AI value creation starts with the workflow

In a service business, an AI initiative needs to reach the people doing the work. They need usable inputs, clear responsibilities and a reliable way to handle exceptions. A useful plan explains how those conditions will change and which operating result should follow.

Operating experience

What I prioritised in service businesses

Chapter 2

At Chapter 2, I lead product and technology, including P&L responsibility. I rebuilt the product organisation around AI, prioritised frequent service workflows for automation and led the organisational changes needed for adoption.

Travel advisory

In an AI travel-tech advisory engagement, I advised a roll-up from concept through implementation. I prioritised team training and pushed for AI within existing back-office workflows, without a new interface for the team to learn. The work concerned an acquired luxury travel agency.

Those are the publicly described roles and engagements. The sequence below is the approach I would use to assess a new workflow; it does not reconstruct either organisation's internal rollout or disclose internal systems.

Rollout framework

From one workflow to a scaling decision

1. Baseline

   Define one workflow, its owner, acceptance criteria and complete delivery cost.

   →
2. Bounded pilot

   Use permitted inputs, human approvals and a practised fallback.

   →
3. Team adoption

   Check use on eligible jobs, rework and service quality.

   →
4. Value decision

   Compare with the baseline. Decide what changes in capacity or spending.

Scale, revise or stop

Agree the review date and thresholds before the pilot. Expand only when quality, adoption and recurring costs support the intended operating result.

1. Choose one complete workflow

Describe the work from its trigger to an accepted result. Specify who requests it, who receives it, which systems hold the inputs and who can decide it is complete.

A candidate workflow should be frequent enough to measure, bounded enough to test and relevant to an operating priority. It might involve gathering information, preparing a draft or checking routine records. These are candidate tasks to examine, rather than claims about what either organisation automated.

Include the handoffs. If one team generates an answer and another has to transfer it, check it and repair it, the baseline needs to include both teams' work. Choose a scope small enough that its owner can observe those steps.

2. Agree the baseline and the result

Measure the current process over a defined period. Record workload volume and mix, active delivery time, elapsed time, quality and the work needed to correct exceptions.

Use a completed job as the unit where that matches the service. Record what counts as completed and keep that definition stable during the comparison. Include unsuccessful attempts and rework in the workload, rather than counting only jobs that went smoothly.

The measurement plan can be short:

Delivery effort

Active human minutes per accepted job, including checks and correction.

Turnaround

Time from the agreed trigger to an accepted result.

Quality

The service's acceptance criteria and the share meeting them.

Exceptions

Cases requiring escalation, a retry or a return to the original process.

Operating cost

Delivery labour, provider and infrastructure costs, and recurring support for the same workload.

Adoption

Eligible jobs using the agreed process out of all eligible jobs.

Show implementation and training costs separately. When volume or case mix changes, explain the difference before interpreting the result. Keep the sample size visible.

3. Put AI where the work happens

Map the proposed workflow alongside the baseline. Specify which step AI performs, where the output appears, who checks it and how a failure returns to a workable process.

The interface choice should follow the task. An existing system may already provide the right place to receive inputs, review a result and continue delivery. A new interface needs to justify the extra handoff and training it introduces. Some workflows will need one; the operating plan should make that choice explicit.

Give the pilot clear boundaries: eligible work, permitted inputs, acceptance criteria, actions requiring approval and the person responsible for an exception. The team should know when to continue and when to stop.

4. Assign ownership and practise exceptions

Give one operating owner responsibility for the complete workflow. Product and engineering can own implementation, but the delivery team needs someone who can approve the process, resolve exceptions and judge whether service quality holds.

Training should use ordinary work and difficult cases. Ask people to practise a missing input, an incorrect result and a service request that falls outside the pilot. Make the fallback easy to find.

During the pilot, record where people abandon the new process or do extra work around it. Low adoption might reflect unreliable output, unclear responsibility, an awkward handoff or a mismatch with the task. Investigate the cause before expanding access.

5. Decide how an improvement becomes value

Compare the complete processes against the agreed baseline. Show delivery effort, quality, exceptions and recurring cost together. State what remains uncertain.

If the process frees time, identify the management decision that follows. The business might serve more customers, shorten a backlog, avoid additional hiring or reduce specific spending. Each requires its own evidence. Freed hours alone do not establish a reduction in expenditure.

BCG's analysis of AI in private equity makes a related point: realising value requires changes to workflows, roles and the operating model. This is useful context for assessing a rollout; it does not validate the results of my engagements.

Five questions before you scale

1. Is the whole workflow measured?

   Name the trigger, accepted result, sample period and cost of checks, retries and handoffs. Keep the workload and quality threshold comparable.

2. Can the team handle failure?

   Confirm acceptance criteria, approval points and a fallback practised on difficult cases. Someone must be able to stop the process.

3. Who owns delivery and adoption?

   Name the operating owner. Measure use across all eligible jobs and investigate abandoned attempts and extra work around the process.

4. What converts time into value?

   Specify the decision: more customer capacity, a shorter backlog, avoided hiring or a reduction in identified spending. Freed hours alone do not establish cash savings.

5. What would make you revise or stop?

   Set the review date, quality floor and acceptable recurring cost. Show implementation and training costs separately. Assess each new workflow on its own evidence.