When a founder asks us to automate something, the first candidate is usually the thing that annoys them. Inbox triage. Weekly reporting. Chasing invoices. Understandable, and often the wrong place to start, because irritation is not the same as cost.
The processes worth automating first are the ones that are high-volume, low-judgement, and expensive when they go wrong. Sometimes that overlaps with what you hate. Frequently it does not.
A test that works
Before scoping any agent, we put the process through four questions. If it fails two or more, we say so rather than building it.
| Question | Why it matters |
|---|---|
| How often does it run? | Something happening twice a month will not repay the build and maintenance, however tedious it is. |
| Can a competent new hire do it from written instructions? | If the process cannot be written down, it cannot be handed to an agent either. Ambiguity does not survive automation. |
| What happens when it is wrong? | A mislabelled support ticket is recoverable. A wrong payment is not. This determines how much supervision the agent needs. |
| Is the input structured or does someone interpret it? | Interpretation is where agents genuinely help, but it is also where they fail unpredictably. |
What tends to be worth it
- Triage and routing. Deciding where something goes, who owns it, and how urgent it is. High volume, reversible when wrong, and a clear success signal.
- Extracting structure from unstructured input. Pulling fields out of emails, invoices, forms and PDFs into a system that expects clean data.
- Drafting the first version. Replies, summaries, tickets, follow-ups. A human still approves, but they edit instead of starting from nothing.
- Cross-system reconciliation. Comparing what your CRM says against what your billing system says, and flagging the differences.
What to leave alone, at least at first
- Anything that moves money without a human approving it.
- Final decisions about people: hiring, performance, termination.
- Processes that only exist because of a broken upstream system. Fix the source; do not automate around it.
- Anything you cannot describe precisely enough to write down. Automating a vague process produces confident nonsense at speed.
Automating a broken process gives you a faster broken process, and removes the friction that used to make it obvious.
Start with a human in the loop
The version that works is almost always the agent proposing and a person approving, at least for the first few weeks. It sounds like a compromise. It is actually the fastest route to a system you trust, because every approval or rejection is training data for what the agent got wrong.
Once the approval rate is consistently high and you know which cases fail, you widen the agent's authority on the safe cases and keep the human on the rest. That is a decision you make from evidence, not from optimism at kickoff.
Measure the right thing
The tempting metric is hours saved. It is hard to verify and easy to inflate. Better metrics are concrete: how long something waits before it is handled, how often it goes to the wrong place, how many items are still open at the end of a week.
Record those numbers before you build anything. Without a baseline you cannot tell whether the agent helped, and you will end up arguing about impressions instead of results.
How this usually goes
- Pick one process that passes the four questions.
- Write the current process down as steps. If you cannot, that is the finding.
- Record the baseline numbers for two weeks.
- Build the narrowest version that handles the common case, with a human approving.
- Widen scope only where the evidence supports it.
One process, done properly, teaches you more about what is worth automating than a broad plan does. It also means that if the answer turns out to be no, you found out cheaply.