Find the friction before the technology.
Ask the people doing the work where a task repeatedly slows down. Is an enquiry waiting for someone to gather context? Does information have to be copied between several tools? Is the same document prepared from scratch each time?
These are starting points for a conversation, not proof that the task should be automated. Write down what triggers the work, the steps it passes through and what a good result looks like. Include the waiting, checking and correction work that can disappear from a tidy process diagram.
Name the person who owns the outcome.
A workflow needs a responsible owner who understands the current process and can evaluate a proposed change. That person does not need to be a technical specialist. They need to know what is useful, what is wrong and what should happen when the normal path breaks down.
Make the operating responsibility clear as well. Who notices a failed connection? Who reviews a draft? Who can change a rule? An unattended workflow without a responsible person is a fragile handoff, even when the technology works.
Choose a baseline you can actually observe.
Before promising improvement, establish what happens today. Use a measure connected to the problem, such as:
- Time from an enquiry arriving to the first useful response.
- Time spent preparing a document from approved material.
- The number of incomplete handoffs or corrections in a representative sample.
- Delay between source data becoming available and a reviewed report being ready.
A small, consistent sample is often a more useful starting point than an elaborate estimate. Record what the measure includes, who observes it and any unusual conditions that would make the comparison unfair.
Decide whether AI has a useful job.
Some steps have a predictable answer: route an enquiry by a selected category, copy a confirmed field or send a reminder after an agreed interval. Ordinary workflow rules may be simpler and easier to operate.
AI becomes more relevant when the input involves language, varied documents or a draft that a person will review. Even then, define the boundaries. Which sources may it use? What should it do when information is missing? Which actions require approval?
Look at the exceptions early.
Collect examples of incomplete, ambiguous and unusual inputs before building. A workflow that only works on a clean demonstration can create more checking work when it reaches everyday use.
Define safe behavior for these cases. It may be better to ask a question, flag an item for review or stop a step than to produce an uncertain result. Agree what should be visible to the owner and how the original information can be recovered.
Scope a pilot around one clear handoff.
A first pilot should be small enough to evaluate. Specify its input, its output, the tools involved, the data it may access and the person who reviews the result. Agree a useful acceptance check before implementation starts.
For example, a lead-intake pilot might prepare a complete handoff for a person to review. It does not need to automate every sales conversation, change the CRM and rewrite the entire customer journey at the same time.
Include deployment, documentation and a walkthrough in the plan. A successful pilot is not just a demonstration: it should make the next operating decision clearer.
Make the next decision from evidence.
Review the pilot against the baseline and acceptance check. Did the handoff improve? Did the new workflow create hidden review work? Can the responsible team operate it? What happens when a source or connection changes?
If the result is useful, agree rollout and the appropriate level of maintenance. If it is not, use what the pilot revealed to revise the process or stop. The goal is a better business workflow, not a reason to keep using a particular tool.
Human02’s delivery approach follows this sequence: review the workflow, build a focused pilot, test it and put your team in control. Explore AI automation for business or tell us where the work is getting stuck.