If you’re preparing an RFQ/RFP for a solar street lighting project, the fastest way to avoid wrong quotes, redesign loops, and tender rejection is not “writing more pages”.
It’s enforcing one auditable evidence chain — the same chain tender reviewers use:
BOQ → Model Code → IES/LDT (exact optics) → DIALux/Relux (targets + uniformity) → Layout Qty → Acceptance & Handover
If this chain is broken (generic photometrics, unclear assumptions, BOQ not mappable), the bid is not “cheaper” — it is not comparable and often not reviewable.
Engineer’s hard rule (Zero-Trust on data):
If a supplier sends a “nice datasheet” but cannot provide a traceable IES/LDT and a DIALux/Relux PDF with tables, they are not selling a solution — they are selling a liability.
Download: RFQ Checklist Template + Site Acceptance Pack (PDF)
This PDF is built for EPC / Government teams to reduce tender rejection and prevent “missing document” disputes during commissioning & site acceptance.
✅ Download the RFQ Checklist + Commissioning / Site Acceptance Pack (PDF) →
How to use it (recommended):
- Attach the PDF to your RFQ / tender form
- Require suppliers to return a filled checklist with their quotation
- Hard rule: If they can’t return a traceable evidence pack (IES + DIALux + BOQ mapping), do not shortlist
Need an EPC-style reply within 24H?
Send any ONE of the following:
- BOQ template (even incomplete)
- Road drawing / cross-section
- Google Map pin + basic notes
✅ Submit here: Engineering Support Hub
✅ Or contact: Contact
Due diligence & factory audit: Manufacturing & Quality
Quick Answer (30 seconds)
A solar street lighting RFQ becomes “review-safe” when it includes four minimum inputs and one deliverables definition:
1) Geometry (road width + pole height concept + spacing constraint)
2) Targets (lux/luminance + uniformity, or “Unknown—supplier to propose”)
3) Solar operation basis (hours/night + autonomy days + environment)
4) Audit deliverables (BOQ mapping + matching IES/LDT + DIALux/Relux PDF with tables)
If you only have a Google Map pin and a rough pole concept — that is enough to start.
Write Unknown where needed, but require the supplier to state assumptions explicitly.
Who this RFQ checklist is for (B2B)
This checklist is built for:
- EPC contractors & consultants
- Government/municipal tenders
- Roadway / public lighting procurement teams
- Projects that require proof, not marketing
If you are sourcing small residential garden lights, this RFQ is not designed for that use-case.
Why many RFQs fail (real tender logic)
Most RFQs fail because suppliers quote using different hidden assumptions, so bids become not comparable.
Example:
- Supplier A assumes 12h/night + 3 nights autonomy
- Supplier B assumes 8h/night + 1 night autonomy
- Supplier C uses a generic IES (wrong optics)
Result: approvals slow down, redesign loops appear, and the tender pack becomes non-auditable.
What reviewers commonly write in technical queries:
- “Please provide the IES/LDT file used in the calculation.”
- “Uniformity is not shown in the report tables.”
- “BOQ quantity cannot be reconciled with the layout.”
Your RFQ must lock comparison variables and force evidence files, so bids are comparable and approval-ready.
Technical Qualification Gate (use this as your tender “hard rule”)
A quotation is not technically qualified if it is missing any of the following:
- Traceable IES/LDT filenames for the exact offered model/optics (with revision/date)
- DIALux/Relux PDF tables showing Avg/Min/Uniformity (not plots only)
- BOQ mapping that lets a reviewer trace BOQ → model → IES → quantity
- Stated assumptions (hours/night, autonomy, mounting height/tilt, environment)
No filenames. No tables. No mapping. No valid comparison.
✅ Upload your BOQ or drawings for a 24H engineering response:
Engineering Support Hub
The evidence pack you must request (Tender / Approval Pack)
A review-safe submission normally includes:
- BOQ mapping table (BOQ → model code → IES/LDT ref → qty)
- IES/LDT files (exact model + exact optics + mounting assumptions)
- DIALux/Relux report PDF (targets + uniformity + layout + settings)
- Datasheets & drawings (spec proof + install feasibility)
- Warranty + spare parts plan
- Acceptance & handover checklist (inspection items + delivered documents list)
If a supplier cannot provide this pack, tender review risk rises sharply.
BOQ → IES → DIALux Mapping (mini example)
This is what “auditability” looks like (demo only, not a customer file):
| BOQ Item | Model Code | Optics | IES/LDT Filename (with revision) | DIALux/Relux Ref | Qty |
|---|---|---|---|---|---|
| 1 | SL-80W-AIO | Type II | SL-80W-T2-0D-REV2.ies | Road-A-Rev2.pdf | 120 |
| 2 | SL-80W-AIO | Type III | SL-80W-T3-0D-REV2.ies | Road-B-Rev2.pdf | 40 |
| 3 | Pole 8m | — | (N/A) | Layout-Notes-Rev2.pdf | 160 |
Minimum naming rule (audit-ready):
IES/LDT filenames should include model + optics + wattage + tilt + revision/date.
Standards Reference (how to write targets without getting trapped)
Different tenders use different standards and metrics. Your RFQ should not guess targets — it should declare the standard reference and require the supplier to align their report format.
If the tender uses EN 13201 (common for roads)
Motorized road classes often use luminance-based criteria (cd/m²) plus uniformity and glare metrics.
In your RFQ, state: “Follow EN 13201 (or local authority standard). Report targets + uniformity + glare metrics in the required format.”
Common reference examples (for context only; always follow tender spec):
- M1: Lav 2.0 cd/m², Uo 0.40, TI 10%
- M3: Lav 1.0 cd/m², Uo 0.40, TI 15%
If the tender is pedestrian / village / area lighting
These projects often use illuminance-based targets (lux) and uniformity (Emin/Eavg or Uo).
If your tender doesn’t specify targets, write:
“Targets: Unknown — supplier to propose with DIALux/Relux proof and stated assumptions.”
Rule: Whatever the standard, the deliverable must include tables (Avg/Min/Uniformity) and assumptions — not screenshots only.
Red Flags 2.0 (engineer-grade screening)
Use this section to reject low-quality “cheap” bids before they waste your schedule.
Red Flag #1 — Generic IES/LDT (no filenames, no revision)
If a supplier cannot provide traceable IES/LDT filenames for the exact model/optics, the simulation is not auditable.
Red Flag #2 — Screenshot-only “proof”
False color plots are not proof.
Require DIALux/Relux PDF with:
- results tables (Avg/Min/Uniformity)
- calculation settings
- luminaire schedule with IES/LDT file reference
Red Flag #3 — BOQ cannot map to layout quantity
If BOQ quantities cannot be reconciled with the layout, reviewers will question the submission.
Red Flag #4 — The “Magic” Maintenance Factor (MF)
A high MF is a classic way to make numbers look good.
RFQ rule: Any maintained assumption must declare:
- environment (dust/coastal/industrial)
- cleaning/maintenance approach
- what MF represents (not just a number)
If a supplier uses an optimistic MF without stating environment and maintenance basis, flag it for review.
Red Flag #5 — The 100% Power Trap (solar energy math)
Solar street lights should not be assumed to run 100% power all night by default.
RFQ rule: Supplier must provide:
- dimming profile (hours + % power schedule)
- basic energy calculation consistent with autonomy days and PV/battery sizing
If the bid assumes 100% power for long hours without an energy profile, the sizing math is unreliable.
DIALux “anti-cheat” checks reviewers use (often overlooked)
These are small details that separate real engineering from “pretty reports”.
Check #1: Calculation grid placement (worst-case matters)
A fake pass is easy if the grid is cherry-picked under the brightest area.
Reviewers should check:
- grid covers the full calculation area
- evaluation includes between poles and darkest points
- tables include Avg/Min/Uniformity (not only graphics)
Check #2: Luminaire schedule must list IES/LDT filename
If the report doesn’t list the IES/LDT file name, reviewers cannot verify photometric traceability.
Check #3: Assumptions must be explicit
At minimum, the report should state:
- pole height, spacing, arm/outreach, tilt
- operating hours/night + autonomy basis
- environment note (dust/coastal) if relevant
RFQ Checklist (Copy/Paste Template)
Copy and paste this section into your RFQ email or tender form.
A) Project Information
- Project name: __
- Country / city: __
- GPS / Google Map pin: __
- Buyer type: EPC / Government / Consultant / Distributor: __
- Application: roadway / street / village / parking / port / high-mast: __
- Target completion date: __
B) Site & Geometry (OK to write “Unknown”)
- Road type: 2-lane / 4-lane / mixed: __
- Road width (m): __
- Sidewalk / shoulder (m): __
- Median: Yes / No (width m): __
- Curves / intersections / bridges: Yes / No (notes): __
- Shading risks (trees/buildings): Yes / No (notes): __
C) Pole & Layout Assumptions
- Pole height (m): __
- Pole spacing concept (m): __
- Pole setback from curb (m): __
- Arm length / bracket (m): __
- Mounting tilt: 0° / other: __
- Installation: single side / double side / median: __
D) Lighting Targets & Standard Reference
- Standard reference (if tender states): EN 13201 / IES / Local authority / Other: __
- Target average (lux or luminance): __
- Minimum value (if required): __
- Uniformity requirement (Uo or Emin/Eavg): __
- Glare / spill / uplight restrictions: __
If targets are not provided:
Unknown — supplier to propose with DIALux/Relux proof and stated assumptions.
E) Solar Operation Profile (Critical for off-grid performance)
- Operating hours per night: __
- Dimming profile needed: Yes / No (describe): __
- Autonomy days (backup nights): __
- Rainy season / cloudy days expectation: __
- PV orientation limits (if any): __
- Battery chemistry preference: LiFePO₄ / other / Unknown: __
- Anti-theft requirement: Yes / No / Unknown: __
F) Environment & Durability (Often the project “killer constraints”)
- Dust / desert: low / medium / high: __
- Coastal salt corrosion: low / medium / high: __
- Wind rating requirement (if known): __
- Temperature range: __
- Vandalism risk: low / medium / high: __
G) Scope of Supply
- Solar street lights qty: __
- Poles included: Yes / No
- Foundation / anchor bolts included: Yes / No
- Cabling / trenching included: Yes / No
- Smart control (4G/LoRa/platform): Yes / No / Optional
- Commissioning & training required: Yes / No
H) Deliverables Required (do not accept screenshots only)
Supplier must provide:
- BOQ mapping table (BOQ → model code → IES/LDT ref → qty)
- IES/LDT photometric files (exact model + optics + mounting tilt assumptions)
- DIALux/Relux report PDF with tables (Avg/Min/Uniformity + settings)
- Layout screenshots showing pole positions + calculation area
- Datasheets pack (luminaire/controller/battery/panel/pole if included)
- Warranty statement (system vs components) + spare parts plan
- Acceptance & handover checklist (inspection points + document list)
I) Compliance & Certifications (as per tender)
Write Unknown if your tender has not specified requirements.
Supplier must confirm availability and provide evidence upon request.
- Required certifications (examples): CE / RoHS / IEC / IP / IK: __
- Battery transport compliance (if required): UN38.3 / MSDS: __
- Corrosion resistance (if required): salt spray / coating class: __
- Local authority reporting format: __
J) Quotation must confirm
- Lead time & Incoterms: __
- Warranty years + exclusions: __
- Spare parts recommendation (%): __
- Packing & labeling list: __
- Compliance documents available (on request): __
How to fill it fast (step-by-step)
Step 1 — Don’t wait for perfect data
If you only have:
- a BOQ template, or
- a Google Map pin + “2-lane road, ~8m wide”
that is enough.
Write Unknown where needed, but require the supplier to return:
- explicit assumptions
- matching IES/LDT filenames
- DIALux/Relux PDF with tables
- BOQ mapping
Step 2 — Lock comparison variables early
To compare bids fairly, lock these first:
- operating hours/night
- autonomy days
- pole height concept
- targets (or supplier to propose with proof)
Step 3 — Enforce auditability (the only rule that matters)
Your RFQ must force this chain:
BOQ → model code → IES/LDT file → DIALux/Relux report → layout quantity
What to upload for a 24H engineering reply
Upload any one (more is better):
- BOQ template (Excel/PDF)
- Road drawing/cross-section
- Google Map pin + basic road notes
- Tender excerpt (targets/standard)
- Site photos (optional)
✅ Submit here: Engineering Support Hub
✅ Or contact: Contact
FAQ (EPC / Government RFQ)
1) What is the minimum input to start a solar street lighting RFQ?
A Google Map pin plus a basic road description (road type and approximate width) is enough to start.
Use Unknown for missing items, but require the supplier to return a DIALux/Relux report and stated assumptions.
2) Can we accept DIALux screenshots instead of a full PDF report?
Usually not for tenders. Reviewers typically require tables (Avg/Min/Uniformity) and calculation settings.
Screenshots alone are not auditable.
3) Why do IES/LDT filenames matter in a tender pack?
Because the reviewer must confirm the simulation used the exact offered model and optics.
If IES/LDT filenames (with revision/date) are missing, the submission becomes non-traceable.
4) If we don’t know the target lux/uniformity yet, what should we write?
Write “Unknown—supplier to propose”, and require the supplier to provide:
- recommended targets aligned to the referenced standard (if applicable)
- DIALux/Relux proof with tables
- all assumptions clearly listed
5) What is the most common reason solar street lighting tenders get delayed?
Missing audit mapping: BOQ cannot be traced to model code → IES/LDT → DIALux layout qty.
This triggers clarification rounds and redesign loops.
6) What should we upload to get a 24H engineering reply?
Any ONE of: BOQ template, road drawing/cross-section, or a Google Map pin with basic notes.
Submit via Engineering Support Hub or Contact.
Next step (high-conversion CTA)
Don’t gamble with tender timelines or public safety.
If a supplier’s pack doesn’t withstand a traceability audit, reject it.
Need a second opinion on a technical submission?
✅ Upload the BOQ/drawings/report here for a 24H engineering response:
Engineering Support Hub
Or contact our team directly: Contact
Factory & quality due diligence: Manufacturing & Quality
