Specification clauses you can copy into a tender, with the reason for each one and how to check an offer against it.
Learning Track · Module 13: Tender clause library · Step 100 of 101
Note
Copy a clause into your specification and complete the text in [square brackets]. Each clause states why it matters and how to check the offer. Check every clause with your technical, procurement, and legal teams.
Luminaires
Lighting calculation for each road
The bidder shall submit a lighting calculation for each road type in Annex A, made with the photometric file of the offered luminaire and a maintenance factor of [0.8]. Each calculation shall show compliance with the stated lighting class and give the power density indicator (PDI) and annual energy consumption indicator (AECI).
Why: it compares offers on light delivered to your road, not on watts or lumens per luminaire.
Verify: run one calculation yourself with the bidder's file. The result must match within a few percent.
Efficacy of the complete luminaire
The luminous efficacy of the complete luminaire shall be at least [130] lm/W at the offered output, measured to IES LM-79 or EN 13032-4 by an accredited laboratory. LED package data shall not be accepted as evidence.
Why: LED package figures are often 30% to 50% higher than the luminaire figure.
Verify: check that the test report names the same model, wattage, CCT, and optic as the offer.
Lifetime claim
The bidder shall state the luminaire lifetime as Lx By at a stated number of hours and an ambient temperature of [35] °C, supported by IES LM-80 test data for the LED package and an IES TM-21 projection. Projections beyond six times the LM-80 test duration shall not be accepted.
Why: TM-21 itself limits how far data can be projected. Claims beyond that have no evidence.
Verify: check the LM-80 test duration and the case temperature against the luminaire's real thermal design.
Controller socket on every luminaire
Every luminaire shall have a [Zhaga Book 18 / ANSI C136.41 7-pin] receptacle, whether or not nodes are supplied under this contract. Zhaga luminaires shall carry Zhaga-D4i certification. The bidder shall supply a sealing cap or shorting cap for luminaires without a node.
Why: adding a socket later means replacing the luminaire. Adding it now costs little.
Verify: check the certification database (Zhaga) or the datasheet and a sample (NEMA).
Replaceable driver and LED module
The driver, surge protector, and LED module shall be replaceable on site with standard hand tools, without removing the luminaire from the pole and without special equipment. The bidder shall guarantee the supply of compatible spare parts for [10] years.
Why: electronics fail before the housing. Without this clause, a failed driver can mean a new luminaire.
Verify: ask for a demonstration on a sample during evaluation.
Surge protection
Each luminaire shall withstand surges of at least [10] kV in differential and common mode, with a replaceable surge protection device that shows its status. The cabinet shall have a Type [1+2 / 2] surge protection device.
Why: surges are a leading cause of early driver failure.
Verify: the test report must show the surge test at the stated level.
Uplight, glare, and CCT
Luminaires shall emit no light above the horizontal when installed at the specified tilt [ULOR 0% / BUG U0]. Correlated colour temperature shall be [3000] K on residential roads and [4000] K on main roads. Glare shall not exceed [the class limit / threshold increment of 10%].
Why: reduces sky glow, complaints, and wasted energy.
Verify: check the photometric file at the installed tilt, not only at 0°.
Warranty
The bidder shall give a warranty of [10] years on the complete luminaire, including driver, LED module, and surge protector. A failure is any loss of more than [10]% of LEDs, any driver failure, or water ingress. The bidder shall replace failed parts within [15] days of a claim, including labour [and access equipment].
Why: a warranty without a failure definition or labour is hard to use.
Verify: ask who gives the warranty (maker or local agent) and how claims work.
Controllers and network
Local schedule when offline
Each controller and node shall store its switching and dimming schedule locally and shall continue to operate it for at least [30] days without communication with the central system. On loss of the schedule, the default state shall be [on at full output from dusk to dawn].
Why: a network or platform outage must never make a street go dark.
Verify: disconnect a sample from the network during the trial.
Metering accuracy
Cabinet controllers shall measure energy with an accuracy of [Class 1 / Class 0.5S] or better. Lamp-level nodes used for energy billing shall have a stated accuracy of [±2]% or better over the range from [10]% to 100% load.
Why: savings claims and any billing depend on the meter.
Verify: compare a sample against a calibrated reference meter.
Coverage before award
Before award, the bidder shall demonstrate communication with at least [20] devices placed at sites chosen by the Authority, including the [three] sites with the weakest expected coverage, for a period of [14] days with at least [98]% of scheduled messages received.
Why: coverage maps are not proof.
Verify: the platform's message log for the test devices.
Interoperability
The central system shall support [TALQ] and shall document all interfaces to controllers and nodes. The Authority may connect devices from other suppliers that meet the documented interface, without extra licence fees.
Why: prevents lock-in to one maker for the life of the network.
Verify: check the TALQ certification list. Ask for the interface documents during evaluation.
Connectivity cost
The bidder shall include all connectivity costs (SIM, data, gateway backhaul, and network fees) for the full contract period in the offered price, and shall state the cost per device per year after the contract period.
Why: connectivity is a cost that many offers leave out.
Verify: the price schedule must show a separate line for it.
Software and data
Data ownership and export
All data collected or created under this contract belongs to the Authority. The Authority may export all data, including asset records, readings, work orders, and history, at any time and at the end of the contract, in [CSV and JSON] format, at no extra cost, within [10] working days of a request.
Why: without it, the history of your network leaves with the supplier.
Verify: ask for a sample export during the trial.
Open API
The system shall provide a documented API that lets the Authority's other systems read assets, readings, alarms, and work orders, and create and update work orders. API access shall be included in the price.
Why: lets the system connect to a city command centre, 311, or a GIS.
Verify: review the API documentation before award.
Platform availability
The central system shall be available at least [99.5]% of each calendar month, excluding planned maintenance notified [5] days in advance. The supplier shall pay a service credit of [x]% of the monthly fee for each [0.1]% below this level.
Why: makes availability a contract term, not a promise.
Verify: ask for the last 12 months of availability for existing customers.
Device and system security
Each device shall have unique credentials. Communication shall be encrypted. Firmware updates shall be signed, and devices shall reject unsigned updates. The system shall log every switching command with user and time, and shall support role-based access. The supplier shall notify the Authority of security incidents within [24] hours.
Why: a device that can switch a street is a target.
Verify: ask for a security description and the most recent independent test summary.
Operation and maintenance
Response times
The contractor shall resolve faults within these times from the time the job is raised in the system: Critical [4] hours, High [24] hours, Normal [48] hours, Low [72] hours. Time on hold counts only for reasons agreed in writing by the Authority.
Why: clear start and stop times prevent disputes.
Verify: the work order history in the shared system.
Work order records
For each fault, the contractor shall record in the system the cause from the agreed list, each part used, and a photo of the finished work. A job without these records shall count as not resolved.
Why: repeat failure analysis and warranty claims depend on it.
Verify: sample 20 closed jobs each month.
As-built asset register
Before acceptance, the contractor shall deliver a complete asset register in the Authority's import format, with location, cabinet, circuit, phase, luminaire model, serial number, controller serial, installation date, and warranty end for each asset.
Why: the register is the base for maintenance, warranty, and savings.
Verify: check a random sample of 5% of assets on site.
Handover at contract end
At the end of the contract, the contractor shall hand over the full data export, all passwords and keys for devices and systems, spare parts stock, and documentation, and shall support transition to a new contractor for [3] months.
Why: a contract end without a plan can leave the city without control of its own lights.
Verify: agree the handover plan in the first year.