The short answer
An AI deployment baseline is a record of how a specific piece of work ran before anything changed, captured before the deployment rather than reconstructed after it. Without one, impact cannot be demonstrated later even when it is real.
The hardest word in measurable business value is measurable. Many deployments begin without any record of the prior state, which leaves the team in an awkward position months later: the system is working, the people using it say it helps, and nobody can produce a number that shows it.
A usable baseline is narrow and it is cheap. Six fields on one named activity, captured in the weeks before go-live, from the people performing the work. That is enough to make an impact claim defensible, and the window to collect it closes the day the deployment starts.
Key takeaways
- A baseline captured after a change is a reconstruction, and reconstructions are challengeable.
- Six fields on one named activity are enough. Breadth is not what makes a baseline usable.
- System data supplies duration and volume, and it omits the effort spent outside the systems.
- The exception rate matters more than the average, because exceptions are where the handling cost concentrates.
- A baseline needs a named owner, since an unowned measurement gets redefined when the result is inconvenient.
- The absence of a baseline is the most common reason a working deployment cannot be funded for expansion.
What is an AI deployment baseline?
An AI deployment baseline is a documented measurement of how a defined unit of work was performed, how long it took, how often it failed and what it cost, recorded before an AI system changes any part of it.
The definition contains three constraints that are usually what goes wrong.
It covers a defined unit of work, not a function. Per invoice, per claim, per ticket, per candidate. A baseline for the finance department measures nothing comparable afterward.
It is documented, which means written down with its method and its date. A number in a slide from a workshop does not survive a challenge nine months later.
It precedes the change. A measurement taken after go-live describes a process that is already different, and estimating backwards from it imports exactly the assumption the baseline was supposed to remove.
Published frameworks place this before deployment rather than alongside it. The NIST AI Risk Management Framework defines Measure as a function requiring metrics appropriate to the context, with Map, establishing that context, placed ahead of it. ISO/IEC 42001 requires objectives for an AI management system and assessment against them, which presumes a prior state exists to assess against. ISO 21502 treats benefits realization as a distinct practice with its own ownership, separate from delivering the thing that produces the benefit.
Why does the baseline go missing?
Four reasons, and none of them is carelessness.
The deployment is the exciting part
Attention goes to the model, the integration and the interface. Measuring the current state feels like administrative work standing between the team and the build, and it gets deferred until it is impossible.
Nobody owns the prior state
The team deploying owns the new system. The team performing the work owns the current process. Measuring the current process so somebody else can be evaluated against it is nobody's objective.
The current process was never measured at all
In most organizations the activity about to be automated has no duration, no exception rate and no cost per unit on record. Establishing one feels like a project, so it is skipped in favour of a plausible estimate.
An honest baseline can be unflattering in both directions
A measurement might show the current process is faster than assumed, which weakens the business case. It might show it is far worse, which raises questions about why nobody noticed. Both make the measurement politically uncomfortable to produce.
Baseline window
What is available at each point in a deployment
| Point | Baseline obtainable | Quality |
|---|---|---|
| Before the project starts | Yes, from the people doing the work | Strong |
| During build, before go-live | Yes, with effort | Strong |
| During a pilot | Partly, from the non-pilot group | Moderate |
| Shortly after go-live | Reconstruction only | Weak |
| Months after go-live | Memory and system logs | Unusable for a claim |
The window closes at go-live. Everything after that row is an estimate of the past made by people who have adapted to the present.
The six fields
One table per activity. This is the whole artifact.
| Field | What to record | Source |
|---|---|---|
| Unit of work | The thing processed, named as the team names it | The people doing it |
| Volume | Units per week or month, with seasonality noted | Systems, confirmed by the team |
| Handling time | Minutes per unit, including the parts outside the systems | The people doing it |
| Exception rate | What proportion departs from the normal path, and what happens then | The people doing it |
| Cost per unit | Handling time converted at a loaded rate, plus any direct costs | Finance, from the above |
| Quality definition | What makes an output acceptable, with examples | The team and its internal customer |
Two fields carry most of the weight and both are undocumented in most organizations.
Handling time including work outside the systems. System data records when a case opened and closed. It does not record the eleven minutes spent correcting an input before the case was opened, which is frequently the work the AI is meant to remove.
The exception rate. Averages conceal the handling cost, because exceptions take several times longer than the normal path. A process with a six percent exception rate where exceptions take ten times as long has a different economics from one at six percent where they take twice as long, and the average hides the difference.
What system data can and cannot supply
| Element | From system data | Needs the people doing the work |
|---|---|---|
| Volume | Yes | Confirmation of what the system misses |
| Elapsed time per case | Yes | Separation of work from waiting |
| Active handling time | No | Yes |
| Work performed outside the systems | No | Yes |
| Exception frequency | Partly, if exceptions are flagged | Yes, since most are not flagged |
| What happens during an exception | No | Yes |
| Quality threshold | No | Yes |
The second column is the reason a baseline cannot be produced from a data pull. Four of the seven elements exist only in the practice of the people performing the activity, and three of those four are the ones that determine the cost.
How to build one in two weeks
Six steps. The constraint is the go-live date, not the method.
1. Pick one activity, not a function
The narrowest unit the deployment will touch. A baseline on one activity is defensible. A baseline on a department is a collection of averages nobody can compare against later.
2. Ask the people performing it for handling time and exceptions
Not an opinion survey. How long does one of these take you, what do you do when it is not standard, how often is that, and what do you do then. These two questions produce four of the six fields.
3. Pull volume from the systems and confirm it with the team
The system count is usually right and usually incomplete, because work handled outside it never became a record.
4. Write the quality definition with three real examples
Three acceptable outputs and three unacceptable ones, from actual cases. This field is what prevents the post-deployment argument about whether the faster output is as good.
5. Convert to cost per unit with finance, once
A loaded rate applied to handling time. Doing this with finance at the baseline stage rather than at the claim stage removes the most common objection to the eventual number.
6. Name an owner and date the document
One person accountable for the baseline, and the date it was captured. An unowned baseline gets redefined when the result is inconvenient, and an undated one cannot be defended as having preceded the change.
What to do when the deployment already happened
Three options, in descending order of strength. None of them is as good as a real baseline and all three are better than nothing.
Use a comparable unmodified population. Another market, another team or another product line still running the old way. This is a genuine comparison rather than a reconstruction, and it is the strongest available substitute.
Reconstruct from system data and state the gap. Elapsed times and volumes are recoverable. Publish the number with an explicit note that active handling time and work outside the systems are not included, which makes the figure conservative and defensible rather than optimistic and fragile.
Measure forward and claim only the trend. Start measuring now, properly, and make a claim about the direction over the following quarters rather than about the improvement already delivered. Smaller claim, and it survives scrutiny.
What does not work is asking people to recall how long the task used to take. Recall after adaptation is unreliable in a consistent direction, and a figure produced that way tends to collapse the first time somebody checks it.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform. Its relevance to baselines is that four of the six fields come only from the people performing the work, and collecting them by hand is the reason the baseline gets skipped.
Discovery Cycles run AI-led interviews asynchronously with everyone in scope, asking what the activity involves, how long it takes, where it waits, what happens when it is not standard and how often that is. Those questions produce handling time, exception rate, the work performed outside the systems and the quality threshold, which is the part a data pull cannot reach.
The Process Library holds the described activity including the steps that leave no system record, dated, so the baseline can be shown to have preceded the change. The Insights Dashboard attaches hours to findings with traceability to the inputs behind them, which is what converts a baseline into something that survives a challenge. The Initiatives Dashboard carries each candidate into a business case with the baseline attached and a named owner, which is where accountability for the measurement sits.
At SURA, a cycle produced 63 insights across 600 employees with five systems integrated, in under seven days against a three-week baseline, and the engagement reported a 186% return. Under seven days is the figure that matters for this problem: a baseline exercise at that duration fits inside the weeks before a go-live rather than competing with the build for schedule. These figures describe one engagement and they are evidence rather than a guarantee.
The question worth asking before any deployment: do we have a dated record of handling time, exception rate and cost per unit for the activity we are about to change, and did it come from the people doing the work?
Baseline template
| Field | Value | Source | Date |
|---|---|---|---|
| Activity | |||
| Unit of work | |||
| Volume per month | |||
| Handling time per unit, active | |||
| Work performed outside systems | |||
| Exception rate | |||
| Handling time per exception | |||
| Cost per unit, loaded | |||
| Quality definition, with examples | |||
| Baseline owner |
Ten rows, one activity, one page. A deployment with this document attached can make a claim. One without it cannot, however well it performs.
Common mistakes
Deferring the baseline until after the build. The window closes at go-live, and nothing reopens it.
Measuring a function instead of an activity. Department-level averages have nothing comparable on the other side of the change.
Taking handling time from system logs. Elapsed time includes waiting and excludes the work done before a case became a record.
Reporting an average without the exception rate. Exceptions take several times longer and concentrate the cost, so the average describes a case that is cheap to handle.
Skipping the quality definition. Without it, the post-deployment discussion becomes an argument about whether faster output is equally good, with no reference to settle it.
Leaving the baseline unowned. A measurement without an accountable owner gets redefined when the result turns out to be inconvenient.
Asking people to recall previous durations after go-live. Recall after adaptation is unreliable in a predictable direction, and the figure does not survive a check.
FAQ
What is an AI deployment baseline?
A dated record of how a defined unit of work was performed before an AI system changed it: the volume, the active handling time, the exception rate, the cost per unit and what makes an output acceptable. It covers one named activity rather than a function, and it has to be captured before the deployment.
Why can't you measure impact after deployment?
Because there is nothing to compare against. A measurement taken afterward describes the new process, and estimating the old one from memory or from system logs reintroduces the assumption the baseline existed to remove. Recall after adaptation is unreliable in a consistent direction.
Can system data provide the baseline?
Partly. Systems give volume and elapsed time reliably. They do not give active handling time, work performed outside the systems, most exception frequency or the quality threshold, and those four are the elements that determine the cost of the activity.
How long does it take to build a baseline?
Two weeks for one activity, with most of the effort in asking the people performing it about handling time and exceptions. The binding constraint is the go-live date rather than the method, which is why the baseline has to be scheduled alongside the build rather than after it.
What should you do if the deployment already went live?
In order: compare against a comparable population still running the old way, which is a real comparison; or reconstruct from system data while stating explicitly what it excludes, which makes the figure conservative; or measure forward and claim only the trend. Avoid asking people what the task used to take.
The claim is built before the change, not after it
A deployment that works and cannot be proven to work is a deployment that does not get expanded. The evidence for it is assembled in the weeks before anything changes, from the people who were doing the work, in six fields on one page.
That document is cheap, narrow and perishable. Once the system is live, the only honest options are weaker versions of it.
See it. Fix it. Win it.