Most sourcing documents I read treat exit as punctuation. The transition clause arrives near the end, after the scope, the service levels and the pricing schedule, written in the calm voice of a thing nobody expects to use. It is drafted by people who are trying to start a relationship, which is precisely the wrong mood for the job.
The kick-off document for a service desk re-tender at a large European public-sector organisation did it the other way round, and it is the cleanest example of the practice I have on file.
The stated aim of that engagement was to manage the procurement of a first rate IT service desk. Underneath the aim sit six objectives. Five of them are what you would expect: analyse the current contract and its accompanying agreements, service levels and indicators; collect requirements from the business areas; design contract provisions informed by the supplier market; analyse that market; work out how adjacent support services might be folded into the desk. The sixth reads: recommend strategies for transitioning the service to a new provider with minimal risk.
Then, at the far end of the plan, in the phase where all the evidence is synthesised, the report is scheduled to make recommendations across three areas. Contract terms, penalties and motivation strategies built on the service levels. Options for integrating the adjacent services. And strategies for transitioning the service to a new provider with minimal risk.
The same sentence, near enough, opens the plan and closes it.
What the ordering buys you
Putting exit in the objectives rather than the annex is not a drafting preference. It changes three things before any work starts.
It changes what evidence gets gathered. The data gathering phase in that plan collects contracts and associated agreements, financial data, performance reports, organisation structures and profiles, and processes. Read that list as current-state material and it is a performance file. Read it as exit material and it is the same file, because everything you need to argue about how the incumbent is doing is also everything you need to move the service somewhere else. Gather it once, at the start, with both purposes declared, and you have an exit pack as a by-product. Gather it at the end, under a notice period, and you are asking the outgoing provider to help you leave.
It changes what the contract is allowed to hold. Objective three names three levers: terms and conditions, penalties, and motivation strategies using the service levels. A transition objective standing next to those three turns them from a compliance instrument into a design problem. If somebody has to be able to leave, the service levels have to describe an operation in terms a successor could reproduce, not in terms only the incumbent's tooling can produce.
It changes who gets asked. Requirements in that plan are to be collected from the business areas, through a workshop and up to twenty-five business users consulted in groups if required. Requirements written by the people who run the incumbent relationship tend to describe the incumbent. Requirements written by the people who consume the service describe the service, and only the second kind survives a change of supplier.
None of this was a delivered result. It is a page of intent, written on day one, and I am reading it as an argument about sequence rather than as evidence of an outcome.
Why the exit surface got bigger while nobody was updating the annex
Standard transition annexes were written for an operation made of people, runbooks and a ticket queue. Move the staff or replace them, hand over the documented procedures, repoint the telephony, migrate the ticket history. Painful, well understood, roughly bounded.
The operations we are now signing contracts around are not shaped like that. An ambitious service desk is now being built around a small machine learning estate: a classification model routing incoming tickets, a deflection layer sitting in front of the portal, a retrieval system over the knowledge base, forecasting against arrival volume, process mining across the ticket flow to find the paths worth automating, and a straight-through processing ambition on the high-volume, low-judgement work like password resets and access provisioning. Alongside that, in a handful of places I visit, an early language model pilot on knowledge article drafting, fenced off and watched.
Every one of those adds a thing that has to leave with you and usually cannot.
The labelled history is the obvious one, and the least of it. Harder: the taxonomy behind those labels, which is a set of human decisions about what counts as the same kind of fault, often living in the provider's configuration rather than in any document you hold. Harder still: the feature definitions. A feature store is a promise about where a value came from and what it means, and if it sits inside the provider's platform, the promise leaves when they do. Then lineage, the chain from a raw event to a number in a monthly pack, which is what lets a successor prove that the new figure and the old figure are about the same thing. Then the model artefacts themselves, their retraining cadence, their drift monitoring, their thresholds.
Ask for those at the end and you are negotiating for them. Ask for them in the objectives, and they are deliverables under a contract that has not been signed yet, which is the only moment your position is strong.
There is a second effect, and it is the one that surprises people. The better the automation, the worse the exit. A desk that has pushed a large share of its volume into straight-through processing tends, by construction, to let the human path for that volume waste away. Nobody has handled those requests manually in a long time, the procedure documents describing how go stale, and the staff who knew them move on. The automated path is the only path, and it belongs to the provider. Efficiency achieved this way is a transfer of capability out of the buying organisation, and it does not show up on any scoreboard until the day you try to leave.
The phase that produces nothing
There is a detail in that plan worth more than the transition language itself. Seven phases, each with an objective, a key output and a timeline band. Six of the seven name an output: the kick-off document, the recorded service levels and contractual terms, the business user requirements, the supply market report, the final report, and the signed-off version. One does not. The data gathering phase carries not applicable in the output column, and its objective is written as gathering the inputs needed to reduce project risk.
Writing that on a client-facing plan takes some nerve, because it funds and schedules a phase that hands over nothing anyone can hold. It is also correct. Some work exists to make the following work possible, and if it is not named it gets absorbed into the phase after it and quietly compressed.
Exit design is that same kind of work. It produces no artefact anybody wants during the term of a contract, and every incentive on both sides of the table points to deferring it. The only defence is a line in the plan with its own objective, the way that data gathering phase had one.
The rest of the governance in the document is built the same way, from things that are easy to skip. Four progress reviews at seven-day intervals inside a plan of a few weeks. One draft per deliverable with a week of client feedback written in as an assumption. Fifteen assumptions in total, carrying the whole risk treatment, since the agenda promised assumptions and risks and only the assumptions slide exists. Naming what you are assuming is the cheapest exit hygiene there is, and it is the first thing dropped when a document is written in a hurry.
Transition appears as an objective before anybody has looked at the incumbent, and again as one of three things the final report is scheduled to recommend. On this plan exit is not the closing chapter. It is a design input.
- 6
- Objectives at kick-off, transition one of them
- 3
- Recommendation areas planned in the final report, transition one of them
- 7
- Phases in the plan, six naming a key output
- 1
- Phase funded to deliver no artefact at all
What I would write into the entry
Name the exit deliverable at kick-off, with an owner, the way any other objective gets named. It costs a line and it changes what everyone gathers.
Define the estate that has to move, in the entry document, not the exit clause. Ticket history and the taxonomy that labels it. Feature definitions with the query that produces each one stored beside it. Lineage for every number that appears in a report. Model artefacts, training data and thresholds. Say who holds each item during the term, and say it while the supplier still wants the work. That schedule is where a RealAI Consult engagement on a renewal begins, because it is the one annex nobody can draft honestly under notice.
Keep one path you own. For any process that has gone straight through, retain a documented manual route and exercise it on a schedule, so the capability to run the service yourself for a few weeks survives the automation of it.
Test the transition during the term rather than at the end of it. A partial handover of one service line, done once, tells you more than any clause.
Look hard at how many bidders your market actually has. The kick-off assumed that no more than three vendors would respond to the tender and be evaluated. Exit rights in a market that thin are a document, not an option, and the honest response is to design a service that more than three organisations could plausibly run.
None of this is exotic and none of it needs new law. It needs the transition question to be asked at the moment the entry is being designed, by the same people, in the same room. That kick-off page did it in one sentence out of six, which is all it takes.
Read from the kick-off document of a service desk re-tender at a large European public-sector organisation: its stated aim, its six objectives, its seven-phase plan and its assumptions. A kick-off states what will be examined. It reports no findings and no results, and nothing above should be read as one. The argument about sequence is ours.
“Transition appears as an objective before anybody has looked at the incumbent, and again as one of three things the final report is scheduled to recommend. On this plan exit is not the closing chapter. It is a design input.”
Get in touch
Put RealAI’s applied-AI team on your hardest data problem.
We help enterprises move from pilots to production: sovereign models, governed data, and agents you can audit. Start with a value-first assessment.