Support contracts grow by default. Write one that shrinks

Support contracts tend to grow. Knowledge of the system accumulates on the supplier’s side, because its people are the ones solving the problems. The client’s own team has fewer and fewer reasons to learn. Two years in, the scope is larger, the price is higher, and leaving the supplier looks riskier than it did at the start.

Nobody planned it. That is simply how the interests line up when the contract does not align them.

Where dependence comes from

Knowledge in people’s heads. Runbooks never get written because “our engineer knows what to do”. That works for exactly as long as that engineer stays on your system.

Pricing that grows with success. A fee per user or per request means the better the system works, the more it costs to run — whether or not there is more work.

A dashboard instead of decisions. A dashboard nobody opens builds no understanding on your side. A short note that somebody reads and responds to does.

No criteria for taking over. Without written conditions for when your team takes over a given task, the right moment for it never arrives.

What shrinking looks like in practice

It is not a single handover at the end of the contract. It is a repeating cycle in which something moves to your side every month. Each month ends with the question of what changes hands this time, and with the answer written in the note rather than kept in somebody’s memory.

Infographic

A monthly cycle that reduces dependence

1. 01MeasureQuality, cost and latency against the baseline.
2. 02Write upOne page: what changed, what broke, what it cost.
3. 03DecideRecommendations accepted or rejected by your system owner.
4. 04Hand overOne routine task moves to your team, with a runbook.

Routine first. Re-indexing, cost review, handling the common alerts. With a runbook and after doing it together a few times, not after one presentation.

Model changes next. Checking a new model version against the evaluation set takes experience and judgement. It moves across once your team has done it several times alongside the supplier and knows what to look for.

Rare incidents last, or never. Some organisations deliberately keep a small external tier for serious quality incidents. That is a sensible choice, as long as it is a choice and not the state the contract simply got stuck in.

What the contract should say from day one

A written reduction schedule. Which support tier applies when, and under what conditions.

Testable criteria for taking over. What your team must be able to do for a task to move to its side, written so that it can be checked rather than declared.

Pricing per system and scope. Not per user or per request, so the fee does not rise because the system succeeded.

Exit terms. What is handed over, in what format and within what window, agreed at the start while you still have negotiating leverage.

What it asks of you

A contract does not shrink through the supplier’s efforts alone. There has to be somebody on your side who takes over.

People with time in their schedule. Whoever is to take over the routine needs hours for it, not “spare moments”. Without that, the reduction schedule stays on paper, and the supplier has an honest reason to hand nothing over.

Taking part in the work, not in presentations. Running an incident or an upgrade together teaches more than any training session about them. The first tasks taken over go more slowly, and that is a cost worth planning for rather than being disappointed by.

A decision that you want to be able to do it. Some organisations deliberately do not build this capability in-house. That is legitimate, but then it is worth writing down and costing as a permanent expense, rather than pretending the contract will shrink.

How to tell it is working

After, say, a year, your team runs the routine work and knows the evaluation set. External support covers the rare and difficult things. The monthly note is shorter, because there are fewer surprises in it.

If after a year the contract is the same size or larger and your team knows no more about the system than at the start, that is the signal — however good the availability figures look.

The second signal is subtler: the team has taken over the tasks but still asks the supplier about every unusual decision. Then what was handed over was execution, not understanding, and the contract has shrunk only on paper.

In AI managed services we work to a simple rule: if the support tier is not declining, one of us is not doing the job.