IT tenders
IT maintenance tender: a technical response, annotated
A fictional technical response for an application maintenance tender: what the buyer scores, the security assurance plan and the mistakes that cost points.
In an IT services tender, the buyer mainly scores what you will do with their system: how you take it over, how you maintain it, who works on it and how you hand it back at the end. Here is a fictional example, built for illustration, and what the buyer looks for in each section.
The case: maintaining a library network portal
Cotelle Informatique (a fictional company with 35 employees) bids for an application maintenance contract (TMA in French tenders): corrective and evolutive maintenance of the library network portal of a group of municipalities, for three years. The consultation rules set two criteria: technical value 60%, price 40%. Technical value splits into maintenance method (25%), assigned team (15%), takeover (10%), security (5%) and reversibility (5%).
First rule: follow the response template. Many IT tenders impose a technical response template, with its own headings and sometimes a page limit. The buyer compares bids heading by heading; an answer that leaves the template scores poorly.
1. Understanding the existing system
What the buyer looks for: proof that you read the technical specifications and their annexes, not a company brochure.
In the example, Cotelle Informatique restates what it understood: a web application built on a common PHP framework, about 40,000 reader accounts, peaks of activity in September, hosting run by another provider. It also recalls the two questions asked during the consultation, on the existing documentation and access to test environments.
The common mistake: pasting the company brochure. It belongs in an annex, not here.
2. Takeover (10%)
What the buyer looks for: how you will take over from the outgoing provider without interrupting the service.
The example plans six weeks of takeover: an inventory of the code and documentation, knowledge transfer with the outgoing provider, a gradual ramp-up, then a committee that approves the switch to maintenance. What the buyer must provide is listed: access to the code repository, the environments and the open requests.
The common mistake: a "turnkey" takeover with no duration and no deliverables. The buyer can't score it.
3. Maintenance method (25%)
What the buyer looks for: the path of a defect, from report to production release, and service levels you will meet.
The example describes how each request is qualified, three severity levels each with a response time and a fix time, acceptance testing before every release, and a regression test run on the critical paths: catalogue search, reserving a document, the reader account. Every change gets an estimate that the buyer approves before any development starts.
The common mistake: promising shorter times than the specifications ask for without the people to meet them. Once the contract is awarded, they bind your company.
4. Assigned team (15%)
What the buyer looks for: named people, their role, their time on the contract and their experience with the same technology.
The example names a project manager, two developers and a security lead, with their allocation, attaches their CVs and names a backup for every role.
The common mistake: CVs of people who will never work on the contract. The buyer can require that they are actually assigned.
5. Security: the security assurance plan (5%)
What the buyer looks for: how you protect their data and access, in a way they can check.
France's standard terms for IT contracts (CCAG-TIC 2021) let a buyer annex a security assurance plan (PAS) to the technical offer; it becomes contractual once the contract is awarded. The example sums up its commitments: named accounts with two-factor authentication, access logging, security patches applied within a set time, reader data processed as a processor under the GDPR, and an alert to the buyer in case of an incident.
The common mistake: declaring measures the company doesn't apply yet. The PAS binds you as much as the rest of the bid.
6. Reversibility (5%)
What the buyer looks for: the assurance that they can change provider at the end of the contract.
In the example, the code goes into the buyer's repository from day one, the documentation is updated with every release, and a reversibility plan sets the duration and content of the handover to the next provider.
7. Similar references
Three comparable maintenance contracts, with the buyer, the period, the technology and the volume of requests handled, plus one line on what makes them comparable.
Key takeaways
- Follow the response template and the order of the criteria in the consultation rules.
- Name the team actually assigned, with CVs.
- Promise only the service levels and security measures you meet: they become contractual.
- Plan reversibility from the takeover onwards.
We write the technical response for your IT services tenders, including the security assurance plan when the tender file asks for one: see the tender response offer.