Start where work is repeated, not where it is interesting
The instinct when adopting AI is to look for the most impressive thing it can do. That is almost always the wrong place to start, because impressive tasks tend to be rare, high-stakes, and hard to verify. The tasks worth automating first are the boring ones that happen every day and cost a few minutes each time.
A useful filter: find every point in the week where a person reads something in one system and types a version of it into another. That copying is pure overhead. It produces no new judgement, it is where transcription errors enter, and it is the first thing to get skipped when the week gets busy.
Map one workflow end to end before touching a tool
Pick a single process and write it out as a sequence: what starts it, who touches it, what they decide, where the information ends up. Do this on paper before opening any automation platform. Two things usually fall out of the exercise immediately.
The first is that the process has more steps than anyone thought. The second is that at least one step exists only because a previous tool could not do something — a workaround that has outlived its cause.
- What event starts this work?
- What information is needed, and where does it currently live?
- What decision does a person actually make?
- Where does the result have to land for the next person?
- How does anyone know it finished?
That last question is the one most often missing, and it is the one that decides whether the automation is trustworthy later.
Separate interpretation from decision
This is the distinction that keeps automated systems debuggable. AI is good at interpretation: reading unstructured text and producing a structured answer. It is a poor choice for the decision itself when that decision has rules.
Classifying an inbound message as a billing question is interpretation. Deciding that billing questions go to a specific person, within a specific window, and escalate after it, is a rule. Put the interpretation in the model and the rule in the workflow.
The practical benefit is that when something goes wrong you can tell which half failed. If the routing is wrong, you read a rule. If the classification is wrong, you look at the input and the prompt. When both live inside one prompt, every failure looks the same and none of them are reproducible.
Good candidates share three traits
Workflows that automate well tend to have a clear trigger, a bounded input, and a destination that can confirm receipt. Lead intake has all three. So does turning a call transcript into notes, routing inbound mail by intent, and keeping a CRM field in step with a form submission.
Workflows that automate badly usually fail one of those. If the trigger is "when someone mentions it", if the input could be anything, or if the destination is a person's judgement rather than a system, the automation will produce more exceptions than throughput.
Keep a person in the loop where the cost of being wrong is real
Drafting is a safer pattern than sending. A system that writes a reply and holds it for approval captures most of the time saving while keeping the failure mode visible. Once the approval step has run for a few weeks and the edits have become trivial, you have evidence for removing it — evidence that did not exist on day one.
The reverse order, automating the send and adding review after something goes wrong, means the first failure happens in front of a customer.
Design the handover before you need it
The measure of a working automation is not that it saves time this month. It is that the next person to own it can understand it without you. That means the trigger, the expected input, the model's role, the validation, the destination, and the failure behaviour are all written down somewhere that is not a person's memory.
Automation that only its author understands is not an asset. It is a dependency.
Cost the workflow before you cost the tool
The question "what will this cost" usually gets answered with a subscription price, which is the smallest part of it. The real figure is the build, plus the ongoing attention, plus what it costs when it is wrong.
A more useful estimate has four lines. What the manual version costs per month in time. What building it costs once. What it will cost to keep working — credential renewals, upstream changes, the occasional investigation. And what a failure costs, multiplied by how often you expect one.
That fourth line is the one that changes decisions. A workflow saving two hours a month that produces a customer-visible error twice a year is not a good trade, however cheap the platform is.
Start with one workflow and finish it
The most common failure pattern is breadth: five workflows started, none finished, none trusted, all needing maintenance. It happens because starting is satisfying and finishing is not — finishing means error handling, the runbook, the monitoring, and the awkward edge cases.
One workflow taken all the way to the point where someone else could own it is worth more than five that mostly work. It also teaches you what "all the way" costs in your environment, which is the number you need before committing to the next four.
What good looks like after six months
A useful test, applied later rather than at launch: can someone who did not build it explain what it does, tell whether it ran today, and fix it when it breaks?
If yes, the automation is infrastructure. If no, it is a person's side project that happens to be load-bearing, and the business is exposed to whether that person is available. The difference is not in the code — it is in the documentation, the observability, and whether anyone else has ever touched it.