What makes a task worth automating
We look for three things together: the task is repetitive, it's rule-based, and it follows a predictable pattern, and it takes up a meaningful share of someone's day. A task needs all of these. Something repetitive but full of judgment calls isn't a good candidate. Neither is something rule-based that happens twice a year.
A useful test is whether you can write the rule down without the phrase "it depends." If the honest description of a step is "move the ticket to billing when the customer mentions an invoice," that's a rule. If it's "move it to billing unless it's really a product complaint, in which case it depends who the customer is," that's a decision, and it belongs to a person.
Most processes contain both. So we rarely automate a whole workflow at once. We automate the rule-based steps around the decision and leave the decision itself where it is.
Start with the tasks that matter most, not everything at once
It's tempting to map every manual task and automate the lot. We don't. We rank the candidates by how much immediate, visible difference each one makes to the team's day, and start at the top.
This does two things. The team sees the benefit quickly, which makes the next automation easier to adopt. And we learn how that team's process actually behaves in practice before building anything bigger on top of it.
Build it so it can change
A process that's automated today will change. New tools, new team structures, new edge cases. An automation that can only be changed by the person who built it turns into the same kind of fragile, undocumented dependency that makes support workflows break when staff turn over.
So automations are built to be configurable: the rules, thresholds and routing live somewhere the team can update as the process evolves, rather than being hard-coded. The goal is a tool that keeps up with the process, not one that becomes another piece of legacy tooling a few months later.
Where we deliberately don't automate
The goal is to remove repetitive work, not roles. In practice, that means there are a few places where we keep a person responsible on purpose.
The pattern across all four below is the same: automate moving the information, and keep the decision and the accountability with a person.
- ›Taking ownership. In our shift handoffs, tooling carries the alert: urgent items are flagged in the channel the next shift is watching. But the handoff isn't complete until a specific person confirms they've picked up a specific item. An automated "delivered" status tells you a message arrived. It doesn't tell you someone took responsibility for it.
- ›Deciding what a pattern means. After we crossed 200+ reviews, we moved to a fixed weekly review in which people look at all the feedback together, and every recurring issue gets a named owner. Collecting feedback in one place is worth automating. Deciding which pattern matters, and who should fix it, isn't.
- ›Judgment calls in customer conversations. When we set up AI assistants, sensitive or compliance-related questions are routed to a human rather than answered automatically. The routing is automated. The answer isn't.
- ›Exceptions. When something doesn't fit the standard process, it gets logged, and people review those logs. Exceptions are where the next version of the process comes from, so hiding them behind an automated fallback would mean losing the most useful signal the team has.
What makes this harder than it sounds
The line between a rule and a decision isn't always obvious from the outside. A step that looks mechanical in a process document often turns out, once you talk to the people doing it, to include a quiet judgment call that no one ever wrote down. That's why we look at how a task is actually done, not just how it's documented, before deciding it's safe to automate.
The other trap is automating a process that isn't working. A script will repeat a broken step faster and more consistently than a person would. Sometimes the right first move is fixing the process, and automating it afterward.
Key takeaways
- ›Most teams don't lack automation ideas. They lack a way to choose between them.
- ›The best candidates are repetitive, rule-based, predictable and time-consuming, all at once.
- ›If a step can't be described without "it depends," it's a decision, not a rule. Automate around it, not through it.
- ›Start with the automations that make the most immediate difference, not with everything at once.
- ›Build automations to be configurable, so they can change with the process instead of freezing it.
- ›Automate moving the information. Keep ownership, judgment and exceptions with a person.