There are two ways to read a tender document. Most bidders read it once, for understanding - to grasp what's being asked, note the deadline, and start drafting. Very few read it a second time, for structure - to work out exactly how the marks will be awarded, and where the document is quietly telling you what matters most.
That second read is where the strongest bids begin. Here's how to do it.
Start with the award criteria, not the questions
It's tempting to open the document at the method statement questions, because that's where the writing happens. But the award criteria - the weightings, the sub-criteria, the minimum thresholds - are the document's real instructions. A question worth 5% of the total score and a question worth 30% deserve entirely different amounts of your time, evidence and senior attention, and yet most bidders allocate effort roughly evenly across all of them. Read the weightings first. Let them tell you where to spend your energy before you write a single sentence.
Look for sub-criteria hiding inside a single question
Weightings are sometimes broken down further than the headline percentage suggests - a single question might carry several sub-criteria, each independently scored. This is where score leakage quietly begins: a bidder answers the question as a whole, confidently and well, without realising that the marking scheme is treating it as three or four separate judgements. If the tender pack includes any indication of sub-criteria - even a loosely worded one - build your answer structure around it explicitly, not around your own sense of what a good answer looks like.
Hunt for hidden dependencies between sections
Tender packs are rarely written by a single author in a single sitting. They're assembled from a specification written by one team, a pricing schedule built by another, and evaluation criteria drafted by a third. The result is that requirements often depend on each other in ways that aren't obvious on a first read - a method statement question that only makes sense once you've cross-referenced the service specification, a pricing assumption that depends on a data set buried in an appendix, a mandatory document referenced once in the instructions and never mentioned again. These hidden dependencies are where compliant, well-written bids quietly fail - not because the answer was weak, but because a separate, disconnected requirement was missed entirely.
Ask: what would I mark down, if I were them?
This is the single most useful exercise in the entire process, and it takes ten minutes. Read the specification and the evaluation criteria together, and ask honestly: if I were sitting on the panel, tired, with forty other submissions to get through, what would make me confident in this answer, and what would make me hesitate? That hesitation is exactly what you need to write out of your draft before it goes anywhere near a real evaluator.
Build the map before you write
The strongest bid teams don't start drafting from the first question. They start by building a map of the entire document - every requirement, every weighting, every sub-criterion, every cross-reference - before a single answer is written. It's less immediately satisfying than getting words on the page. It's also the single biggest determinant of where those words end up scoring.
Reading a tender pack like an evaluator, rather than a bidder, is a shift in posture more than a technique. It means treating the document not as an instruction to respond to, but as a scoring machine to be understood - because that, ultimately, is exactly what it is.