What “done” should mean when you buy an AI system

When you buy a custom AI system, you are buying a change in how work gets done. A request should reach the right place. A reviewer should receive the right information. A failed step should leave the team with a clear next action.

Those outcomes need to be part of the definition of “done.”

A useful acceptance plan begins while the system is being scoped. It names what the team will check, which version it will check and what will happen if a step fails.

Take a simple example: an inquiry arrives and needs to become a tracker entry.

An acceptance statement might say: “An eligible inquiry creates one entry with the agreed fields, and the coordinator can see where it came from.”

Then add the cases that matter. What happens when a required field is absent? When the same inquiry arrives twice? When the tracker is temporarily unavailable? Who can correct a mistake?

These are illustrative conditions. Your own scope should use your actual tools, permissions and operating rules.

A message saying “saved” is useful feedback. The acceptance check should also inspect the saved record in the destination system.

The same principle applies to a document, an appointment or an update to a workflow map. The evidence should show that the intended change persisted, and that unrelated information stayed intact.

In a recent public exercise of the Utlyze advisor, we asked for a narrow change to a fictional workflow. The check compared the stored map before and after the request. A separate summary check confirmed that describing the map did not edit it. That is a concrete boundary: the system should make the requested change and preserve the rest.

Testing a development version is one step. The team also needs to establish that the released version contains the accepted change.

Ask for a short release record: what changed, which checks passed, where the system was released and how the live result was verified. Ask for the known limitations too.

A test performed in a phone-sized browser window, for example, does not establish that every physical phone and microphone has been tested. A fast summary response does not establish the time needed to generate a new workflow map. Specific evidence helps you judge whether the proof fits the job.

A workflow needs a person or team responsible for exceptions after release.

If a destination is unavailable, someone should be able to see whether the request is waiting, failed or has an uncertain result. An uncertain result needs checking before another attempt: otherwise, a retry may repeat an action that already happened.

Agree on how to stop the affected step and return to a working process. Keep that recovery plan proportionate to the job. A simple internal update and a customer-facing action carry different consequences.

The questions are straightforward: What should happen? What should happen when it cannot? Where is the saved result? Which version was checked? Who owns the next action?

Bring one recurring job to the Utlyze advisor. We can start by making that work visible, then scope the system and the proof it needs.

Map one job with Utlyze.