Questions to ask an application maintenance and support services vendor before you sign

Ask an application maintenance and support services vendor five things before you sign: who specifically will hold the knowledge about your system, how response and resolution are measured and who produces the numbers, what sits inside the retainer as against a billable change, how patching is done and evidenced, and what it costs to leave. Vague answers to any of the five predict the relationship.

This article gives you the five questions, the answer that should reassure you, the answer that should worry you, and the follow-up that separates a rehearsed pitch from an operator who has actually carried a pager.

What these questions are really testing

Any competent sales team can describe a support process. What you are testing is whether the people who wrote the proposal have run production systems, because operating software and selling the operation of software produce very different sentences. An operator talks about specific failures, measurement disputes and the awkward Tuesday when a certificate expired. A reseller of capacity talks about frameworks, coverage and commitment.

The second thing you are testing is where the incentives sit. Every maintenance contract contains a boundary between work the vendor absorbs and work the vendor bills. A vendor who is comfortable drawing that boundary precisely, in writing, before signature, is a vendor whose margin does not depend on ambiguity. A vendor who prefers to settle it later has told you how they intend to make money.

Run the questions with the people who would actually do the work in the room, not only the account lead. The gap between what a sales team promises and what a delivery team recognises as achievable is visible within about ten minutes, and it is the cheapest signal you will get all quarter.

The five questions and the answers to listen for

Ask each question directly and let the silence do some work. The table gives you the shape of a good answer and the version that should slow you down.

Question one: who exactly will hold the knowledge?

Maintenance is a knowledge business. The value is not in having engineers; it is in having engineers who remember why the settlement job runs at 03:40 and what happens if it runs twice. Ask for names, ask how many other accounts each person carries, and ask who the designated secondary is. Then ask what happens when the primary resigns, and listen for whether the answer contains a handover period or a reassurance.

The written form of this is the run-book. Ask to see a sample from an existing client, redacted. A vendor with a real run-book culture will have one ready. A vendor who promises to produce one during transition may be sincere, but you are now buying documentation as a project rather than inheriting it as a practice.

Question two: how are response and resolution measured?

Response and resolution are separate commitments, and only one of them is easy to hit. Ask which ticket system the clocks run in, whether you can export raw ticket data yourself, and what events stop the clock. A pause while awaiting customer information is legitimate. A pause the vendor applies at its own discretion makes any target achievable. Our guide to service levels that mean something sets out the definitions worth insisting on.

Follow up with a specific request: show me a month where you missed a target, and tell me what changed afterwards. Every vendor operating real systems has missed targets. The ones worth hiring can describe the miss, the cause and the correction without becoming defensive.

Question three: what is inside the retainer?

The boundary between defect, service request and enhancement determines most of what you will actually pay. Ask the vendor to classify five scenarios from your own history on the call, out loud. A rewritten report is which category? A change forced by a supplier's API deprecation? A performance problem that only appears at month-end? The answers tell you more than any clause, and disagreement discovered now is cheap. The document that fixes this properly is covered in what to put in a maintenance and support RFP.

Question four: how do you patch, and can you prove it?

Patching is the part of maintenance that is easiest to defer and hardest to detect. Ask for the cadence in weeks, the severity policy that triggers an out-of-cycle release, and the evidence log you will be able to read. The United States National Institute of Standards and Technology's guidance on enterprise patch management frames patching as routine preventive maintenance with measurable cadence rather than emergency response, and a vendor who treats it as the latter will always have something more urgent that week.

Ask one more question here: when did you last restore a backup to prove it works? Restore testing is the clearest single indicator of whether a support function is operating or performing. A vendor who can tell you the date and what broke during the test is a vendor who has done it.

Question five: what does leaving cost?

Ask this before you sign, because you will never get a clean answer afterwards. You want a notice period in months, a list of handover artefacts, an assisted-exit rate, and confirmation that you own the code, infrastructure, credentials, prompts and documentation throughout. Ownership should not be a negotiation; the glossary entry on code and IP ownership sets out the position any client should expect as standard.

Ask what state the system will be in on the day you leave. A vendor who has been quietly accumulating undocumented scripts, personal cloud accounts and manual steps hands you an estate that only they can run, and the switching cost becomes the real contract term regardless of the notice period. Requiring that every operational change lands in your repository, under your accounts, is a small clause with a large effect on your freedom three years later.

What this due diligence costs you

Three or four vendor calls of ninety minutes each, two reference calls, and a day to compare answers. Against annual spend, that is trivial: maintenance and support starts at $1,000 or ₹68,000 per month for business-hours cover with an eight-hour response, rises to $2,500 or ₹1,60,000 for 24 by 5 with a four-hour response, and $5,250 or ₹3,40,000 for 24 by 7 cover with a one-hour response and a named engineer. Applications with AI components carry a $750 or ₹40,000 monthly add-on for evaluation runs, cost monitoring and re-indexing. Published figures are on the pricing page, and a vendor who will not discuss their own numbers at this level of detail is telling you something.

Questions that sound useful but are not

Some due-diligence favourites reveal nothing. Headcount tells you about the vendor's sales pipeline, not your service. Certification counts tell you who paid for exams. A client logo wall tells you who bought something once, not who stayed. And asking whether a vendor can support your stack produces a yes from everyone, which is why the useful version is asking which parts of it they would rather not own.

There is also a point at which this process is over-engineered. If you run one small internal application with predictable load and no regulatory exposure, an hour-long conversation and a three-month trial will tell you more than a formal evaluation. Heavy due diligence is proportionate to blast radius, and buying it for a low-risk system is its own waste of money. For the harder cases, signs your vendor is out of their depth covers the warning signals that appear after signature rather than before it.

The reference call

Two reference calls are worth more than the whole proposal, but only if you ask operational questions rather than satisfaction questions.

• Who is your named engineer, and how many have you had? Turnover in the seat is the single best predictor of service quality.
• Describe your worst incident with them. You are listening for a narrative, not a score.
• What percentage of your work ends up as a change request? Anything above a third suggests a scope boundary drawn in the vendor's favour.
• How long did transition-in actually take against the plan? Overrun here predicts overrun everywhere.
• Who produces the service report, and do you check it? An unchecked report is not a measurement.
• Would you run the tender again, and would they win? The most useful question in procurement.

Related reading

A security questionnaire for vendors covers the parallel security review, and the university ERP modernisation case study shows what a long-lived support relationship looks like when the knowledge transfer was done properly. If you would like to run these questions past us before you use them on anyone else, get in touch.

Hire the vendor who answers precisely about the boring parts, because the boring parts are what you are actually buying.