The useful starting question is what happens between a request and an accepted result. An employee's job contains several kinds of work: gathering information, interpreting it, making a decision, taking action, and checking the outcome. AI may alter one part without changing the others.
Consider an order-entry specialist. Reading an attachment is a task. Creating an accurate, authorized order that the warehouse can fulfill is the workflow. Measuring how quickly a model reads the attachment tells you little about whether the complete process improved.
This chapter sets out a way to look at any proposed change before a model is chosen: what the unit of finished work is, what the process looks like now, which steps carry authority, where work will move, and where the real constraint sits. Each idea is illustrated from the guide's own workflow chapters. The framework is editorial guidance; the numbers in the examples are illustrative.
Define the unit of completed work
Choose a unit that someone downstream accepts. Examples include a resolved support request, an approved proposal, a correctly entered order, or a usable forecast delivered before a purchasing decision.
Specify the start and end. Does support end when a reply is sent, when the customer confirms the answer, or after a defined period without another contact? Does a proposal end at first draft or partner approval? Different boundaries produce different productivity claims.
Record both human effort and elapsed time. Ten minutes of employee work spread across three days is different from three hours of continuous work. AI that saves five minutes will not remove a two-day wait for customer approval.
How the guide's workflows define their units
| Workflow | Unit of completed work | Measure that looks like progress but is not |
|---|---|---|
| Support replies | A resolved request, followed through a fixed observation window | First-reply speed, if follow-ups rise |
| Proposals | An approved submission, or a recorded decision not to bid | Pages drafted per hour |
| Order intake | A complete, correct, duplicate-free order in the system | Fields extracted per minute |
| Incident triage | A verified, source-linked brief a responder can rely on | Time to a first summary, whatever it contains |
| Onboarding | An eligible account reaching a verified first milestone | Plans sent or conversations closed |
| Knowledge retrieval | A request resolved with verified, permission-appropriate, source-linked material, or a correct "nothing found" | Answers generated, however fluent |
| Meeting follow-up | An approved follow-up with accepted owners and dates, sent to the right audience | Recaps produced per minute |
| Inventory forecasting | An approved replenishment decision with its outcome recorded | Forecast error alone, without the order and service outcome |
| Catalog enrichment | An approved, attribute-complete record, or a correct hold naming the missing data | Fields filled per record |
Each "false progress" measure is real and can improve. The problem is that it can improve while the unit gets worse. A proposal desk that drafts faster but sends partners more rework has moved effort, not removed it.
A counterexample: a unit that is too small
Suppose a team defines its unit as "a draft reply generated". The assistant produces thousands. Every one counts as output, including drafts the agent discards, drafts that cause a second contact, and drafts on requests outside the agreed scope. The metric rises while customers wait as long as before. The fix is not a better model; it is a unit someone downstream would accept.
A counterexample: a unit that is too large
The opposite error is "customer satisfaction this quarter". Many things move it, most of them unrelated to the assistant: product releases, staffing, seasonality. A unit that large cannot attribute a change to the workflow. Use it as context, not as the measure of the experiment.
Draw the process before changing it
A useful workflow map includes inputs, systems, transformations, decisions, handoffs, and exceptions. Add an owner at each consequential step. Use real cases to challenge the map, especially those that employees call unusual but encounter regularly.
| Step in order intake | Existing responsibility | Possible change | What stays explicit |
|---|---|---|---|
| Identify the customer | Order specialist | Proposed match | Verified customer identity |
| Read product and quantity | Order specialist | Extracted fields | Source document and units |
| Match product | Specialist or sales | Suggested catalog match | Approved item mapping |
| Resolve ambiguity | Sales or customer | Draft clarification | Actual confirmation |
| Create order | Authorized employee | Approved system write | Permission and duplicate prevention |
| Fulfill order | Warehouse | Outside this pilot | Correct downstream outcome |
This map makes it possible to identify a small experiment. It also reveals whether a simpler integration could remove the task altogether. Asking customers for structured orders may be more useful than interpreting complex attachments.
What a good map records that a process chart does not
As a proposed practice, record four things beside each step:
- The input and its source of truth. "Customer's PDF" is an input; the item master is the source of truth for what the customer's code means. A map that confuses the two invites a system to treat a supplier's wording as fact. The catalog enrichment chapter shows what happens when identity is inferred rather than checked.
- Who may act on the output. See the next section.
- What happens to exceptions. Who receives them, how fast, and what the queue looks like on a bad day.
- What is measured today. If nothing is measured at a step, the pilot cannot show that the step improved.
Walk at least ten real cases through the draft map, including ones staff describe as awkward. In the order-intake chapter, the awkward cases (conflicting pack sizes, a revision that changes the ship-to address, a timeout after a successful submission) are where the design decisions sit. A map built only from the ordinary case would miss all three.
Separate information from authority
A system can propose a useful answer without being authorized to act on it. Extracting a price is different from approving a discount. Summarizing a discussion is different from committing to a deadline. Predicting demand is different from placing a purchase order.
Write down the allowed output and who can convert it into action. This decision affects the user interface, integrations, review effort, and recovery process. It should be made before a prototype quietly acquires production permissions.
The guide's workflows show the same separation in different settings:
- In meeting follow-up, "we could probably have that by Friday" is information about the conversation. It is not a commitment, and a recap that records it as one creates an obligation nobody agreed to.
- In forecasting, the forecast is information and the purchase order is an action. A better forecast does not by itself authorize a larger order.
- In incident triage, the brief may list a recent deploy as a candidate cause; rolling it back is a mitigation the incident commander authorizes.
The authority chapter sets out four operating arrangements for deciding how far a system's output may travel without a person. Choose the arrangement for each step on the map, not for the system as a whole: a single workflow can retrieve freely, propose with review, and leave execution entirely to people.
Look for work that moves elsewhere
An assistant may reduce drafting while increasing verification. Automatic classification may make the ordinary queue smaller and leave a concentrated set of difficult cases. Faster front-end processing may create a backlog downstream. These are process changes to measure, not reasons to assume failure or success.
Include knowledge maintenance and exception resolution in the map. If a system depends on approved source documents, someone must keep them correct. If employees need to correct output, those corrections consume time and may require greater expertise than the original task.
Four places work moves
| Where it moves | Illustration from the guide | What to measure |
|---|---|---|
| Into review | Support drafts replace research and writing with evidence review (support) | Review minutes per case, including rejected drafts |
| Into exceptions | Routine orders get faster; the ones left are the hardest (order intake) | Exception share, exception minutes, queue age |
| Upstream, into data | Retrieval only works on labeled, owned documents (knowledge retrieval) | Curation effort and who funds it |
| To another team | Proposal partners review more drafts (proposals) | Effort by role across the whole cycle |
The order-intake chapter works through the exception case: because exceptions take longer than routine orders, the assisted average rises with the exception share, and its sensitivity shows the share at which assistance stops helping. The operations leaders guide sizes the queue those exceptions form.
A misreading to avoid
"The assistant saves three minutes per case" and "the team saves three minutes per case" are different claims. The first measures the step. The second requires that nothing else grew, including review, exception handling, upstream curation, and the time other teams spend on work that now reaches them. Report effort by role across the whole unit, as the economics chapter recommends, or the saving may only be relocated.
An illustrative comparison
Imagine a simplified proposal requiring four hours of research, three of drafting, and three of review. An assistant reduces research to two hours and drafting to one, but review increases to four. Total effort falls from ten hours to seven, a three-hour improvement. Reporting only drafting would suggest a much larger change than the complete workflow supports.
If the partner can review only two proposals a day, additional drafts do not automatically increase submissions. The team must examine its actual constraint. This example is hypothetical and demonstrates measurement, not an expected result. It is a three-step simplification, separate from the four-step breakdown in the proposals chapter, though both fall from ten hours to seven.
Faster drafting, same output
- Steps assistance shortens
- Step that grows
Before · 10 h
Research 4 h · Drafting 3 h · Review 3 h
Assisted · 7 h
Research 2 h · Drafting 1 h · Review 4 h
Drafts finished sooner → drafts waiting for review → partner review: two proposals a day → submissions: no increase
Show the data
| Step | Before (hours) | Assisted (hours) |
|---|---|---|
| Research | 4 | 2 |
| Drafting | 3 | 1 |
| Review | 3 | 4 |
| Total | 10 | 7 |
Why the constraint decides what the saving is worth
The three released hours have value, but their value depends on where the constraint sits:
- If the constraint is drafting capacity, the team can now produce more drafts, and more submissions may follow, provided review keeps up.
- If the constraint is partner review, more drafts wait in a longer queue. The saving shows up as shorter working hours for writers, not as more proposals. Meanwhile partner review grew by an hour per proposal, which tightens the constraint.
- If the constraint is demand, so that there are only so many opportunities worth bidding on, the time released is capacity with no automatic use. The economics chapter explains why capacity becomes money only through a named mechanism.
A queuing result helps here. Little's Law states that the average number of items in a stable system equals the arrival rate multiplied by the average time each item spends in it. Little, Operations Research, 2011 If drafting was holding work back, faster drafting releases more proposals toward partner review each month. As arrivals approach what review can handle, items wait longer, and Little's Law ties the averages together: items waiting equals the arrival rate times the average wait. It is an identity for averages over a stable period, useful for sizing a queue from two measurements, as the operations leaders guide does; it does not itself predict that a queue will grow, or any particular team's queue.
A practical test for the constraint
As a proposed practice, before a pilot, ask three questions of each step on the map:
- Does work wait in front of this step? A queue in front of a step suggests it is the constraint.
- If this step were twice as fast, would more finished units come out the end? If not, the constraint is elsewhere.
- Who would notice first if volume rose? The answer points to the constraint that the change will expose.
If the honest answer is that review, approval, or downstream capacity limits output, a pilot that speeds up drafting should be framed as reducing effort, not as increasing output, and the review step should be studied alongside it.
A workflow statement you can use
Write: "For [eligible cases], [owner] will use [assistance] to produce [accepted output], using [permitted inputs], with [approval boundary]. We will compare [complete-process measure] against [baseline], while maintaining [quality requirement]."
For example: "For documented product questions, support agents will use source-linked drafts to resolve requests. Agents retain sending authority. We will compare total handling effort and repeat contacts against the current process while checking material claims against approved documentation."
If the team cannot complete this statement, the next step is process discovery rather than model selection. A clear statement becomes the shared reference for the business owner, engineering, finance, and the people doing the work.
Three more statements from the guide
These illustrations restate decisions the workflow chapters make; they are editorial summaries, not observed deployments.
- Order intake: "For emailed purchase orders from known customers, order specialists will use extracted fields and proposed mappings to create orders, using approved master data, with specialist approval before any order is written. We will compare complete-order correctness and total effort, including exceptions, against manual entry, while preventing duplicate orders."
- Incident triage: "For qualifying incidents on connected services, responders will use a read-only, source-linked brief to understand the incident, using authorized telemetry and change records, with no authority to change systems. We will compare time to a verified brief and omitted critical facts against current practice, while keeping the existing command structure."
- Forecasting: "For stable, routine items, planners will use a forecast with a range and an explicit order policy to propose replenishment orders, using history with stockout and one-off flags, with planner approval before any order is placed. We will compare availability and average inventory under the same policy against the current method."
What the statement exposes
The blanks are where projects go wrong. "Eligible cases" forces a scope decision, and an exclusion list. "Accepted output" forces the unit question. "Permitted inputs" forces a data and permission question before integration work starts. "Approval boundary" forces the authority question. "Complete-process measure" forces the team to decide, in advance, what would show the change did not help.
What to do with this chapter
As a proposed sequence:
- Pick one candidate workflow and write its unit of completed work, with start and end.
- Map it with real cases, recording inputs, sources of truth, owners, exceptions, and current measures.
- Mark, for each step, whether the system may inform, propose, or act, and who converts proposals into action.
- List where work could move: review, exceptions, upstream data, other teams.
- Find the constraint with the three questions above.
- Write the workflow statement. If a blank cannot be filled, fill it before choosing a model.
Then use choosing a first workflow to compare candidates, and capabilities to name what the system must do at each step.
Related chapters: choosing a workflow, capabilities, authority and autonomy, order intake, economics, operations leaders.