Technical proposals for Spanish tenders: how to prepare one and what changes when an AI writes it

What is the technical proposal in a tender?

The technical proposal, sometimes called the technical offer (in Spanish, the memoria técnica), is the document in which a company explains how it will deliver the contract: the methodology it will follow, the team it will put on it, the resources it will commit and the timescales it will work to. It is not a description of what the company is; it is an account of what the company will do on this particular contract. It goes in alongside the administrative documentation, which shows you are eligible to take part, and the price offer, which sets the price. Each of the three is evaluated in a different way.

The rules are in the specifications. The PCAP (the administrative specifications, Pliego de Cláusulas Administrativas Particulares) sets out, among other things, how bids are scored and what documentation has to be provided; the PPT (the technical specifications, Pliego de Prescripciones Técnicas) describes the technical requirements of the service, supply or works. The proposal has to answer to both: comply with what the PPT demands and score on what the PCAP rewards. It pays to separate, from the outset, minimum requirements, criteria that earn points and matters that simply describe how the work will be done. The three are not written the same way.

What the contracting body looks for when it evaluates one

Whoever evaluates a technical proposal does so with the scoring grid open beside it. The award criteria are what divide up the points: some are automatic, such as a price formula, and others rest on a technical assessment of the proposal. The proposal competes for the second kind. So the document is not judged on how well it reads, but on how easily each criterion can be found in it and shown to be properly dealt with. What is usually asked for, with variations from one tender to the next, is this:

• Methodology: how the work will be done, and why that way.
• Work plan and schedule: phases, milestones and deadlines.
• Team and organisation: who does what, how much of their time is committed and what experience they bring.
• Technical resources: the tools, facilities and equipment assigned to the contract.
• Quality processes, an implementation plan and risk management.
• Indicators and monitoring: how you will show that the service is working.
• Improvements and additional commitments, where the specifications score them.

How to prepare a technical proposal, step by step

1. Read the specifications in full, annexes included. Note the award criteria and the points behind each, the technical requirements, any page or length limits, the mandatory formats and the grounds for exclusion. Everything that follows rests on this reading.
2. Build the table of contents from the criteria, not from your last proposal. Every criterion that rests on a technical assessment needs a section of its own, and the space each section gets should be in proportion to the points it carries.
3. Settle the strategy before you write. What the contracting body really values, what evidence your company can bring, which strengths deserve prominence, which weaknesses need handling and which commitments it is reasonable to make.
4. Write from evidence. Every claim should rest on something real: a project you have delivered, a named member of the team, a certification, a procedure that already exists. Anything that cannot be backed up has no place in the proposal.
5. Check it against the specifications. Requirements left unanswered, criteria only half covered, sections that contradict one another, page limits exceeded and anything that does not line up with the price offer or the administrative documentation.

The mistakes that cost the most points

Most of what goes wrong in a technical proposal has the same root: it was written from what the company wanted to say rather than from what the specifications ask for. The mistakes are easy to spot once you know what to look for, and they are almost always found late, with the deadline bearing down. These are the most common:

• Reusing the proposal from another tender without going back to the criteria. The methodology may still serve; the table of contents and the page allocation almost never do.
• Writing about the company instead of the contract. The evaluator is not after a corporate brochure; they want to know how this service will be delivered.
• Making commitments nobody has signed off. Whatever the proposal promises is what you will have to deliver if you win.
• Going over the page limit or ignoring the required format. No extra paragraph is worth that risk.
• Contradictions between the technical proposal, the price offer and the administrative documentation: a different team in each, timescales that do not match.
• Leaving a criterion thinly covered because it looked minor. The points it carries are not.

What changes when the AI writing it has read the specifications

A general-purpose AI model can help you read the specifications or draft a paragraph. What it lacks is context: it does not know your company, it does not know how the points are distributed and, where it is short of information, it tends to fill the gap. A proposal that claims capabilities the company does not have is not a rough draft to be polished; it is a liability. The difference is not in writing faster. It is in writing from the tender file and from what is actually true of the company.

What the system does

This is how Carabela works on the technical proposal. It reads the specifications and the annexes and turns the criteria, requirements and limits into a structure, the same work it does in tender analysis. On that structure it builds the table of contents and allocates the content according to the scoring. It drafts the methodology, work plan, team, resources and the remaining sections from your company's own documentation and its real capabilities. Then it checks the document for internal consistency and against the specifications. It does not invent capabilities that nothing backs up.

What stays yours

The strategy, the commitments and the signature belong to the company. You can validate each commitment before it goes into the proposal, or approve the complete file before anything is submitted: the level of autonomy is set for each company, and nothing goes out without that approval. The whole process, from opportunity to a bid ready for signature, is shown in the product demo. No proposal guarantees the award: that decision belongs to the contracting body. What changes is how many bids you can prepare, and how consistently.