Improve Continuously

A better metric can conceal a weaker operation

Shorter handling time may coincide with more repeat contacts. Higher straight-through processing may move difficult cases into a slower queue. A model improvement may increase review effort or create a dependency the operating team cannot sustain.

Keep the original operating outcome visible while the capability evolves. Review performance across the relevant flow of work, including the people who receive its outputs. Technical measures help explain what happened; the operating owner must decide whether the result serves the enterprise.

Continuous improvement does not mean continuous expansion of autonomy. Evidence may justify a broader role, a narrower one, a process change or retirement. The ability to make those decisions deliberately is the capability this phase develops.

What changed for the customer or operation—and what became harder elsewhere?

Five questions that turn signals into decisions

What is the signal actually telling us?

Look at the primary outcome, guardrails, exceptions, adoption and total operating effort together. Segment the evidence where different case types behave differently. Check whether demand, policy, staffing or data changed before attributing a movement to the AI capability. Record uncertainty when the comparison cannot separate these effects.

Where is the cause?

Trace representative cases, including failures and workarounds. Determine whether the issue comes from knowledge, decision authority, process design, system behavior or response capacity. Feedback from operators can reveal a recurring gap that averages conceal. Choose the intervention after identifying a plausible mechanism.

Who can authorize this change?

Distinguish routine maintenance from a change in policy, permitted actions or risk exposure. Keep larger changes within the appropriate owner's mandate and review route. Treat model or knowledge updates as operating changes when they can alter decisions; an automated release should not quietly expand authority.

How will we test the effect?

State the hypothesis, affected scope, expected outcome, protected guardrails and conditions for reversal. Use a credible comparison where feasible and account for other changes. Preserve the relevant baseline and version information. A release note records that something changed; it does not show that performance improved.

What should the enterprise learn or stop?

Review whether the gain persists and whether downstream teams experience a cost. Record the decision and its basis so another team can assess whether it applies to their context. Revisit the operating case when costs, demand or obligations change. Retire low-value controls or features through an authorized decision, just as deliberately as adding new ones.

Follow the backlog beyond the dashboard

Hypothetical example, continuing the invoice opportunity.

The assistant prepares requests faster and its extraction results remain stable. Yet supplier queries and unresolved exceptions rise. A case review reveals that missing goods receipts are concentrated in one purchasing route; repeatedly improving extraction would leave that cause untouched.

The Operating owner tests a change to receipt capture and routing with Procurement. The review considers elapsed time to resolution, repeat requests, rework and the additional effort in the receiving team. Expansion depends on an improvement in the whole flow.

First review: bring one promising signal and one deteriorating guardrail to the people who own the affected work. Trace cases, agree a cause to test and choose a bounded intervention. Return to framing or design if the problem now differs materially from the original operating case.

• Are we reviewing the intended operating outcome alongside quality, exceptions and total effort?
• Have we considered other explanations for a change in performance?
• Does the proposed remedy address a plausible cause in the work, rather than the most visible technology?
• Is the change within the owner's authority, with explicit approval for altered policy or autonomy?
• Can we test, contain and reverse the change while protecting live work?
• Have we verified downstream effects and recorded whether to Expand, Continue, Narrow, Redesign or Stop?
• Are we willing to reframe or retire the capability if the operating case no longer holds?

Choose the next commitment

Adopt or extend a change when the evidence supports the outcome and its ongoing obligations. Adjust or reverse it when guardrails deteriorate or the mechanism fails. Return to framing or design when the problem, value case or operating boundaries have changed.

This phase connects back to every other phase. Use the Transformation Hub to find the decision that now needs attention; completing a sequence is less useful than revisiting the right question.

Record the review decision as Expand, Continue, Narrow, Redesign or Stop. The phase gate states the next delivery commitment; a pause, fallback or rollback remains an operational control.