Technical Specifications: Drafting Guide

Did you know that 30% of special appeals in public procurement are due to errors in the technical specifications?
Ambiguous specifications, brand mentions without the clause "or equivalent", or contradictions between documents are the most frequent causes of tender annulment.
The technical specifications (PPT) is the operational core of any file. While the specific administrative clauses (PCAP) defines the legal and administrative conditions of the contract, the PPT details the technical and functional specifications of the object to be contracted.
A precise drafting not only prevents the paralysis of the file; it guarantees that the administration receives exactly the provision it needs to serve the citizen. If the PPT is ambiguous, the contract execution will be conflictive.
In this guide, we break down the drafting process to transform an administrative need into a solvent, secure technical document open to free competition.
1. PPT Preparation Phase: Analyze Before Writing
The most common error is "copy-pasting" an old specification without questioning its validity. Before writing the first line of the technical specifications, the responsible officer must carry out an internal and external consulting exercise supported by analysis tools:
Tools for the preparation phase
- Analysis of similar contracts: Review equivalent tenders published by other administrations on the Public Sector Contracting Platform. What CPV codes did they use? Were there many queries or appeals?
- Preliminary market consultations (Art. 115 LCSP): The law allows consulting economic operators before starting the procedure to know innovative technical solutions and estimate realistic costs, always respecting non-distortion of competition (Art. 70 LCSP).
- Market intelligence: Use tools like aggregators and search engines to detect recent technical innovations (e.g., new efficiency standards) and avoid requesting obsolete technologies.
2. Drafting the Technical Specifications: Define the "What" Without Limiting the "Who"
Article 126 of the Law on Public Sector Contracts (LCSP) is clear: technical prescriptions must allow access under conditions of equality. How is this achieved in practice?
The performance approach
Instead of describing to the millimeter the physical characteristics of a product (which can unfairly point to a single brand), it is recommended to define functional or performance requirements.
- ❌ Limiting example: "Vehicle with 150 HP engine of brand X".
- ✅ Functional example: "Vehicle with sufficient power to reach 120 km/h on a 5% slope with full load and emissions lower than x g/km".
This allows different technical solutions to compete to solve the same need, increasing concurrence and improving the final price.
The "or equivalent" rule: essential clause
According to Art. 126.6 LCSP, when it is technically impossible to describe the object without referring to a specific brand, patent, or origin, it is mandatory to always add the mention "or equivalent".
Relevant jurisprudence: The Central Administrative Tribunal for Contractual Appeals (TACRC) has annulled numerous specifications for mentioning brands without this tag, even when the contracting authority argued that "it was the only compatible solution". The burden of proof always falls on the administration.
Safe formula: "Technical description conforming to [standard/norm] required, equivalent to [reference brand/model] or equivalent that meets identical technical benefits."
Search for similar files and access relevant databases:
3. Essential Structure of Technical Specifications
Although each file is unique, a solid PPT must maintain a coherent structure. Below, we detail the essential blocks:
| Section | Mandatory Content | Practical Example | Frequent Error |
|---|---|---|---|
| 1. Object and purpose | What is contracted and for what administrative need. | "Cleaning service of 15 buildings to guarantee hygienic-sanitary conditions". | Describing only WHAT without explaining FOR WHAT (hinders value proposals). |
| 2. Technical scope | Physical specifications, performance, SLA, and applicable regulations (ISO, UNE Standards). | "Daily frequency in common areas. Products with EU Ecolabel label". | Mixing technical specifications with solvency requirements (they go in PCAP). |
| 3. Execution conditions | Delivery deadlines, place, operations, and minimum assigned personnel. | "Cleaning from 6pm to 10pm. Response in 2h for urgent incidents". | Not specifying minimum personnel when critical (risk of labor dumping). |
| 4. Transversal criteria | Universal accessibility, sustainability, and energy efficiency. | "Equipment with A++ energy label. Accessibility according to UNE 170001". | Omitting environmental criteria, mandatory according to the LCSP (Arts. 201 and 202) and European Directives. |
| 5. Conformity criteria | How compliance will be verified (KPIs). | "Monthly random inspections. User satisfaction surveys". | Not defining quality control mechanisms. |
4. Documentary Coherence: The PPT-PCAP Binomial
One of the critical points where files often fail is the incongruence between specifications.
The technical specifications must be limited to aspects of the object. Everything regarding economic solvency, award criteria, penalties, or administrative procedure belongs to the PCAP.
Golden rule: If there is a discrepancy between the technical and administrative specifications, the PCAP prevails. That is why it is vital to ensure internal coherence. If the PCAP says the term is 12 months and the PPT says 15, we have a guaranteed legal certainty problem.
Connection between PPT and award criteria
Although the criteria are defined in the PCAP, they must draw directly from the PPT.
- Bad practice: The PPT asks for "standard cleaning" but the PCAP gives 20 points for "ecological products" (without defining them).
- Good practice: The PPT establishes "products with basic ecological certification as a minimum requirement". The PCAP awards points to those who offer "superior certifications type Cradle to Cradle". Thus, everyone meets the minimum and excellence is rewarded.
5. Validation and Quality Control with AI
Once the draft is written, how do we ensure it contains no errors that paralyze the tender?
Manual review is necessary, but fallible. This is where technology brings an extra layer of security. The use of AI-based writing assistants like Tendios allows:
- Detecting mentions of trademarks that forgot the "or equivalent" clause.
- Identifying solvency criteria (such as "previous experience") wrongly located in the technical specifications.
- Verifying regulatory coherence with the latest version of the LCSP.
Frequently Asked Questions About Technical Specifications
Who is responsible for drafting the PPT?
The contracting authority, normally through the technicians of the requesting unit (the service that has the need). In complex contracts, external technical assistance can be hired for its elaboration.
Can the PPT mention trademarks?
Only when it is technically impossible to describe the object in another way (e.g., spare parts, compatibility). In those cases, it is mandatory to add "or equivalent" (Art. 126.6 LCSP). Omission is a direct cause of nullity.
What is the difference between PPT and PCAP?
The PPT defines WHAT is needed (technical specifications, qualities). The PCAP defines HOW it is contracted (procedure, solvency, award criteria). The PPT is technical; the PCAP is legal.
Can the PPT be modified after publishing the tender?
Only through correction of material errors or clarifications that do not substantially alter the conditions. If the change is significant, it requires canceling and republishing or extending deadlines (Art. 136.2 LCSP). If the change is substantial, it will entail the retroaction of actions (Art. 124 LCSP).
Conclusion: A Well-Drafted PPT Is the Basis of Contractual Success
A robust technical specifications document is built on 5 fundamental pillars:
- Prior analysis: Review background and consult the market.
- Functional approach: Define services, not closed products.
- Clear structure: Object, scope, execution, and conformity.
- Documentary coherence: PPT and PCAP must be an ecosystem without contradictions.
- Rigorous validation: Detect legal risks before publishing.
Investing time in drafting the PPT is saving time in execution. It attracts better offers, reduces bidder queries and shields the administration against appeals.
Do you need to validate your technical specifications before publishing?
Avoid non-rectifiable errors and ensure free competition. Tendios AI technology analyzes your PPT and PCAP drafts, detecting inconsistencies, improper brand mentions, and legal risks in seconds.


