What to put in an application maintenance and support services RFP

An application maintenance and support services RFP should contain six schedules: an inventory of every system in scope, service levels that separate response from resolution, acceptance criteria for transition-in, a pricing schedule with a named change mechanism, a security and data schedule, and an exit clause. Without all six, the bids you receive will not be comparable.

This article walks through each schedule in the order a procurement document usually sets them out, shows the wording that removes ambiguity, and gives you a scoring matrix for the responses. It also says plainly when an RFP is the wrong instrument for the job.

Why most maintenance RFPs come back with incomparable bids

A maintenance RFP is not a build RFP. A build has a finish line, so a vendor can price the distance to it. Maintenance has no finish line, so the vendor is pricing a probability distribution: how often will this thing break, how deep will each fix go, and who decides what counts as a fix rather than a new feature.

When the document leaves that undefined, each bidder resolves it with a different private assumption. One prices a small retained team. One prices a ticket queue with an offshore first line. One prices the minimum and expects to recover margin on change requests. The spread between them looks like a commercial difference. It is actually three different readings of your own requirement.

The fix is not a longer document. It is a document that pins down the five variables a bidder cannot guess: what is in scope, what good looks like, who arbitrates classification disputes, what happens when volume moves, and how the relationship ends.

The six schedules an application maintenance and support services RFP needs

Each schedule answers one question a bidder would otherwise have to assume. Put them in the RFP as numbered annexes so responses can be compared line by line.

How to write the scope of work so it cannot be read two ways

Start with an inventory, not a description

Do not write a paragraph about your estate. Write a table with one row per application, naming the runtime version, the hosting arrangement, the integrations it publishes and consumes, the number of active users, and the ticket volume from the last twelve months. A bidder who sees a Java 8 service on an unsupported database will price the upgrade honestly. A bidder who sees only "our order management platform" will price a guess.

Define the ticket taxonomy yourself

The single most expensive ambiguity in application maintenance and support services is the boundary between a defect, a service request and an enhancement. Define all three in the RFP, give two worked examples of each from your own history, and name the person on your side who arbitrates when a classification is disputed. If the vendor writes the taxonomy after signature, the taxonomy will favour the vendor.

Write the exclusions down

State what is explicitly out of scope: new modules, data migrations, third-party product upgrades, penetration test remediation beyond a stated severity, and anything touching a system not on the inventory. Exclusions protect the bidder as much as you, and a bidder who can see the fence prices the field inside it more tightly.

What service levels should the RFP specify?

Specify priority definitions, the clock for each priority, the hours during which the clock runs, and how the measurement is produced. Response and resolution are separate commitments, and an RFP that asks only for response times will get four bids that all promise fifteen minutes and none that promise a fix. The distinction is set out in our guide to service levels that mean something and defined in the glossary entry on response versus resolution.

Ask for the measurement method, not just the number. Who runs the reporting tool, can you see the raw ticket export, and what stops the clock? A pause for "awaiting customer" is reasonable; a pause that the vendor applies unilaterally is a way to make any target achievable. Google's site reliability engineering material on service level objectives makes the same point for internal teams: an objective without an agreed indicator and measurement window is not an objective.

What should the commercial schedule ask for?

Ask for a monthly retainer, the hours it includes, the rate for hours beyond it, and the rate for change requests, as four separate numbers. Our own published structure is a useful shape to request: software maintenance and support starts at $1,000 or ₹68,000 per month for business-hours cover with an eight-hour response and ten hours of work included. The Standard tier at $2,500 or ₹1,60,000 per month gives 24 by 5 cover, four-hour response and twenty-five hours. Enterprise at $5,250 or ₹3,40,000 per month gives 24 by 7 cover, one-hour response, sixty hours and a named engineer. If the application carries AI components, an add-on at $750 or ₹40,000 per month covers evaluation runs, cost monitoring and re-indexing. All published figures sit on the pricing page.

Then ask what happens when volume moves. A retainer priced for eighty tickets a month behaves badly at two hundred. Require each bidder to state the band their price assumes and the mechanism for moving between bands, so the first busy quarter produces a tier change rather than an argument. The contractual detail behind this is covered in what should be in an AMC.

Scoring the responses

Weight the matrix before you open a single bid, and publish the weights in the RFP. Six criteria are usually enough.

• Evidence of comparable estates. Two references running the same stack at similar volume, contactable, not a logo wall.
• Named team and continuity. Who holds the knowledge, what their notice period is, and what happens when they leave.
• Transition-in plan with an acceptance test. A date on which the incumbent can be released, with criteria you can verify.
• Measurement transparency. Raw ticket data exportable by you, not a monthly slide.
• Proactive work included. Patching cadence, dependency updates and backup restore tests inside the retainer, not billed as changes.
• Total cost over three years. Retainer plus expected overage plus expected change requests, not the headline monthly figure.

When an RFP is the wrong instrument

If you cannot produce the inventory, an RFP will not save you. Running a competitive process over an estate nobody has mapped produces confident bids that all get renegotiated in month three. Buy a short paid assessment first, from one or two vendors, and use its output as the scope annex for the real RFP.

An RFP is also the wrong instrument when the application is about to be replaced. Paying to onboard a maintenance vendor onto a system with eighteen months left rarely pays back. Keep the incumbent on a short extension and put the money into the modernisation programme instead. And if the estate is one small application with predictable load, a two-page statement of work and a direct conversation will get you a better outcome in a tenth of the time.

What transition-in actually looks like

A university that had run its student and finance systems for fifteen years took this route before any modernisation began: inventory first, then a shadowing period in which the incoming team worked tickets alongside the people who had always fixed them, then an acceptance test that closed out the handover. That groundwork is what made the later ERP modernisation without a rewrite possible, because by then someone could describe the system accurately.

Before you issue the RFP

• Export twelve months of ticket history and classify it yourself before anyone else does
• List every application, version, integration and licence on one page
• Write your own definitions of defect, service request and enhancement, with examples
• Decide the hours of cover you actually need, by system, not by habit
• Name your arbitrator for classification disputes and your service owner
• Set the evaluation weights and circulate them internally before bids arrive
• Agree internally what you will do if every bid is above budget

Related reading

The companion piece on questions to ask a maintenance and support vendor covers the conversation after the paperwork, and the hidden costs that quotes leave out explains why the cheapest response is rarely the cheapest year. If you would rather test the shape of a requirement before committing it to a formal document, talk to us and we will tell you which schedules matter for your estate.

A maintenance RFP earns its keep in the schedules nobody enjoys writing, because those are the only parts a vendor cannot answer with optimism.