When several suppliers quote the same solar street lighting project, the first question should be:
Are they actually quoting on the same technical basis?
Two quotations may both say “80 W solar street light” while using different operating profiles, autonomy assumptions, batteries, solar modules, optics, poles, or supply scopes. In that situation, comparing prices alone can give the wrong picture.
A useful solar street light RFQ should give all suppliers the same known project inputs while making supplier-specific proposals, assumptions, configurations, evidence, and deviations visible.
The goal is not to force every supplier to offer an identical product.
The goal is to make the differences clear enough for the EPC contractor, procurement team, consultant, or municipal reviewer to understand what each quotation actually includes before commercial comparison begins.
A practical flow is:
Project Inputs → RFQ → BOQ → Supplier Response → Technical Evidence → Clarification / Deviation → Comparable Quotations
Define the Same Technical Basis Before Suppliers Quote
Many quotation problems begin before the supplier calculates a price.
If one supplier assumes 12 hours at full output, another uses a dimming schedule, and a third designs for a different autonomy requirement, the nominal wattage may be the same while the system configuration and energy basis are materially different.
Before requesting quotations, define the common project basis as far as the available information allows.
Not every input needs to be finalized before the first RFQ. Known conditions should be stated, open items should be marked for confirmation, and supplier assumptions should remain visible.
For a broader document outline, see the solar street light tender sample and RFQ structure.

Project and site conditions
Useful starting information may include:
- country and project location;
- road or application type;
- project quantity;
- road width and number of lanes;
- pole arrangement;
- existing infrastructure;
- road or site drawings, if available;
- relevant solar-access or shading constraints;
- coastal, dusty, high-temperature, or other special environmental conditions.
If the project is still at an early stage, some of these inputs may not yet be available. That does not prevent an RFQ from being issued, but the missing information should remain identifiable rather than being replaced by hidden assumptions.
Lighting requirements
If lighting criteria have already been defined, include them in the RFQ.
Depending on the project, this may include:
- mounting height;
- pole spacing, if fixed;
- road or application classification;
- illuminance or luminance requirements;
- uniformity requirements;
- road layout or lighting-design references.
If the lighting layout is not finalized, state that clearly. The supplier can then prepare a proposed arrangement instead of appearing to quote against a fixed design.
Operating profile
For solar street lighting, the operating profile affects daily energy consumption and therefore influences battery and PV sizing.
Where known, specify:
- operating hours per night;
- full-output period;
- dimming schedule;
- motion-control requirement;
- seasonal or special operating conditions.
For example, two 80 W luminaires may use very different nightly energy if one operates at full output for 12 hours and the other follows a staged dimming program.
That difference should be visible when the quotations are compared.
Solar and energy design basis
The buyer does not need to perform the supplier's system design.
However, any design basis already fixed by the project should be stated, such as:
- project location;
- solar-resource or design-data source;
- required autonomy, if specified;
- operating-profile reference;
- battery technology requirement, if the tender specifies one;
- environmental design conditions;
- other project-specific energy constraints.
If the buyer has not fixed a value, the supplier can propose one.
The important point is that the proposal remains identifiable as a Supplier Proposal or Supplier Assumption, rather than appearing to be part of the original buyer requirement.
Supply and service scope
Price differences often come from scope differences rather than product quality.
A quotation may include the pole, anchor bolts, commissioning, training, or spare parts, while another quotation may cover only the solar lighting system.
For each scope item, use a clear project status such as:
- REQUIRED
- OPTIONAL
- TO CONFIRM
- NOT APPLICABLE
Typical scope items include:
| Scope Item | Project Status | Notes / Reference |
|---|---|---|
| Luminaire | ||
| Solar module | ||
| Battery | ||
| Controller | ||
| Pole | ||
| Arm / bracket | ||
| Anchor bolts | ||
| Foundation scope | ||
| Installation | ||
| Commissioning | ||
| Training | ||
| Spare parts | ||
| Technical documentation | ||
| Packing / shipping |
A lower quotation may simply include a different supply boundary.
Confirm the scope before deciding which supplier is cheaper.
Separate Buyer Requirements From Supplier Proposals
A project RFQ does not need to contain every engineering answer.
Some conditions are fixed by the buyer. Others are intentionally left for suppliers to propose.
Those two categories should not be mixed.
A Supplier Proposal is a solution the supplier recommends.
A Supplier Assumption is an input temporarily used because the buyer has not yet fixed that condition.
Both can be valid during quotation, but they should remain visible.

Illustrative example — not an actual project
| Item | Buyer Requirement | Supplier Proposal / Assumption | Source | Status |
|---|---|---|---|---|
| Pole spacing | 30 m | — | Road drawing Rev.B | CONFIRMED |
| Autonomy | Not specified | 3 nights proposed | Supplier offer | TO CONFIRM |
| Dimming | Not specified | Supplier schedule proposed | Supplier offer | TO CONFIRM |
| Pole height | 8 m | — | BOQ | CONFIRMED |
If 30 m pole spacing is fixed in the project drawing, the supplier should design against that condition unless a different arrangement is clearly proposed.
If autonomy is not specified, the supplier may recommend a design basis. That proposal should remain visible until the buyer or consultant confirms it.
The same principle applies to:
- dimming;
- solar module sizing;
- battery configuration;
- optic selection;
- controller strategy;
- mounting arrangement;
- spare-parts scope.
A useful rule is:
Not specified does not mean silently assumed.
From a supplier-side engineering review, this distinction is especially important. A supplier may need to make assumptions to prepare a preliminary system configuration, but those assumptions should be traceable and reviewable before the quotation becomes the technical basis for an order.
Map Each BOQ Item to the Offered Configuration and Evidence
A BOQ may state:
80 W solar street light — 500 sets
That line does not fully describe what the supplier is offering.
For a meaningful technical comparison, the project team should be able to trace:
BOQ Item → Offered Model → Key Configuration → Evidence Reference

A simplified mapping may look like this:
| BOQ Item | Offered Model | Key Configuration | Evidence Reference | Status |
|---|---|---|---|---|
| SSL-01 | Model ABC-80 | 80 W luminaire / stated PV and battery configuration / defined optic | DS-01 / IES-01 | CONFIRMED |
The purpose is not to reproduce the supplier's complete internal BOM.
The purpose is to record the configuration details that materially affect the project comparison, which may include:
- luminaire model;
- luminaire wattage;
- solar module;
- battery;
- controller;
- optic or light distribution;
- operating profile;
- pole or mounting arrangement;
- included accessories.
For configuration options, see solar street light systems for EPC and municipal projects.
Link supporting documents to the actual offer
Supporting evidence may include:
- datasheet;
- IES or LDT file;
- DIALux or Relux calculation;
- product drawing;
- pole drawing;
- relevant test report;
- certificate;
- warranty statement;
- installation document.
The existence of a file does not automatically prove that it applies to the quoted product.
The reviewer should be able to check whether the document is relevant to the offered configuration.
For example:
- Is the photometric file applicable to the offered luminaire configuration and optic?
- Does the drawing refer to the same product or revision?
- Does the test report cover the relevant model or configuration?
- Was the lighting calculation prepared using the same road geometry and mounting arrangement stated in the quotation?
A filename is therefore an Evidence Reference, not automatic proof of applicability.
This is where supplier-side engineering discipline matters. For Sunlurio, a useful quotation package should make it possible to follow the relationship between the quoted BOQ item, the proposed product configuration, and the supporting project documents without forcing the buyer to reconstruct that relationship from unrelated files.
For supporting reports, see how lighting test evidence should be reviewed.
Track Clarifications, Revisions and Supplier Deviations
RFQs often change during the quotation process.
Suppliers ask questions. Buyers or consultants respond. Drawings may be revised. Quantities or requirements may change.
The practical objective is not to create a complicated document-control system.
It is to make sure everyone knows which requirement and revision the quotation is based on.

When a clarification affects the RFQ
A simple flow may be:
RFQ Rev.0
↓
Supplier Question
↓
Buyer / Consultant Response
↓
Addendum / Amendment, if required
↓
Revised Supplier Quotation
A supplier question does not automatically change the RFQ.
Likewise, a clarification response does not necessarily become a formal amendment in every procurement procedure.
The important point for comparison is that the reviewer can identify the current RFQ revision and any relevant clarification or formal change reflected in the quotation.
When a supplier proposes something different
A Buyer Amendment changes the project requirement.
A Technical Deviation records a supplier offer that differs from a stated requirement.
For example:
| Buyer Requirement | Supplier Offer | Difference | Reference | Decision |
|---|---|---|---|---|
| Specified configuration | Alternative configuration proposed | Technical deviation | DEV-01 | TO REVIEW |
A deviation is not automatically acceptable or unacceptable.
Its treatment depends on the applicable tender rules, project authority, and contract procedure.
For quotation comparison, the key requirement is visibility: the difference should not disappear inside the supplier offer and later be treated as though it were identical to the original requirement.
Use One RFQ–BOQ Comparison Register
As a tender develops, information can become fragmented across the BOQ, supplier quotations, datasheets, drawings, IES files, clarification emails, and revised documents.
A single comparison register helps keep those relationships visible.
A practical structure is:
| BOQ / Requirement | Official Basis | Offered Model / Configuration | Evidence | Supplier Assumption / Issue | Clarification / Revision | Reviewer Decision | Status |
|---|

Recommended Comparison Status values are:
- CONFIRMED
- TO CONFIRM
- DEVIATION
- SUPERSEDED
- NOT APPLICABLE
The register does not replace tender evaluation, consultant approval, contract review, or final technical approval.
It is a working control tool that helps the project team see where quotations are aligned and where further review is still required.
Illustrative example
Illustrative example — not an actual project
| Item | Basis | Supplier Offer | Evidence | Issue | Status |
|---|---|---|---|---|---|
| Pole spacing | 30 m drawing basis | Designed to 30 m | Lighting calculation | — | CONFIRMED |
| Autonomy | Not stated | 3 nights proposed | Supplier calculation | Buyer confirmation required | TO CONFIRM |
| Optic | Specified optic required | Alternative optic proposed | IES reference | Technical deviation | DEVIATION |
For larger projects, this process is easier to manage in a structured workbook than in a long email chain or a single RFQ document.
To make the method usable on a live tender, the same logic is built into the editable RFQ / BOQ Comparison Workbook included in the Sunlurio RFQ Toolkit V2.
It separates:
- Project Inputs;
- Supplier Response;
- RFQ / BOQ Comparison;
- Evidence Register;
- Clarification / Revision;
- Technical Deviation.
Download the Solar Street Light RFQ Toolkit V2
Use the PDF checklist to prepare the RFQ basis, then use the editable Excel workbook to record supplier responses, evidence, clarifications, revisions and technical deviations.
Toolkit V2 includes a 10-page PDF checklist and editable RFQ / BOQ comparison workbook.
Confirm the Technical Basis Before Comparing Price
Before moving into commercial comparison, run one final check.
Scope
Confirm that:
- quantities are comparable;
- the supply boundary is clear;
- major inclusions and exclusions are visible.
Operating basis
Confirm that:
- operating hours are visible;
- dimming assumptions are visible;
- autonomy is either defined or clearly shown as a supplier proposal.
Product and configuration
Confirm that:
- the offered model is identified;
- the main system configuration is visible;
- pole, mounting, and accessory scope are clear where relevant.
Evidence
Confirm that:
- datasheets can be traced to the offered model;
- photometric files are identifiable where required;
- calculations and drawings are referenced;
- relevant evidence can be linked to the offered configuration.
Document control
Confirm that:
- the current RFQ revision is identifiable;
- relevant clarifications have been recorded;
- applicable addenda or amendments are reflected;
- supplier deviations are visible;
- superseded information is distinguishable from the current basis.
Once those points are sufficiently clear, the project team can compare prices with a much better understanding of what each quotation represents.
There is an important boundary:
Technically comparable does not mean technically approved, contractually compliant, or selected for award.
Technical comparability is only one part of the evaluation process. Final responsiveness, approval, contractual compliance, and award decisions remain subject to the buyer's tender procedure, consultant review, project authority, and applicable contract requirements.
Frequently Asked Questions
What information should be included in a solar street light RFQ?
A practical RFQ normally identifies the project location, application, road or site geometry, lighting requirements where defined, operating profile, autonomy basis where specified, supply scope, quantities, and required technical documentation.
Not every input needs to be finalized. Open items can be marked TO CONFIRM, while suppliers can be asked to identify their proposed design basis.
Can I request quotations before the lighting design is finalized?
Yes.
In early project stages, some technical conditions may still be under review.
The RFQ should distinguish between:
- fixed Buyer Requirements;
- items still TO CONFIRM;
- Supplier Proposals;
- temporary Supplier Assumptions.
This allows suppliers to prepare preliminary configurations without making unconfirmed assumptions appear to be approved project requirements.
Should battery capacity be specified in Ah or Wh?
Ah should not be compared independently of battery voltage.
Where battery capacity is specified, the electrical basis and configuration should be clear. Wh can make stored-energy comparison more direct, but usable energy still depends on the battery design and operating limits.
For many project RFQs, defining the required operating profile and autonomy basis is more useful than prescribing battery capacity alone.
How do I compare quotations from different solar street light suppliers?
First confirm that the quotations are based on a comparable project basis.
Check:
- project inputs;
- supply scope;
- operating profile;
- autonomy basis;
- offered model;
- system configuration;
- supporting evidence;
- supplier assumptions;
- clarifications;
- revisions;
- technical deviations.
Then compare commercial prices.
What is a technical deviation in a lighting tender?
A technical deviation is a recorded difference between a stated project requirement and the supplier's proposed offer.
It should make the original requirement, supplier alternative, reason or supporting evidence, and review decision visible.
The final treatment of that deviation depends on the applicable tender procedure and responsible project authority.
How do I check whether an IES file applies to the offered luminaire?
Confirm that the photometric file is applicable to the configuration being quoted.
Relevant checks may include:
- luminaire model or product family;
- output configuration or wattage;
- optic or light distribution;
- relevant revision.
A generic or unrelated photometric file should not automatically be assumed to represent the product included in the quotation.
Preparing a Solar Street Light RFQ or Reviewing a Tender?
If your project already has a BOQ, tender specification, road layout, or technical requirement list, Sunlurio can review the available information from a supplier-side engineering perspective before preparing a project quotation.
Where available, include:
- BOQ or tender specification;
- project quantity;
- country and project location;
- current document revision;
- road drawing or layout;
- lighting requirements, if defined;
- submission deadline.
For project-based inquiries, including the quantity and project location helps the engineering team understand the scope more quickly.
Sunlurio can review project inputs, supply scope, configuration questions, and document requirements that may need clarification before quotation.
For project document questions, see tender document and BOQ review or lighting engineering support.
Send Your BOQ / Tender Specification
For teams preparing their own RFQ, the Solar Street Light RFQ Toolkit V2 includes:
- a 10-page RFQ Checklist PDF; and
- an editable RFQ / BOQ Comparison Workbook.
The toolkit is designed to help organize project inputs, supplier responses, supporting evidence, clarifications, revisions, and technical deviations before commercial comparison.