Suppose you change AI suppliers and download every customer conversation. The files open. The messages are there. Then someone asks which customers still need a reply.

One response was drafted but never approved. Another was sent. A third may have been sent, but the system never received confirmation. Can your team tell them apart from the records it has?

For businesses buying AI assistants that manage requests and take actions, that question deserves a place in the demonstration.

What the download needs to tell you

A conversation archive can be complete as a record of words and incomplete as a record of work. The customer’s question and the proposed answer may both be present, while the review decision sits elsewhere. A status label may say “complete” without explaining whether that means drafted, approved or sent.

The distinction matters because someone has to act on those records. If an unanswered request looks finished, it can be overlooked. If a completed action looks pending, it can be repeated. Neither problem requires the AI to have written anything inaccurate.

This changes what a buyer should ask to see. Alongside the quality of the assistant’s replies, examine whether its records let another person take responsibility for the next step. That includes the evidence for an action, any review still required and who is allowed to continue.

A polished answer is easy to inspect during a demonstration. The unfinished work is less visible, yet it is what the next operator inherits.

Three replies, three different decisions

Consider three sample enquiries, each with a finished-looking response.

The first response is awaiting review. Its next step is approval or correction by the person responsible. Moving it into a new system should not turn it into an approved reply.

The second has been accepted by the sending service. There is a record of that acceptance. It should not be sent again simply because it appears in an imported list. Acceptance does not establish that the customer received or read it; delivery failures and subsequent responses still need their usual handling.

The third is more awkward. The assistant requested a send, but the connection failed before it received a result. The message may have gone out. It may not have. A fresh assistant cannot settle that uncertainty by writing another answer or treating the attempt as failed.

Someone needs to check the sending service’s record. If the outcome remains unknown, a responsible person needs to decide how to proceed, taking account of the consequences of a duplicate or a missed reply.

This is the case I would put in front of a supplier. Can the export preserve an unresolved action as unresolved, with enough information to investigate it? A handover that quietly turns “unknown” into “not done” has changed the meaning of the work.

Try a small handover during the pilot

A suggested starting point is to create those three situations with sample data in a test environment. Agree a cutoff and record what each enquiry’s status and next action should be. Then use the supplier’s supported export and give the files, along with any permitted supporting records, to a colleague who did not build the pilot.

Ask that person to work out what to do next. Let the gaps become visible before explaining them away.

Perhaps the approval history is absent. Perhaps the export contains a link that only the original account can open. Or perhaps the files are entirely usable, but nobody has explained what a particular status means. These call for different repairs, from a supplier change to a short piece of documentation.

Keep permissions in the exercise. A colleague should be able to reach the records needed for their role without gaining access to material they are not entitled to see. Sample data lets the team examine that boundary without moving confidential customer messages into an unapproved service.

This is a proposed diagnostic exercise, not a validated recovery test. It can expose missing information in a small workflow. It cannot establish how a full migration would perform, and an integrated system may require a much larger rehearsal.

Decide which dependence is worth accepting

There is no need to demand that every useful feature be easy to replace. The UK’s Government Digital Service guidance on managing technical lock-in in the cloud recognises that integrated services can offer benefits worth some dependence. It advises organisations to assess the trade-off and test significant components rather than assume switching will be straightforward.

For an AI pilot, the practical choice might be to accept dependence on the supplier’s search and drafting tools while retaining a readable queue and a manual way to handle essential requests. During a transition, replies could take longer and complex cases might wait. Management can decide whether that reduced service is acceptable.

That is a more useful discussion than a general assurance that the business owns its data. Ownership matters, but it does not explain how the team will use the records on the day it needs them.

Before expanding the pilot, ask for the handover alongside the demonstration. Give a colleague the sample records and see whether they can distinguish a reply awaiting review, an action already accepted and an outcome that still needs investigation.

On Monday morning, the person taking over should know which requests need attention and what evidence supports the next step.