Automation advice almost always points one direction: automate more. The expensive mistakes we see run the other way. Last quarter we killed three of our own automations, and every one of them had passed the "could AI do this?" test. Could is the wrong question.
The right question is a four-part test: is the task frequent, is it low-variance, is a mistake cheap, and is the process stable? Fail any part and the honest answer is not yet.
Here is the framework we run at Avakata before anything gets automated, with the numbers that make each test concrete.
Count the real cost of a bad automation
A bad automation costs more than the manual task it replaced. You pay to build it, you pay to maintain it, and you pay for every failure it produces while nobody is watching. One of ours saved 20 minutes a week and broke quietly every six weeks, costing four hours per incident to detect, repair, and apologize for. Net effect: negative eleven hours a quarter.
Silent failure is the multiplier. A human who cannot do a task tells you. An automation that cannot do a task often produces something that merely looks done, and you find out from a client.
Twenty saved minutes a week never make the news. The four-hour cleanup always does.
That asymmetry is why the default answer should be manual, and why automation should have to earn its place with arithmetic rather than enthusiasm.
Test one: is it frequent enough to matter?
Frequency sets the ceiling on what an automation can ever save. Our threshold is simple: if a task happens fewer than three times a week, we do not automate it. A 15-minute task done twice a week costs 26 hours a year. If the automation takes 20 hours to build and tune, plus two hours of quarterly upkeep, you barely break even in year one — and most automations do not survive to year two unchanged.
Run the arithmetic before the tooling. Minutes per instance, times instances per year, minus build hours, minus maintenance hours. It fits on a sticky note, and it kills half of all automation ideas on contact.
We keep the math inside the automation's own doc. When the assumptions change, the decision gets re-run instead of re-argued.
Frequency can be borrowed from the future, carefully. If a task is about to scale from twice a week to twice a day — a launch, a new service line — automate ahead of the curve. But only when the scaling is scheduled, not hoped for.
Test two: is the variance low enough?
Automation pays off on tasks where instance one hundred looks like instance one. It fails on tasks where every instance needs its own judgment. Our rule: write down the last ten times you did the task. If more than two of the ten required a decision you could not have scripted in advance, the task is not ready, and the variance will surface as errors the moment you stop watching.
Invoicing passes the test. Client onboarding mostly passes. Scoping a new project fails every time we re-check it, and we have stopped trying.
Ten instances, two exceptions. That is the whole test.
High-variance tasks can still get AI assistance — drafts, checklists, research. Assistance keeps a human deciding. Automation removes the human. The framework only gates the second thing.
Test three: what does a mistake actually cost?
Price the worst plausible failure before you automate, because the automation will eventually produce it. An internal formatting error costs minutes. A wrong number in a client deliverable costs trust. A wrong price in a proposal, a mangled apology, a tone-deaf reply to an upset customer — those can cost the relationship. We automate freely where errors are cheap and reversible, and slowly or never where they are expensive and permanent.
Reversibility matters as much as size. A mistake you can catch and undo inside an hour is a nuisance. A mistake that reaches a client inbox is a liability with your name on it.
This is why our engine drafts outbound email but has never once sent one unreviewed. The 30 seconds of review per message is the cheapest insurance we buy.
Error budgets clarify the gray zone. We tolerate a 2 percent failure rate on internal tasks and effectively zero on anything a client sees.
Test four: is the process stable yet?
Never automate a process you changed last month. Automation freezes a process in place, and a frozen process you are still learning is a bug factory. Our threshold: do the task manually at least ten times, following the same written procedure, without editing the procedure. If the checklist survived ten runs untouched, it is stable enough to hand off. If you kept fixing it, the process is not done being designed.
Manual repetition is not wasted time. It is requirements gathering. Every run teaches you an edge case the automation will need to handle, at a tenth of the cost of discovering it in production.
Version the procedure like code. When the process does change later, update the document first, run it manually twice, then update the automation. Drift between document and automation is where silent failures breed.
Stability is earned in repetitions, not predicted in planning.
What we deliberately keep manual
Four things stay manual at Avakata no matter how good the tooling gets: pricing conversations, scope changes, apologies, and the first strategic draft of anything new. Each one fails at least two of the four tests — high variance, expensive mistakes, or both. They are also the tasks where a client can tell within seconds whether a human actually showed up.
The list is not static. Client onboarding was on it in January. After 30 manual runs the checklist stopped changing, we automated the document assembly in March, and it has run clean for 14 weeks. Humans still make the welcome call.
Clients never push back on the list. The opposite: two hired us this year partly because a competitor had automated exactly one of these.
Keeping something manual is a decision, not a failure. Write the list down, date it, and revisit it when the tests say to.
Score everything quarterly and keep a kill list
Run the four tests against your existing automations every quarter, not just against new ideas. Score each one on frequency, variance, error cost, and stability, then add the hours it actually consumed in maintenance. Anything scoring negative goes on a kill list, and killing it is a win, not a retreat. We review ours on the first Monday of each quarter, and the whole exercise takes 40 minutes.
Last quarter's review killed three: a social cross-poster that mangled formatting weekly, a lead-enrichment step that misfired on 8 percent of records, and a report generator nobody read. Reclaimed: roughly six hours a month.
Automation is a portfolio. Prune it like one.
The framework's output is not really a technology decision. It is a decision about where your judgment still earns its keep, made with numbers instead of vibes — which is the only version of the decision that holds up a quarter later.