The demonstration was flawless: in ten minutes the tool sorted requests that had taken the team hours to arrange. Nobody asked what would happen if the vendor changed its price, a family asked to erase its information, or the model became unavailable in the middle of a campaign. The meeting ended enthusiastically, yet without answering the question that makes technology procurement responsible: how will we regain control when we choose to leave?
An exit is not decorative contract language#
An exit agreement does not signal distrust of a tool. It respects the people who will have to live with it. It should say which data can be exported, in which usable format, who can stop the service, how long stopping takes, and what extra work falls on the team. It should also name decisions that must never be locked inside a platform. Denying support, assessing someone, or sending sensitive communication needs a local accountable person who can genuinely correct it.
An exit agreement does not signal distrust of a tool. It respects the people who will have to live with it.
Consider a public library adding an assistant for patron questions. The pilot looks inexpensive because the advertised price counts only answers. It ignores cataloguing hours, telephone follow-ups, and checking bad recommendations. If the library keeps its questions, labels, and a short manual procedure, it can change tools without losing its service memory. If everything lives in the vendor dashboard, every later improvement is negotiated from a dependency nobody budgeted for.
Turn a preference into a test#
The practical way to avoid that trap is to rehearse departure before signing. Select a week of fictional requests, export the records, disable trial access, and ask someone else to handle the same case using the available documentation. The exercise shows whether the organisation owns its judgement or merely rents an interface. The fallback does not need to be elegant; it must protect people waiting for an answer while an incident is fixed.
The rehearsal also makes language more honest. Rather than promise that AI will “transform” a service, a team can state which task it speeds up, what data it uses, where errors are reviewed, and whom to contact when an answer does not fit. Useful transparency is not a display of vendor code. It makes the route of a decision visible to the person who bears its effects.
Before approving the next purchase, reserve ninety minutes to write an exit sheet with an owner and a date. Ask who can apply the brake, what remains available, and how three difficult cases would be served without the tool. If nobody can answer, a feature is not missing; a condition for autonomous use is.
Count the cost missing from the offer#
A tool’s monthly price is only one part of its cost. Count the hours needed to prepare data, review output, resolve complaints, train replacements, and keep an alternative alive. A simple table can separate time saved in a task from time created around it: for every hundred requests, how many need correction, how long correction takes, and what knowledge it requires. This is not a punishment for technology needing care; every public or community service needs care. The comparison prevents a burden from being called a saving when it has merely moved desks, usually toward the person least able to challenge it.
The cost conversation needs people who receive the result, not just people who sign. In a housing association, for instance, an automatic reply may save staff minutes while making neighbours with limited digital access repeat a question three times. That effort never appears on a vendor invoice, yet it belongs to the system. Asking how a response arrives, what happens when it is not understood, and whether a telephone or in-person route exists adds evidence that a speed metric cannot see. Responsible procurement examines the whole journey, from a question entering the service to a person understanding what they can do next.
Decide in advance who may say stop#
A workable exit needs authority, not only files. Before beginning, a team can name who may suspend a feature, which signals trigger suspension, and how to communicate without blaming the person who noticed a problem. Some signals are technical, such as an incomplete export; others are human, such as several people being unable to correct an answer or an explanation that cannot be given honestly. Writing them down frees an organisation from improvising under commercial pressure or haste. Stopping a use is not failure. It can be the decision that preserves trust, reviews harm, and makes a return possible on better terms.
The next purchasing meeting can end with a small measurable exercise. Choose an already anonymised real case, ask the vendor to show the export, and let someone outside the pilot handle it through the alternative procedure. Record the time, questions, and information that failed to appear. Then agree a correction with an owner and date, or decide not to buy yet. This practice returns the conversation to its proper place: not fascination with an interface, but the collective ability to sustain a dignified service when the interface is no longer there.
Who owns the service memory?#
An exit test is more than downloading a table. Useful organisational memory is scattered across instructions that worked, labels through which a team understands a request, corrections made to an answer, and reasons for deciding not to automate a case. When that memory survives only as opaque configuration, an export can be technically complete and still fail the people who need to continue the work. Decide which record the organisation keeps somewhere readable without the vendor, how long it is retained, and who periodically checks that the export makes sense. The task looks administrative until an incident occurs. Then it prevents the first week without a platform from also becoming the first week without judgement.
An association coordinating support visits can make this a monthly practice. Select four closed cases, save a readable version of their minimum data, and ask someone who did not join the pilot to reconstruct the service from that material. If they must open five tabs, interpret codes without a key, or ask someone who has left, the exit plan remains a promise. If they can explain what happened, what was done, and what is still pending, the team retains a capability that does not depend on a subscription. This matters especially when a person asks for correction: they should not be trapped by a company’s commercial calendar in order to exercise a basic right.
Leaving also needs a price. Migration is not merely an export fee; it may mean training the recipient, adapting templates, communicating a change, and maintaining a manual route for several weeks. Listing those costs beside the purchase price changes an overly cheerful comparison of offers. Take one precise question to the next meeting: “If we cancelled on Friday, what would we do at nine on Monday?” Write down the answer, name an owner, and test one small part. Autonomy does not arrive on the day of rupture; it is built while choosing remains easy.
An exit you can explain#
Keeping data is different from keeping the ability to explain. When a person asks why they received a recommendation, what information was used, or how an error was corrected, the team should be able to answer with its own documents and language that does not depend on a vendor dashboard. Preparing that answer means deciding which captures, rules, and versions are retained during ordinary use. It also means separating information needed to continue a service from information that should be deleted on departure. That precision protects privacy and prevents a backup from becoming another endless archive that nobody can interpret.
When comparing tools next time, request a reverse demonstration. Instead of asking for another feature, give the vendor a closed case and ask them to show how its data are recovered, how a correction is recorded, and how a person’s access is disconnected. Note who performs every step and what cannot happen without outside help. The exercise does not aim to embarrass anyone; it reveals the real distribution of power. Responsible procurement does not promise a painless departure. It makes costs visible, retains a proportionate alternative, and lets an organisation honour its commitments even when its technology changes.
