If your case is a request for proposal from a private client, the piece you want is automate RFP response with AI. This one covers public-sector tenders: the tender document, the legal deadline, the award criteria and PLACSP (Spain's public-sector procurement platform), where the rules are formal and the room for interpretation is scarce.
If you have not yet decided what to equip yourself with to bid sustainably — a third-party tool or your own capability — that prior decision is covered in AI for public tenders: buy the tool or build the capability?.
The proposal doesn't describe your company: it responds to a tender document
The most common starting mistake is treating the proposal like a corporate dossier: who we are, what we do, how well we do it. It's material that sounds good and doesn't score.
The tender document sets out award criteria with their allocation of points. The tender board doesn't read looking for a good company: it reads looking for evidence of each criterion, and scores what it finds. If your methodology is described brilliantly but in a section different from the one the tender document asks about, the evaluator may not count it as answered.
A competitive technical proposal describes how you're going to deliver the contract: work methodology, material and human resources, service organization, timelines, quality control and the improvements you offer over what is required. Everything else is context, and context doesn't score.
Read the tender document backwards
The most useful practice, and the one almost nobody applies systematically: start at the end of the tender document. Go first to the award criteria, break them down into sub-criteria, and build the outline of your proposal around them.
That gives you a structure where each section responds to a scorable criterion, in the order the contracting authority has written them. The evaluator finds what they're looking for where they expect to find it, and doesn't have to reconstruct your answer.
A method that works:
- Extract the criteria from the tender document with their exact scoring and their relative weight.
- Separate the criteria evaluated by value judgement from the automatic ones (formula).
- Turn each criterion into a section of your outline, with the same name the tender document uses.
- Assign length proportional to the points: a criterion worth 30 points can't take up the same space as one worth 5.
- Flag the eligibility requirements and check that each one has a supporting document before writing anything.
That last step avoids the most expensive work of all: writing fifty pages only to discover at the end that a certificate was missing.
The error that disqualifies: mixing the economic with the technical
Of all the possible mistakes, this is the only one that can't be recovered. One of the most frequent grounds for exclusion in a public-sector tender is introducing economic information, or information that can be scored objectively, into the technical-proposal envelope.
The logic of the procedure is that the criteria subject to value judgement are evaluated before the economic offer is known, precisely so that price doesn't contaminate that assessment. If your proposal reveals the price —directly or by deduction, with a breakdown of hours and profiles that allows it to be calculated—, the board can exclude you.
It's not a technicality: it's the rule that turns a good offer into an offer that doesn't get read. It deserves a dedicated review, by someone other than whoever wrote it, before every submission.
Every claim needs backing
Proposals fill up with sentences nobody can verify: "extensive experience in similar projects", "a highly qualified team", "a proven methodology". They don't score, because the evaluator has no way to take them as true.
What does score is the concrete and verifiable: the project with a name, scope and date; the certification with its number; the profile with its qualification and years; the indicator with its value and its source. A useful rule of thumb:
If a claim in your proposal can't point to a company document that backs it up, either it becomes something that can, or it goes.
This also has a risk dimension. In a public-sector tender, claiming a compliance you then can't sustain isn't a writing error: it's a contractual problem, and in the worst case, grounds for termination. Traceability isn't a documentary obsession — it's what lets you defend every line if it's challenged.
Why the second proposal costs the same as the first
Here's the structural problem, and it's the one no writing tip solves.
A company that bids on tenders regularly has already written almost everything it needs. The methodology descriptions, the staff profiles, the certificates, the reference cases, the quality plans: they exist, in previous proposals. But they live in per-project folders, in versions nobody knows which is the good one, and in the head of the person who wrote it last time.
So every tender starts near zero. And since the deadline is fixed and always arrives at a bad moment, the real decision usually isn't "how do we make the best proposal" but "which of the three do we bid on". The tenders you don't submit aren't lost: you don't even compete.
The cost isn't in the writing. It's in reassembling each time what you already knew.
Outsourcing the proposal has a cost you don't see
The market's usual answer is to hire a specialized consultancy. They write well, know the procedure and solve the workload peak. For a company that bids on two tenders a year, it's a reasonable decision.
For one that bids on twenty, it has a cumulative consequence: every proposal written by a third party leaves with that third party. The learning about which arguments score in your sector, which format that contracting authority prefers, which version of your eligibility profile is the current one — all of that stays outside. By the fifth year you depend just as much as in the first.
It's not an argument against outsourcing. It's an argument in favour of the knowledge staying in your company, whoever writes it.
Where AI fits, and where it doesn't
The part of the proposal that eats up time isn't the creative part: it's locating, selecting and rewriting material that already exists so it responds to this specific tender document. That is automatable, and it's where an assistant with the context of your company changes the economics of the process.
What it can do well:
- Analyze the tender document and extract award criteria, eligibility requirements and critical warnings, with their weight.
- Propose the outline derived from those criteria, in the tender document's order.
- Draft section by section from your previous proposals and your real documentation, citing which document each claim comes from.
- Accumulate the learning from each tender —outcome, score, what worked— so the next one starts higher up.
What it doesn't do, and it's worth saying plainly:
- It doesn't win the tender. That depends on your offer, your real eligibility and your competitors.
- It doesn't replace human review. The draft is a draft; the responsibility for what gets signed remains a person's.
- It doesn't invent what you don't have. If the tender document asks for a certification your company can't evidence, the problem isn't one of writing.
That's exactly the approach of Licia, our public-tender assistant: it works on your proposals, your previous tender documents and your corporate information, integrates with PLACSP and cites the source of every claim, with human review points. You submit more tenders, without growing the team — and the knowledge stays in your company.
Technical proposal template, section by section
This is the skeleton that repeats across most public service tenders. It is not a fill-in-the-blanks template: the tender documents always win. If their order of criteria does not match this index, follow theirs. It is good for two concrete things: leaving no section out, and knowing before you write where each one loses points.
| Section | What it answers | Where points are lost |
|---|---|---|
| 1. Index and cross-reference table | Which award criterion is answered on which page | Making the evaluator hunt. A criterion they cannot find scores nothing |
| 2. Understanding of scope | That you have read these tender documents, not that you know the sector | Paraphrasing the contract object and calling it understanding |
| 3. Methodology and work plan | How it gets delivered: phases, milestones, deliverables, dependencies | A generic method that would fit any other contract equally well |
| 4. Organisation and staffing | Roles, real allocation and who covers for whom | Attaching CVs without saying what each role does on this contract |
| 5. Equipment and technical resources | What it is delivered with, and what is already in place | Listing inventory without tying it to the tasks in the plan |
| 6. Quality and control plan | What is measured, how often, and what evidence backs it | Promising quality with no indicator, threshold or owner |
| 7. Risk management | Risks specific to this contract, and how they are mitigated | Textbook risks, identical across every bid |
| 8. Transition and start-up plan | How you take over without interrupting the running service | Treating it as solved when the tender scores it separately |
| 9. Improvements | Only those the tender documents score, quantified and evidenced | Giving away improvements that score nothing, documenting none that do |
| 10. Commitments and service levels | What you are bound to, and what happens if you miss it | Committing to an SLA the organisation cannot sustain |
| 11. Annexes and supporting evidence | The documentary proof behind every claim in the body | Claiming in the body what no annex supports |
One note on using the outline: the cross-reference table in section 1 returns more than anything else for the effort it costs. It is the first thing an evaluator looks at and the last thing most bidders prepare.
Frequently asked questions
Is there a technical proposal template that works for any public tender?
No. The skeleton repeats — scope, methodology, resources, quality, risk, improvements — but each contract's tender documents set the order and the wording. A template keeps you from leaving sections out; copying it as-is, without reordering it to match the award criteria, is one of the most common ways to lose points.
What must the technical proposal of a public-sector tender include?
Work methodology, human and material resources, service organization, timelines, quality control and the improvements you offer over what is required. The specific content is set by the tender document: the proposal must respond to its award criteria, in their order and with their terminology.
Why are points lost in the technical proposal?
For three common reasons: not responding to the criteria explicitly and locatably, making claims that can't be substantiated, and unbalancing the length relative to the weight of each criterion. On top of these comes the serious error of including economic information where it doesn't belong.
Can a bid be excluded because of an error in the technical proposal?
Yes. The most frequent case is including in the technical envelope economic information or information that can be scored by formula, which breaks the evaluation order of the procedure and can lead to exclusion.
Can the writing of a technical proposal be automated?
The part of locating, selecting and adapting your own material, yes — and it's the one that eats up the most time. The judgement about what to offer, the review and the sign-off remain human. Automating doesn't replace judgement: it removes the blank page.
Is responding to an RFP the same as responding to a public-sector tender?
No. A private RFP allows free formatting and negotiation; a public-sector tender is governed by the tender document, with legal deadlines, published award criteria and formal grounds for exclusion. If your case is the private one, go to automate RFP response with AI.
Conclusion
The technical proposal is won on two planes. The first is method: read the tender document by its criteria, structure the answer in its order, size it by points and back up every claim with a real document. The second is capability: making bidding on the next tender not cost the same as bidding on the first.
The method can be learned by reading. The capability requires that your company's knowledge —your proposals, your tender documents, your eligibility— be available and organized when the deadline arrives. That's where most companies lose, and not for lack of talent.
If you want to see how that process would look in your organization, and we'll review it with your real tenders.
Jordi García is Tech Lead at onext. He works on bringing AI into governed production across development and product teams —with Spec-Driven Development, context engineering and human verification at every step— and authors onext's technical insights on the method, quality and cost of applied AI.
LinkedIn →