A map of what to automate, what to give a model, and what to leave alone

Most 'should we use AI for this' questions answer themselves the moment you ask a smaller one: can you write the rule down?

If you can state the rule in plain terms and it holds every time, automation handles it. It's cheaper and faster, and it costs no tokens. If you can't write the rule because the task needs real judgment, a model earns its keep. There's a third pile as well, one most people would rather not admit exists: tasks that should stay with a human, or not be done at all.

That's three buckets. This field guide takes the automation-versus-AI distinction and turns it into work you can actually do at your desk. You can run your own stack through it.

Bucket one: if a rule can write it, automate it

If the logic is deterministic - same input, same right answer, every time - it's automation, and there's no reason to put a model near it.

Round-robin a new lead by territory. Set a renewal task 90 days before contract end. Sync a closed-won deal into finance. Send the follow-up when a form comes in. Flag a deal that's sat in one stage past its sell-by date. Every one is a rule you can write on an index card, and a workflow will run it forever without thinking, because it doesn't need to. A decent check is whether the work would bore anyone doing it by hand. If the task comes out identical every time, put a machine on it and let your people spend the hour elsewhere.

This is also where a rep's day disappears to. Salesforce's State of Sales research finds reps spend under 30% of their time selling, and a lot of the rest is bucket-one work a machine should have owned years ago.

A model here only makes things worse. You'd be paying tokens to make a reliable task occasionally creative, and creative is the last thing you want from lead routing. This is what plain automation is for, and most of a healthy RevOps stack lives right here.

Bucket two: if it needs judgment, give it a model

If a human currently reads something and makes a call a rule can't capture, that's a model.

Routing the lead is a rule's job. Reading an inbound message to work out whether it's a real buyer or a student doing research is judgment, and so is reading the sentiment in a support thread, deciding whether two records are the same company when the names don't match, scoring a lead on the language they actually used rather than the boxes they ticked, or turning twenty call notes into what's really blocking a deal. Rules can't hold any of these for long. Every attempt to write one ends in forty exceptions.

When your rule needs a dozen 'unless' clauses and still gets it wrong, stop writing rules. That's a job for a model grounded in your own data.

Bucket three: leave it to a human, or don't do it at all

Some tasks shouldn't be automated or modelled at all. They belong with a person, or they should stop happening.

The hard, rare judgment call - which of two strategic accounts gets the exec's afternoon - stays human, because the cost of a wrong answer dwarfs the time saved. Deciding to fire a customer sits here too, and so does the apology, and so does anything where the entire point is that a person paid attention.

Then there are the tasks that survive on habit alone, like the report no one reads, or the field still maintained because someone asked for it back in 2019. Automating those is worse than doing nothing, because the waste becomes permanent and invisible. One audit I ran found 722 custom properties on a portal, 203 of them empty. For most of them the right move was never to automate the upkeep. It was deleting them.

Often the cheapest task is the one you stop doing, so ask whether a task should exist before you ask what to run it on.

How to tell bucket one from bucket two

The line between 'automate it' and 'model it' is one question: can you write the rule so it's right every time, or only most of the time?

If the rule comes out right every time, automate it. If it's only right most of the time, you're looking at judgment, and judgment is what a model is for. When you're reaching for the fourteenth 'if this, then that' branch and the exceptions are still winning, you've found a bucket-two task dressed up as bucket one.

Imagine training a new hire. If you could hand them a one-page checklist and walk away, it's a rule, so automate it. If you'd have to tell them they'll get a feel for it after fifty of these, it's judgment, and a model can carry it. And if you'd honestly tell them not to bother, that's bucket three.

The mistake almost everyone makes

The most common failure is a model doing a rule's job.

Someone puts a language model on lead routing because AI is in the budget, and now a task a workflow ran perfectly costs money, adds latency, and sometimes gets it wrong for reasons no one can trace. What you're left with has the downsides of automation and AI both, and the upside of neither.

The opposite failure is a person still doing bucket-one work by hand, copying deals into a spreadsheet every Friday, because nobody wrote the ten-minute rule.

Sort honestly and most tasks fall into place. Write rules where you can write rules. Reach for a model where you can't. Keep a person on the handful of things that actually need one, and use the delete key on the rest.

Common questions