Work design

Start with the workflow, not the AI tool

An AI tool can perform a task. That does not mean it improves the work. Lasting value depends on the workflow around it: the outcome, evidence, decisions, hand-offs, exceptions, and people responsible when the standard path breaks.

A team in a Singapore office reviews a workflow on a whiteboard, with one person pointing to an exception in the process

The demo works. The work does not.

In my consultancy work with organisations, I often encounter a familiar pattern. A decision-maker sees an impressive demonstration, acquires the tool, and asks employees to use it. The employees then struggle to apply it meaningfully to their work. They attend courses to learn the tool and, after a month of experimentation, manage to create an AI-enabled workflow. Yet the workflow produces mediocre results, fails to achieve the intended outcome, or cannot handle important exceptions. Before long, the application sits unused somewhere in the organisation’s systems, while the team quietly returns to its old way of working.

AI providers are continually competing to outperform one another, so the capability gap between leading tools rarely stays wide for long. Today, OpenAI may announce its latest and most capable model. Tomorrow, Anthropic, Google, or another provider may offer something comparable or better. Chasing “a better tool” becomes an endless race.

The technology may be capable, but the initiative can still struggle because a task was automated without redesigning the work around it. Instead of asking, “What can I do with this tool?”, ask, “What should improve in the workflow, for whom, under what conditions, and towards what desired outcome?”

Begin with an outcome someone can recognise

“Improve productivity” is too broad to guide a design decision. So is “use AI to plan production”. The first describes an aspiration, while the second has already selected an intervention.

A useful work outcome describes what must be true when the workflow is complete. For example:

A kitchen supervisor receives the day’s customer orders, ingredient requirements, current inventory, and staff availability in time to prepare a practical production plan that fulfils orders while minimising waste.

This definition changes the conversation. Speed still matters, but it is no longer the only measure. Order fulfilment, ingredient availability, food wastage, staffing constraints, production capacity, and the handling of late orders or stock shortages all become part of the intended result.

It also allows the team to discover that AI may not be the best first intervention. The actual constraint might be incomplete orders, inaccurate inventory records, disconnected spreadsheets, late updates, unclear responsibilities, or no agreed method for prioritising production.

Examine the work as it is actually done

A procedure describes how work is expected to happen. A workflow review must also reveal how it happens in practice. That includes the spreadsheet maintained by one employee, the message sent to confirm a late order, the supervisor’s informal stock check, and the workaround used when an ingredient or staff member is unexpectedly unavailable.

Walk through several recent, representative work days and make six elements visible:

  • Trigger: What starts the work, and when must the production plan be ready?
  • Outcome: Who needs the result, and what makes it practical and usable?
  • Evidence: Which sources, records, operating requirements and policies must be accurate and available?
  • Decisions: Where do people classify, compare, prioritise, exercise judgement, approve, or reject?
  • Hand-offs: Where does work move between teams or systems, and what can be delayed or lost?
  • Exceptions: What happens when an order arrives late, stock information is inaccurate, equipment becomes unavailable, or a staff member is absent?

Pay particular attention to experienced employees who make difficult steps appear easy. Their speed often rests on tacit knowledge: how they anticipate potential disruptions or bottlenecks, reconcile conflicting information, and recognise when a situation requires escalation. If that judgement remains invisible, a prototype will be designed around an incomplete understanding of the work.

Find the constraint before choosing the intervention

Once the workflow is visible, identify where performance actually breaks down. Are customer orders arriving late or in different formats? Are employees re-entering the same information across multiple systems? Are inventory records inaccurate or difficult to access? Does the kitchen supervisor spend too much time reconciling orders, available stocks, production capacity, and staff schedules? Are important decisions delayed because responsibilities or approval requirements are unclear?

Different constraints call for different responses:

  • Clarify the process when teams follow different ways of working or disagree on the standard path.
  • Improve data or knowledge access when trusted information is incomplete, inaccurate, or difficult to find.
  • Use rule-based automation when inputs, decisions and operating rules are stable.
  • Use an AI assistant when a person needs support to interpret information, compare options, prepare a plan, or explore alternatives.
  • Consider an AI agent when bounded work requires several steps across different tools, with defined permissions, human oversight and recovery paths.
  • Redesign roles, policies, or approvals when the constraint is organisational rather than technical.

A useful solution may combine several of these interventions. For example, reliable inventory data and a clearer ordering process may be required before an AI assistant can help the supervisor prepare a production plan.

What matters is that each component addresses an observed constraint. The complexity of the solution should be justified by the work, because every additional component introduces new permissions, failure points, evaluation requirements, and operating responsibilities.

Design responsibility, not just human review

Saying that “a human will check it” is not an operating model. It does not explain what the person must check, what evidence should be available, how much time they have, or what they should do when they disagree with the system.

For every AI-supported step, define:

  • what information the system may access;
  • what it may produce, recommend, or execute;
  • what the person must verify or decide;
  • which conditions require approval or escalation;
  • how uncertainty, missing information, and failures will be shown;
  • who is accountable for the final outcome and for responding when something goes wrong; and
  • how users can pause, override, correct, and improve the workflow.

In the food-production scenario, an AI assistant may prepare a recommended production plan based on customer orders, inventory records, and staff availability. However, the kitchen supervisor may still need to verify stock availability, assess whether the plan is practical, and respond to unexpected changes during production.

The aim is not to place a person mechanically at every step. It is to preserve meaningful judgement and accountability where the consequences require them, especially when the work affects customers, employees, costs, compliance, food quality, or safety.

Measure the whole workflow

A badly designed AI workflow can make one step faster while making the end-to-end workflow worse. Planning time may decrease while review time, correction effort, or exception handling increases. A team may produce more output, while downstream employees encounter greater variation and spend more time adapting or reworking it.

Test the workflow using normal situations, difficult situations, incomplete information, and known exceptions. Compare its performance before and after the intervention. Depending on the intended outcome, useful measures may include:

  • end-to-end time, not only the time taken to generate an output;
  • first-time-right rate and correction effort;
  • completeness and traceability of the information used;
  • consistency across users and situations;
  • exceptions detected, missed, and resolved;
  • user workload, confidence, and ability to intervene; and
  • the cost and capability required to operate and improve the solution.

For the food-production workflow example, the team might also measure whether orders are fulfilled on time, production plans are practical, ingredient waste is reduced, and unexpected changes are handled effectively.

The success of a pilot lies in the reliability of the evidence it produces for the next decision or action. It is better to discover early that a proposed solution is unsuitable than to make a large investment in the wrong design.

Start with one recurring workflow

Choose a workflow that matters, occurs often enough to be observed, and has an owner who is willing to improve it. Bring together the people who perform the work, receive its output, manage its risks, and support the systems involved.

Use one recent example to answer four questions:

  1. What outcome were we trying to produce, and for whom?
  2. Where did time, quality, or confidence break down?
  3. Which evidence, decisions, hand-offs, and exceptions shaped the result?
  4. What is the smallest change that would allow us to test an important assumption?

The next step may involve improving the process, providing better access to information, developing employee capability, introducing simple automation, building an AI-assisted prototype, or conducting a deeper diagnostic. The tool should be selected only after the team understands what needs to change and why.

Starting with the workflow is not a slower route to AI adoption. It is a more direct route to useful change. It also provides a clearer basis for deciding whether AI deserves a place in the work and how roles should be redesigned to support its successful adoption.