Frame the Opportunity

Start with the consequence

A promising demonstration can make the task look like the opportunity. The executive question is wider: what happens to customer outcomes, cost, risk or capacity when that task changes? Faster execution may improve the whole operation, or simply move the queue to the next team.

Start with the consequence the enterprise needs to change. That may be a recurring failure, a constraint on growth or a service that is not possible today. Trace the relevant work from its trigger to the outcome, including decisions, exceptions and handoffs. Then locate the intervention and the dependencies it needs.

This makes the unit of investment explicit: a change in operating performance with an Outcome owner. It also leaves room for a modest intervention when that is sufficient, and a more ambitious redesign when the evidence supports it.

If the pilot succeeds, what changes in the operation the next morning?

Five questions that can change the decision

What outcome is worth changing?

Specify whose performance changes and why it matters: service reliability, cycle time, cost, risk, decision quality or a new capability. Choose one primary outcome, a baseline or credible comparison, and a guardrail that must not deteriorate. A cost objective is legitimate; make the operating consequence and trade-offs explicit.

How will the change create value?

Trace how changing a task, handoff, decision or knowledge dependency changes the outcome. Compare simplification, conventional automation, AI assistance and greater autonomy where justified. Consider the smallest change that can achieve the outcome.

Rank two or three credible opportunity areas against value, feasibility, time to evidence and the capacity to change. Record why the preferred option wins and what would change the ranking. A score with weak evidence should remain an assumption, not acquire authority through arithmetic.

What could prevent the gain?

Find the critical dependency: capacity in the next team, policy authority, data, model reliability, integration or skills. Name the Operating owner who can change it and the sponsor who can resolve trade-offs across teams.

Set an initial autonomy boundary. Use Recommend, Act, Escalate and Never Delegate to state what the system may do, which decisions remain with people and what must trigger escalation. These are starting constraints for design, not a claim that risk has been resolved.

Can the enterprise use the benefit?

Separate time released, usable capacity and cash savings. Include human review, exception handling, ongoing service costs and transition effort. Show what loses funding or attention when this option wins, and how the case changes under weaker assumptions.

What evidence would change the decision?

Name the assumption most likely to overturn the case. Choose the least costly credible test, the evidence required and the condition for stopping. Fund the next justified commitment; a successful demonstration does not automatically justify scaling.

A faster invoice is only part of the case

Hypothetical example. All figures are monthly planning assumptions, not client results.

Initial proposal: use AI to extract invoice data faster. Reframed opportunity: reduce avoidable invoice exceptions from receipt to approved payment, with Finance and Procurement owning the handoffs.

• 200 hours gross time released: 3,000 invoices × 4 minutes ÷ 60.
• 80 hours added operating effort: assumed review, exception handling and support.
• 120 hours potential net capacity: 200 less 80.

Cash value depends on whether the owner can redeploy that capacity, avoid overtime or change spend. Delivery and licence costs remain to be assessed. Hours released alone do not establish savings.

First test: have the Finance Operating owner trace historical exceptions, including peak periods, without changing payment authority. Compare extraction errors, missing receipts and approval delays. Reframe if extraction is not the main constraint.

• Can the sponsor explain the intended operating outcome in one sentence, including why it matters to the enterprise?
• Have we agreed a baseline, a success measure and a guardrail, with the uncertainty visible?
• Have we ranked credible opportunities for both value and feasibility, and compared simpler alternatives?
• Does the value case include the effort required to review, handle exceptions, transition and run the service?
• Are an Operating owner and an executive sponsor committed, with authority to resolve the critical dependencies?
• Have we stated the initial limits on autonomy and the decisions that require human judgment?
• Do we know what evidence would make us proceed, test further, reframe or stop?

Choose the next commitment

Proceed to design when the value mechanism, ownership and evidence justify it. Test first when one material assumption remains unresolved. Reframe when the real constraint differs from the original proposal. Stop or defer when value is insufficient or a critical dependency cannot be addressed.

Proceeding funds the next design step. Keep unresolved assumptions visible and revisit this phase when new evidence changes the case.

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.