A triage board for what to automate first, and what to leave alone

The most expensive hour in a small company is the one spent arguing about which annoyance to fix first. An owner, an ops lead, and whoever runs the books can each name five repetitive tasks they hate, nobody holds the numbers to compare them, and the meeting ends where it started. Last night I built a free tool that settles that argument in about three minutes: you list the repetitive tasks in your week, and What To Automate First ranks them by what each one actually costs you a year, in hours and in dollars, and tells you in plain words which to automate now, which are quick wins, and which to leave with a person. It runs entirely in your browser. Nothing you type leaves your machine.

This is the build log: what I decided, what broke, and what the thing honestly cannot do.

The gap in standard automation advice

Most discussions of business automation argue that the right first automation is not necessarily your biggest time sink, it is the small, critical task that quietly does not happen when everyone gets busy. The follow-up chasing that never goes out, the review request nobody sends, the invoice that ages a month because reminding people is miserable. But general principles and advice do not rank your operational tasks for you.

That gap is concrete. Across small-business operations, task-level triage is a constant bottleneck: operators asking some version of "which of my repetitive tasks can actually be safely automated, and where do we start." The survey data says the same thing from the other direction. In Goldman Sachs' 10,000 Small Businesses survey, 73 percent of small businesses said they would benefit from more training and implementation resources, and only 14 percent have AI embedded in core operations. Three quarters of them are already convinced. They are stuck on the first concrete decision, which is not "should we use AI." It is "which task first."

Every existing answer to that question that I could find belongs to a vendor. You take a quiz, the quiz concludes that their product is the answer, and the quiz was never going to conclude anything else. So the design premise for this build was the same one behind the switching-cost calculator I shipped the night before: build the version that is allowed to tell you no. This tool will tell you a task is not an automation candidate at all, and it says so with the same visual weight it gives the good news.

What I decided, and why

The tool asks six things about each task. The name. How many times a week it runs. Minutes per run. The hourly cost of whoever does it. How rule-based it is, on a three-step scale from "same steps every time" to "real judgment every time." And one question most calculators would never think to ask: does this task quietly get skipped when things are busy?

That last question is the article's thesis wired directly into the math. A task that silently stops happening under load is worth more than its hours suggest, because the cost of it not happening lands later, as an unpaid invoice or a missing review or a lead that went cold. The scoring gives those tasks a meaningful boost. The biggest time sink does not automatically win, and that is deliberate.

The second decision was harder, and I think it is the one that makes the tool honest. If you tell the board a task takes real judgment every time, it will not recommend automating it. Ever. Not at any dollar figure. A task like that shows up in the ranking with its annual cost displayed honestly, sometimes a painfully large number, and a verdict that says it needs a person. I built it that way because the alternative is the thing I keep warning people about: the failed automation of a judgment call, which costs you the build, the cleanup, and usually a customer. The tool would rather show you an expensive truth than a cheap recommendation.

The third decision was about presentation. The previous night's build taught me that a calculator whose form towers over its answer is backwards, so this one inverts it. The reading sits at the top of the page, directly under the headline: one sentence naming your top pick and what it is costing you, then a ranked table with the figures lined up in columns you can actually scan. The input rows live below it. When the board has nothing to read yet, it says so plainly instead of showing you an empty grid. And the whole reading is copyable as plain text with one button, with labels and units intact, because the most likely destination for this ranking is an email to whoever approves the time to fix things.

What broke on the way

Two things, and they are both worth telling because they are both the kind of thing that eats an evening.

The first was my own verification. I test these builds the way a user would, in a real browser, with wrong input and junk input and a phone-width window. My test script kept filling the wrong fields, and it took me two rounds to see why. The numeric fields in this tool are deliberately plain text fields under the hood, because the tool holds exactly what you typed and does its own careful reading of it, rather than letting the browser silently rewrite your input while you type. The cost of that choice is that a name field and a number field look identical to any tool, or any screen reader, that is navigating by field type. The fix was already half-built into the design, because every field carries a real visible label, and once the script navigated by label instead of by position everything passed. The lesson is clear for accessible form design: a field that holds raw text but represents a numeric value must declare its semantics explicitly.

The second was smaller but dumber. The tool clamps every numeric input so that nothing absurd can blow up the math or the layout, including a hard cap on how many characters a number field accepts. During testing I accidentally pasted a task name into a frequency field, watched it get truncated to twelve characters, and spent a genuinely confused few minutes convinced I had found a data-eating bug. I had not. The guardrail was doing its job on input I never intended to give it. Half of debugging is distinguishing an actual defect from an intentional input defense, and defensive boundary limits must always be explicitly documented alongside their rationale.

The underlying scoring engine was built with high test coverage: the scoring logic lives in its own pure module with 45 unit tests covering boundary cases where classification verdicts flip.

What it cannot do

Every tool built in an evening has edges, and naming them is the difference between a build log and an advertisement.

It cannot tell you how to automate anything. The board ranks the payoff, it does not scope the project. Whether the answer is a workflow in a tool you already pay for, a small custom build, or a checklist taped to a monitor is exactly the kind of judgment the tool refuses to fake.

It trusts your estimates completely. If you tell it a task runs five times a week at twenty minutes, it believes you. Operators reliably underestimate how often the annoying thing happens, so if anything the readings run low.

It ranks payoff, not payback. The board does not know what building any given automation would cost, so a high rank is a reason to scope something, not proof it is worth doing. The switching-cost calculator next to it on the shelf covers the other half of that question for the buy-versus-stay case.

Its thresholds are calibrated, not revealed. A task just above the line reads "automate now" and a task just below it reads "quick win," and the face does not currently show you where that line sits. That is the sharpest edge on the instrument tonight, and it is first in line for the next pass, because a gauge you cannot calibrate against is a gauge you eventually stop trusting.

And frequency is weekly, which means a monthly task makes you do arithmetic in your head to enter it. I noticed this while entering a monthly board report as "0.25 times a week" and feeling faintly ridiculous doing it. A proper frequency selector costs one control and is on the list.

The part worth chewing on

The whole build took an evening because the constraint did the designing. No accounts, no server, no stored data, no external calls, nothing to breach and nothing to maintain. Every feature the tool refused to have is a category of failure it cannot experience. The interesting thing about the ranking it produces is that the most valuable row is usually not the one at the top. It is the expensive task near the bottom marked "needs a person," because that row is the tool telling you where automation ends, and a tool that knows its own edge is rarer than a tool that works.