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, you don't need a model. You need automation - cheaper, faster, and it doesn't cost a token. If you can't write the rule, because the task needs real judgment, that's where a model earns its keep. And a third pile nobody likes to admit exists: tasks that should stay with a human, or not be done at all.

Three buckets. This is the field guide to the automation-versus-AI distinction - less theory, more sorting. Here's how to sort your own stack.

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. Don't put a model on 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. The test is boredom: if the task is identical every time, it should bore a machine, not occupy a person.

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

A model here is a liability, not an upgrade. 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.

Not 'route the lead' - a rule does that. But 'read this inbound message and tell me whether it's a real buyer or a student doing research' - that's judgment. 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 words they used, not the boxes they ticked. Turning twenty call notes into what's really blocking a deal. These resist rules. Every attempt to write the rule ends in forty exceptions.

The tell is simple: if 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

The bucket nobody sells you: some tasks shouldn't be automated or modelled. They should stay with a person, or stop.

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. The decision to fire a customer. The apology. Anything where the entire point is that a person paid attention.

Then the tasks that survive on habit alone. The report no one reads. The field maintained because someone asked for it in 2019. Automating those is worse than doing nothing, because now the waste is permanent and invisible. One audit I ran found 722 custom properties on a portal, 203 of them empty. The right move on most wasn't to automate their upkeep. It was to delete them.

The cheapest task is the one you stop doing. Ask whether it 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?

Right every time is automation. Only-most-of-the-time is the fingerprint of 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 wearing a bucket-one costume.

A quicker version of the same test: imagine training a new hire. If you could hand them a one-page checklist and walk away, it's a rule - automate it. If you'd have to say 'you'll get a feel for it after fifty of these', it's judgment - give it a model. And if you'd say 'honestly, don't 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. That isn't automation and it isn't good AI. It's the worst of both.

The quieter failure is the reverse: 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. Rules where you can write rules. Models where you genuinely can't. A person where it counts.

And a delete key for everything else.

Common questions