What you actually get from a workflow audit.

The process map, as it actually runs

The first deliverable is a map of how the work moves today: every hand-off, every system it touches, and every point where it waits for a person. It is drawn from the people who do the work, not from the process document, because those two are never the same.

Most clients find the map itself is worth the week. Seeing an ordinary enquiry cross four systems and two inboxes explains a month-end number that had been hard to explain for years.

The points of loss, named and quantified

Each waiting point gets a number: how long work sits there, how often, and what it costs when it is missed. Where the data does not exist, the audit says so rather than estimating: an invented baseline makes every later claim unverifiable.

A baseline you guessed makes every result you report meaningless.

One measurable outcome

The audit proposes a single number to move, with the current value and the way it will be measured. One number, not a dashboard: a project with five targets has no target.

This is the sentence that later decides whether the build succeeded, so it is written in plain language and agreed before anything is priced.

Where a person stays in control

The audit marks the decisions that must not be automated: anything customer-facing before review, anything the system is unsure about, and anything destructive or financial. These become the approval points in the design.

Naming them early is what keeps the eventual system defensible to a customer, a regulator or an insurer.

A recommendation, including “do not build”

Roughly one engagement in five ends with a recommendation not to build anything. The usual reasons are ordinary: the volume is too low, a setting in software the client already pays for solves it, or the process needs agreeing before it needs automating.

You keep the map either way. That is the whole reason the audit is free: it is the only honest way to make the recommendation credible.