Where should a business start looking for AI opportunities?

Look at recurring work that people already do, especially where they repeatedly search, retype, wait or check. Ask an experienced employee to walk through a recent example from the first request to the completed result. Capture the information used, the decisions made, the handovers and the exceptions.

Kevin suggests two useful starting points: repeated tasks and processes that can be divided into stages. These help identify candidates. They do not establish that every candidate should be fully automated. A task may be technically possible to automate yet have poor economics, unreliable inputs or consequences that require human judgement.

How do you distinguish a task from a workflow?

“Summarise this document” is a task. “Receive an enquiry, check requirements, prepare a response, obtain approval and send it” is a workflow. Improving the summary may not improve the result if the case still waits two days for missing information or approval.

At CSM, we follow the whole piece of work before selecting a tool. Map who receives each output and what they need to do next. This helps avoid making one person faster while increasing checking or re-entry for someone else. Measure the completed outcome, not just how quickly the model generates text.

Which steps need AI, and which need ordinary automation?

Use explicit rules where the correct operation is known: calculations, required-field checks, moving approved records and routing by agreed criteria. AI may help where inputs vary, such as interpreting an email, extracting proposed fields from a document or drafting a response from approved evidence. People remain responsible for decisions that require authority, context or judgement beyond the agreed boundary.

An agent that chooses its own steps is not automatically the best design. Anthropic distinguishes predefined workflows from model-directed agents and recommends starting with the simplest approach that meets the need in Building effective agents. More autonomy can add cost, delay and failure modes; it should earn its place through better results.

How would you assess an enquiry-to-proposal workflow?

Consider an illustrative business receiving service enquiries. First, software records the enquiry and checks for required contact details. AI proposes a structured description of the request and highlights missing requirements. A person confirms scope where ambiguity could change the commitment. Controlled rules use approved rates. AI drafts the explanation, and the authorised owner approves the proposal before it leaves.

If the information is incomplete, the workflow should request clarification rather than manufacture a scope. If the pricing source is unavailable, it should stop the pricing step. If approval is delayed, it should show the outstanding decision. Each stage has a visible output and a clear reason to move forward or pause.

The first release might automate only capture and evidence preparation. That can still be valuable if it removes repeated searching and gives the reviewer a better starting point. End-to-end automation is a possible future design, not an automatic acceptance criterion.

How should leaders compare opportunities?

Assess frequency and volume, time spent, avoidable rework, delay to the customer, dependence on particular people and the cost of mistakes. Then assess readiness: are the inputs accessible, are the rules agreed, is there a process owner and can the team recognise a correct result? A high-value process with unresolved ownership may need groundwork before an AI build.

Include the risk of leaving the process unchanged. A manual workflow can also lose documents, apply inconsistent checks or depend on one person. Compare the proposed system with the real baseline, including its weaknesses, while separately evaluating the new risks introduced by automation.

How do you estimate value without exaggerating time savings?

Calculate net effort across the whole workflow. An illustrative case with 600 requests per month and 12 minutes of current work per request uses 120 hours. If an assisted process still needs four minutes of review and adds ten hours of monthly exception handling and maintenance, the net capacity released is 70 hours: 120 minus 40 minus ten. These are example inputs, not a CSM result or forecast.

Apply realistic adoption and eligible-volume assumptions. Exclude cases the system cannot handle and include ongoing costs, monitoring and rework. Capacity released is not automatically cash saved: decide whether it will reduce overtime, improve turnaround, absorb growth or allow people to do more valuable work. Test those outcomes after rollout.

How much human control should you retain?

Treat control as a design decision for each step. A system may retrieve evidence automatically, draft a recommendation for review, or execute a bounded action after validation. Greater autonomy should depend on demonstrated performance, reversibility, detectability of errors and the consequences of being wrong.

The “slider” in the video is a useful metaphor for different allocations of work, but responsibility is not simply a preference setting. Legal duties, customer impact, data permissions and operational constraints can impose boundaries. In regulated work, involve the relevant risk and compliance owners before choosing the level of automation. See our guide to AI controls in financial services.

What makes a good pilot?

Use a defined team, a bounded process and representative records, including difficult cases. Record the baseline before testing. Agree what constitutes a correct completion, when the system must stop, who handles exceptions and what would make you pause or abandon the implementation. Check the complete workflow, not only isolated model outputs.

Compare completion time, review effort, repeat errors, missed requirements and the proportion of cases that need intervention. Capture user feedback alongside those measurements. NIST’s AI RMF core calls for documented evaluation and post-deployment monitoring. A pilot should create evidence for a decision, not merely demonstrate that a model can perform a task once.

When should you decide not to automate?

Pause when there is no reliable way to evaluate the result, unresolved rights to use the data, insufficient volume to justify upkeep or no owner for failures. A process that changes daily may need simplification before automation. If an existing software feature solves the problem adequately, a custom AI system may add unnecessary complexity.

Our advice is to choose one recurring process, give it an owner and agree the outcome worth improving. Then work backwards through the information, decisions and controls. Expand only when the evidence shows that the business is completing better work with less avoidable coordination.

What should I read next?

Explore how to connect the data behind a workflow and how to move AI pilots into useful decisions.