Prepare a solar-street-light tender comparison.

Buyer guide

1. Transcribe the tender requirement exactly

Create one row for each requirement, retaining its source clause, destination, deadline set by the buyer and mandatory/optional status. Separate technical requirements from commercial, delivery, inspection and legal requirements. A shorter paraphrase can sit beside the original wording, but it must not replace it. This makes later review traceable to the tender rather than to memory.

Keep a source-copy link or page reference beside every row and state the tender revision being used. If the buyer issues an addendum, record which matrix rows changed and whether earlier evidence needs reconsideration. This small discipline reduces the chance that a superseded requirement remains hidden in an old spreadsheet. Open the browser-local requirements review.

2. Identify the project configuration

For every product-related row, record the candidate family, exact model if known, proposed configuration and mounting context. If no exact configuration has been selected, say so. A family page or image may start a conversation but cannot establish that every variant has the same characteristic or remains available for the project.

3. Match documents to the quoted configuration

Request the relevant document, drawing, file, sample record or written confirmation, then record its issuer, date, holder, named product/configuration and scope. A test report, conformity document or supplier statement should be called what it is. It should not be converted into a blanket certification or a claim about all production. See quality and documents and the outdoor-lighting document request list for the document-scope approach.

4. Separate compliance from design suitability

A document may answer one tender requirement while leaving site geometry, solar conditions, controls, installation or maintenance unresolved. Maintain a separate design-input row and link it to the project brief. The solar-design guide helps make those inputs visible, but it does not calculate a project result or replace the tender authority’s requirements.

5. Resolve exceptions and substitutions before award

Use a clear status such as supplied, buyer to confirm, supplier to confirm, not applicable or unconfirmed. Record why a row is open and who must close it. If a requested item is substituted, retain both the original requirement and the proposed alternative, with a decision owner. Confirm each open row before the award decision.

Tender comparison worksheet

Use the browser worksheet to compare requirements with a proposed configuration and the documents supplied for the project. Entries stay in this browser until downloaded; they are not supplier confirmations or an automatic compliance result.

6. Carry the matrix into sample and order review

Once a configuration is chosen, use the same row identifiers in the sample-approval record, quote, drawings, labels and inspection discussion. Re-check anything affected by a revision, accessory, destination change or configuration change. The aim is continuity of evidence, not a generic pre-award checklist.

Reusable tender-evidence request

Copy this as a starting point, then replace bracketed fields with project facts. It requests evidence; it does not imply that a document, capability, approval or outcome already exists.

Limits and next step

Use this matrix as a working record, not a declaration of tender compliance, a certification statement or legal advice. Ask for current confirmation of each offered configuration, required document and tender condition. Keep unconfirmed rows open for the relevant reviewer before an award decision.