operations
How to pick your first automation (most people pick wrong)
Jun 30, 2026 · Rishikesh, founder
The demo is always the same. Someone types one sentence into a box, and thirty seconds later there's a finished proposal on screen, or a slide deck, or a quarter's worth of marketing plan. The room goes quiet. Somebody says "we need this." And right there, at peak awe and minimum information, a company picks its first automation.
I did this in my own company. The first thing I automated was the thing that had impressed me most in a demo. It worked in testing, wobbled in week two, and by week four everyone had quietly gone back to doing it by hand. Meanwhile the task that actually ate our week, the dull and repetitive kind nobody would ever put on stage, sat untouched for months.
Here's what I check now before we build anything, for our own companies or anyone else's. Three numbers: volume, rules-density, and cost of error. The demo selects for novelty. Your operation runs on arithmetic.
The three numbers
Volume is how often the task actually happens. Not "constantly" — a count. Open last week's records and tally the instances. A task that happens six times a quarter cannot justify its own automation, no matter how painful those six times feel. A task that happens forty times a week can carry real infrastructure.
Rules-density is the share of instances that resolve with rules you could write down. Sit with the person who does the task and walk through their last ten real cases. If eight of them followed the same script (check this field, look up that record, route it there), you have high rules-density. If every second answer starts with "well, it depends," you don't. Machines eat rules. Judgment is expensive to encode and it's the first thing to break in production.
Cost of error is what happens when the system gets one wrong, because it will. There is a world of difference between a mislabeled email that a human re-labels in four seconds and a wrong figure that goes out to a customer on an invoice. Your first automation should live where errors are cheap, visible, and reversible.
Then multiply, informally. You want high volume, high rules-density, and low cost of error, all at once. Miss badly on any one of them and the task might still be worth automating someday. Just not first.
Why demos point you at the worst candidates
Think about what makes a demo impressive. The task looks hard: creative, judgment-heavy, the kind of work you assumed needed a smart human. That is exactly the profile that fails the three numbers.
Run proposal writing through them. It happens a few times a month, so volume is low. Every deal is different, so rules-density is low. And a mediocre proposal costs you the deal without ever telling you it was the proposal, so the cost of error is high and invisible on top of it. The task scores badly on every axis. It just demos beautifully.
Now take the task nobody puts on stage: pulling fields out of documents and keying them into a system. It happens daily, sometimes hourly. The rules fit on an index card. A mistake surfaces at reconciliation and gets fixed in minutes. It scores clean across the board, and it raises nobody's pulse.
There's a second reason to start boring. Your first automation's real job is not the hours it saves — it decides whether your team ends up trusting automated systems or telling stories about the week the AI embarrassed everyone. In our own companies, the systems that have run longest are the ones nobody mentions anymore. They just work, which is the entire point. A flashy failure poisons the well for a long time. A boring success buys you permission for the next five projects.
Run the method on your own week
Take ten minutes and list the recurring tasks your team touches every week. Aim for around ten of them, big and small. For each one, get the actual count from last week, ask the person who does it how many of their last ten cases followed the standard path, and ask how a mistake would surface and what it would cost to fix. Twenty minutes of this beats any vendor pitch you will ever sit through.
My favorite sanity check: could a sharp temp do this task on their second day with a one-page SOP? If yes, it is automatable now. If they would need a month of context and a feel for company politics first, it is not a first automation, whatever the demo suggested.
And put a number on what boring is worth. If four people on your team each spend an hour a day moving data between systems, that is twenty hours a week. Multiply by your own loaded hourly cost and you have the annual budget that one dull task hands you. Do that math for the first time and you will probably go quiet for a moment. The unglamorous task was the expensive one all along.
Seven checks before you build
Run your candidate task through these. Every no is a reason to pick a different first project, not a reason to build more carefully.
- It happened at least twenty times last week, and you counted rather than estimated.
- The handling rules fit on one page, and the word "usually" isn't carrying them.
- A wrong output gets caught in minutes by someone downstream, not discovered in an audit.
- Two different people on your team do the task the same way.
- You can verify the machine's work by sampling a few cases, not re-doing all of them.
- Nobody in the company would argue about what a correct result looks like.
- If it broke for a day, you'd be behind on work, not in trouble with a client or a regulator.
Treat your first automation as a trust project. The hours come later. Pick something with brutal volume, rules a temp could follow, and mistakes that cost minutes, then let it run quietly for a month and let your team catch it being reliable. After that, the harder and more interesting projects get easier to sell internally, because the machine has a track record instead of a highlight reel.
When you're ready to put real numbers against a candidate task, run your own figures through our ROI calculator. It does the arithmetic. You bring the honesty.