Skip to content
All articles

After Launch: Hand Over, Measure, Improve

An AI solution that goes live without an owner slowly stops being used. Hand it over properly, measure real use, and improve it in small steps.

Published

A dark desk at night with a lamp, a small plant and an open binder holding a single blank sheet.

Imagine a company that launches an AI assistant to answer staff questions. The launch goes well, the project team is thanked and moves on. Months later, someone asks who updates the answers when a policy changes, and nobody knows.

The problem: "The project is finished, so everyone has moved on"

A launch feels like the finish line. The budget is spent, the team is thanked, and attention turns to the next priority. But a live solution is not a finished object. It depends on information that changes, on people who use it, and on systems it is connected to.

When nobody owns it, small problems pile up unseen. Answers go out of date. A connected system changes and something quietly breaks. Staff try it once, find it unhelpful, and go back to the old way.

What it costs

  • Silent decline: the solution keeps running, but its results drift away from how the business works today.
  • Lost trust: once staff meet a wrong answer with nobody to report it to, they stop relying on it.
  • Dependence on one person: if the only person who understands the solution leaves or changes role, nobody else can explain or fix it.
  • A weaker case for the next project: a launch that faded makes the following proposal harder to approve.

The turning point: treat the handover as part of the project

Handing over and improving is the last step of the process I follow, after Discover, Design and Build. It is planned from the start, not squeezed in on the final day.

  1. Document it. Write down in plain language what the solution does and must not do, where its information comes from, what it is connected to, and what to do if it fails.
  2. Name the owners. One named person looks after the solution day to day, and one named manager is accountable for it. A shared mailbox or "the technology team" is not an owner.
  3. Train the people. Train those who use it and those who look after it, using real situations from their own work rather than a general demonstration.
  4. Measure real use. Agree at the start which signs show it is helping: whether people open it, whether they come back, and whether the work it was meant to reduce is actually reduced. Review them on a regular schedule.
  5. Improve in small steps. Collect what users report, change one thing at a time, check the effect, and keep a record. Small steps are easier to test and easier to undo.
  6. Prepare for change. Decide beforehand what happens when a policy, a system, a supplier or a team changes: who is told, who decides, who updates the solution, and who checks that it still works.

What changes

The solution stays connected to the business after the project team has left. When a question comes up, there is a name to ask and a document to open.

Decisions about improvement rest on what people actually do, not on opinions. And changes arrive as small, checked steps rather than as a rushed fix after a complaint.

A solution that goes live without an owner is not finished. It is only unattended.

What this means for your company

Take any AI solution you already run, or plan to launch, and ask three questions. Who owns it today? Where is it written down how it works? How would we know if people stopped using it? Wherever the answer is unclear, start there.

This is the hand over and improve step of my AI solution build and delivery service: documentation, named owners, training, a way to measure use, and a plan for change. It is the same approach I apply in the AI solutions I have delivered for large enterprises and public-sector organisations over the past year.

If this sounds familiar and you would like to talk it through, the WhatsApp button on this page is the quickest way to reach me.