01The Specification Is the Scoring Guide
Every care sector tender includes a service specification. It is the longest document in the ITT pack. It describes the service the council wants delivered, the standards it expects, the outcomes it measures, and the regulatory framework it operates within.
Most providers read the specification once, retain a general impression of what the council wants, and then write their method statements based on their own service model. This produces answers that describe what the provider does. It does not produce answers that describe what the council asked for.
The distinction costs marks. Every quality question in the tender is derived from a section of the specification. Every evaluator checklist item maps to a specification requirement. A response that mirrors the specification scores higher than one that ignores it, because the evaluator is literally checking your answer against the specification.
02The Structure of a Typical Care Specification
Care sector specifications follow a consistent structure. Understanding this structure allows you to navigate any specification efficiently.
03Section 1: Introduction and Context
Background on the procurement. Population demographics. Strategic priorities. This section tells you why the council is commissioning the service and what local factors matter. Use this data in your opening paragraphs to demonstrate local knowledge.
04Section 2: Service Description
What the service is. Who it serves. Hours, geography, and scope. This section defines the boundaries of the contract. Referencing it demonstrates that you understand what you are bidding for.
05Section 3: Service Delivery Requirements
The operational detail. How care should be delivered, how assessments should be conducted, how care plans should be written, how reviews should be scheduled. This is the section your service delivery and quality method statements should mirror.
06Section 4: Safeguarding and Risk
The council’s safeguarding expectations. Reporting requirements. Multi-agency protocols. Your safeguarding method statement should reference this section by number.
07Section 5: Workforce
Staffing requirements. Qualifications. Training expectations. DBS requirements. Supervision and appraisal expectations. Your workforce method statement maps directly to this section.
08Section 6: Quality and Monitoring
KPIs. Audit requirements. Reporting schedules. Contract review mechanisms. Your quality monitoring method statement should address every KPI listed here.
09Section 7: Social Value and Community Benefit
Where present, this section outlines the council’s social value expectations. Your social value response should use the language from this section.
10Section 8: Mobilisation and Transition
Expected timelines for service commencement. TUPE information. Transition requirements. Your mobilisation answer should reference these timelines directly.
Not every specification uses these exact headings. But the content follows this pattern. Recognising it allows you to locate relevant sections quickly when writing each method statement.
11The Three-Pass Reading Method
TenderLab reads every specification three times before writing begins. Each pass has a different purpose.
12Pass 1: Orientation (30 minutes)
Read the entire specification from start to finish without taking notes. The purpose is to understand the scope, the tone, and the council’s priorities. After this pass, you should be able to answer: What is this service? Who does it serve? What does the council care most about?
13Pass 2: Mapping (60 minutes)
Read again with the tender questions open alongside the specification. For each quality question, identify which specification sections it references. Write the section numbers next to each question. This creates a map that tells you exactly where to look when writing each method statement.
If a question does not reference a specification section explicitly, search the specification for the relevant topic. The question on safeguarding will map to the safeguarding section. The question on workforce will map to the workforce section. The connection is always there.
14Pass 3: Extraction (90 minutes)
For each mapped section, extract the specific requirements. These are the evaluator’s checklist items. List them for each question. When you write the method statement, address each extracted requirement in order.
This process takes approximately three hours. It produces a complete scoring map for the entire tender. Every minute spent on specification reading saves time during writing and improves scoring accuracy.
15What to Look For: The Scoring Signals
Specifications contain language that signals what the evaluator will check for. Learning to recognise these signals accelerates the reading process.
16“The Provider shall...”
This is a mandatory requirement. Your method statement must address it. Omitting a “shall” requirement is equivalent to failing to answer part of the question.
17“The Provider is expected to...”
This is a strong expectation. Not addressing it will cost marks. It may not trigger an automatic fail, but the evaluator will note its absence.
18“The Provider should consider...”
This is a differentiator. Addressing it demonstrates depth and thoroughness. Providers who respond to “should consider” items score higher than those who address only mandatory requirements.
19Named Practices and Frameworks
When the specification names a specific framework, standard, or practice, reference it by name in your method statement. If the specification mentions Making Safeguarding Personal, your answer must include that exact phrase. If the specification references the Accessible Information Standard, your answer must use those words.
20Specification-Driven Architecture
TenderLab uses the term specification-driven architecture to describe the process of structuring method statements around specification requirements rather than around the provider’s own service model.
The difference:
Provider-driven: “This is what we do. Here is how we do it. Here is why it is good.”
Specification-driven: “The specification requires X. We deliver X through [specific system]. The outcome is [measured result].”
The second approach scores higher because it demonstrates alignment. The evaluator reads a response that addresses their requirements in their language, referencing their document. It makes their job easier, which makes your score higher.
21Common Specification Reading Mistakes
22Mistake 1: Reading Only the Questions
Some providers read only the quality questions and never open the specification. The questions are derived from the specification. Without reading the specification, you cannot identify the sub-requirements that the evaluator will check for.
23Mistake 2: Reading Once and Forgetting
A single read produces a general impression. It does not produce the specific section references, named practices, and mandatory requirements that the evaluator will score against. Three passes are necessary.
24Mistake 3: Ignoring the Appendices
Specifications frequently include appendices with KPIs, reporting templates, quality frameworks, and outcome measures. These appendices contain scoring content that should appear in your method statements. Ignoring them means ignoring scoring opportunities.
25Mistake 4: Assuming All Specifications Are the Same
They are not. Every council has different priorities, different KPIs, and different language. A specification from one council will emphasise outcomes. Another will emphasise processes. Another will focus on partnership working. Your method statements must reflect the priorities of the specific specification, not a generic assumption about what councils want.
26How TenderLab Uses the Specification
For every tender, TenderLab produces a specification analysis document before writing begins. This document contains the question-to-specification mapping, the extracted requirements for each question, the named practices and frameworks the evaluator will check for, and the KPIs that should be referenced in quality monitoring answers.
The writer then constructs each method statement against this analysis, addressing every requirement in order, using specification language, and referencing specification sections by number. The result is a set of responses that the evaluator can verify against their own document.
Providers who treat the specification as background reading are writing blind. The specification tells you what to write. It tells you what language to use. It tells you what the evaluator will check. The only thing it does not tell you is your own operational detail. Combine the specification’s structure with your organisation’s practice, and you have a response that scores.