Start with a task, not a tool

Ask where the team keeps doing the same work by hand. Copying data, finding context, checking documents, assigning requests, chasing updates. Have the person who does it walk you through a recent example, start to finish.

Do not begin with a list of AI products. A demo can look impressive and leave the actual problem untouched. You need to know what arrives, what gets decided, where it goes, and what counts as done.

Pick a problem worth the effort

List the tasks that recur weekly. For each, note the volume, the active time per item, who touches it, and what a mistake costs.

Then ask the sharper question: is this task the reason you are about to hire? If the change genuinely removes that need, the value is the hire you avoid, less what the automation costs to run. If nobody’s pay changes, time saved is capacity, not cash. Name the benefit before you put a number on it.

A classification review changed the starting point

In a support-classification project, we tested how incoming requests should be grouped before touching live routing. Reading the full issue text exposed decisions that short summaries had hidden. Some requests fit no available category, so leaving them unclassified was the correct result.

We revised the instructions, re-ran the same cases, and kept the workflow disabled. That proved a narrow point: the revised rules handled those development cases more consistently. It did not prove production accuracy. The next step was a reviewed pilot, not automatic action on customers.

Your first improvement can be a better decision rule and a clear test. You do not have to switch everything on to make progress.

Define one complete first release

A good first release has a start, an end, an owner, and a test. For example: turn a website enquiry into a checked customer record, keep its source, assign an owner, and flag a failed handoff. That is a complete improvement without automating all of sales.

Use fixed rules where the next step is known. Add an agent only where the input needs interpreting. Write down what the release will not do, so the team knows where responsibility still sits.

Bring five lines to the first conversation

The task, who does it, how often, the tools involved, and what better looks like. Add one normal example and one awkward one. That is enough for a specific conversation.

Before release, record a baseline. After release, measure the same things: active time, correct completion, manual fixes, missed items. Then ask the people using it. Saving time in one step and adding it in another is not an improvement.

Related

Explore workflow automation