Cost per Executed Task: The Unit-Economics Model We Use to Decide Between Automating a Process and Hiring an Ops Person

Why "hours saved per week" is the wrong unit, and what to use instead

Use cost per executed task, not hours saved per week. Divide the fully loaded annual cost of running a process by the number of times it actually executes in that year. Do this twice, once for the human version and once for the automated version, and compare the two numbers directly.

Hours saved per week fails for three reasons. It assumes the reclaimed hour has a buyer, which it usually does not when the person doing the task also answers the phone and greets members. It hides volume, so a process that runs 40 times a year looks identical on paper to one that runs 4,000 times. And it silently excludes the costs that arrive after launch: the maintenance drag when a supplier changes a CSV format, the error-correction cost when an automation writes a wrong value into 300 records before anyone notices, and the seasonal spikes that make a system idle for eight months and saturated for four.

Cost per executed task fixes all three, because volume sits in the denominator. It also gives you a single number you can put next to a real quoted salary and defend to a board, which is what founders are actually trying to do when they search for whether automation is cheaper than hiring.

The formula: what goes into the numerator on both sides

The human side is loaded salary times the fraction of that person's time the process consumes, plus tooling, plus the cost of their mistakes. The automated side is amortised build cost, plus annual maintenance, plus runtime and infrastructure, plus the residual human time nobody can remove, plus the cost of automated mistakes. Both divide by annual task count.

The two lines founders consistently forget are maintenance drag and residual human time. Maintenance drag is not hypothetical: every integrated process we have built has an upstream system that changes without warning, whether that is a courier API deprecating an endpoint, a payment provider changing webhook payloads, or a retailer emailing a spreadsheet with two new columns. We budget it as a percentage of build cost per year rather than pretending it is zero. Residual human time is the exception queue. An automation that handles 92 percent of cases still needs someone to look at the other 8 percent, and if that person has to context-switch into the process cold, each exception costs more than a task did when they were doing all of them.

Error-correction cost is the line that decides several of these comparisons. Humans and automations fail at different rates and, more importantly, at different blast radii. A person mistypes one address. A bad deployment mistypes four hundred. When the downstream cost of a single error is high, for example an incorrect diagnostic result reaching a customer, the error term dominates the entire model and pushes you toward a human gate regardless of volume.

• • Human cost per task = (loaded salary x share of role) + tools + (error rate x cost per error) / annual task count
• • Automated cost per task = (build cost / amortisation years) + annual maintenance + runtime + residual human minutes + (automated error rate x cost per error x blast radius) / annual task count
• • Loaded salary means gross plus employer contributions, equipment, software seats, management overhead, and recruitment amortised over expected tenure, not the headline number in the job ad
• • Amortise build cost over the honest life of the process, not over five years by default. If the business model is changing next year, amortise over one
• • Count the task, not the batch. If someone processes 30 onboardings in one sitting, that is 30 executions, and the automation only has to beat the marginal one

Six recurring processes, and where each one crossed the line

Across three clients we ran this model on six recurring processes: retailer onboarding and product catalogue ingestion at Plodovi, membership admin and class booking reconciliation at MOVE & MEET, and kit dispatch plus result release at GlycanAge. Four crossed under the loaded cost of an ops hire. Two never did, and we said so.

The pattern that emerges is not about how tedious the work is. It is about volume, variance, and blast radius. Retailer product catalogue ingestion at Plodovi is high volume and highly repetitive, and the same shaped file arrives from the same partners week after week, so the cost per executed task collapses quickly as more retailers join. Kit dispatch at GlycanAge is similar in shape: address validation, label generation, courier handoff, and status writeback happen identically thousands of times, and the marginal cost of one more dispatch approaches the runtime cost of a function call.

Retailer onboarding itself is a different story. It runs a handful of times a month, every retailer has a different idea of what a product record contains, and half the work is a phone conversation. We automated the mechanical parts, the data validation and the account provisioning, and left the conversation and the judgement calls with a person, because the cost per executed task for a fully automated onboarding never got near the cost of the hour a human spends doing it well. Class booking reconciliation at MOVE & MEET crossed the line early, because it ran daily, was purely arithmetic, and the error-correction cost of a human doing it at 10pm after teaching a class was high in both money and goodwill.

• • High volume, low variance, low blast radius: automate early. Catalogue ingestion, kit dispatch, booking reconciliation.
• • High volume, low variance, high blast radius: automate the mechanics, keep a human gate on release. Result release at GlycanAge is clinician-gated by design, and the gate is a feature, not a cost to be optimised away.
• • Low volume, high variance: keep it human. Retailer onboarding conversations, bespoke partner requests.
• • Low volume, low variance: usually a scheduled script rather than a system. Do not build a product for something that runs twelve times a year.

The volume threshold: where a part-time human is simply cheaper

Below roughly a few hundred executions per year, most custom automation loses on cost per task, because build and maintenance costs sit in the numerator no matter how few times the process runs. The precise threshold is where amortised build plus annual maintenance divided by annual volume exceeds the loaded hourly cost of the person times the minutes the task takes them.

Work an example with round numbers you can substitute your own into. Suppose a task takes a person 12 minutes, their loaded cost is 30 per hour, so the human cost per task is 6. If a custom automation costs 15,000 to build, is amortised over three years, and carries 2,500 a year in maintenance and runtime, the annual automated cost is 7,500. At 500 executions a year that is 15 per task, more than double the human. At 2,000 executions it is 3.75 per task. At 5,000 it is 1.50. The crossover in this example sits at 1,250 executions per year, and everything below that is an argument for a part-time person, not a system.

Two adjustments move the threshold materially. First, if the process is seasonal, use peak-period volume and peak-period pain rather than the annual average, because the real question is often whether you can survive December without hiring, not whether the average month is efficient. Second, if a no-code tool or an off-the-shelf product handles 80 percent of the process for a subscription fee, that becomes the automated numerator, and the crossover drops sharply. Custom build is the expensive option in this model and should be reserved for processes where the shape of your business is the reason no product fits.

Seasonality, error-correction, and maintenance drag: the three lines that flip decisions

Seasonality changes what you are buying. A human ops hire is a fixed annual cost that you carry through the quiet months; an automation is a fixed build cost with near-zero marginal cost during peaks. When a process triples in volume for one quarter, automation often wins on peak capacity even when it loses on annual average cost per task.

Model seasonality by splitting the year into peak and off-peak and computing cost per task in each. Plodovi's order and catalogue volume moves with the growing season, and MOVE & MEET's membership admin spikes in January and September. In those months the human option does not just cost more, it fails, because you cannot hire and train a person for a six-week surge and the existing team absorbs the overflow by working late. Cost per task does not capture that failure mode, so we add a simple flag: does the human option break at peak volume? If yes, the comparison is no longer purely economic.

Maintenance drag and error-correction are the reverse pressure. We treat maintenance as a real recurring line, sized by how many external systems the automation touches, because a process wired into a courier API, a payment provider, and a partner spreadsheet has three independent sources of breakage. And we size error-correction by blast radius rather than frequency. A human error is usually one record; an automation error is usually every record processed since the last deploy. If discovering an error is slow and reversing it is expensive, the automation needs a validation layer, and that layer belongs in the build cost, not in a future roadmap.

Running the model yourself in an afternoon

You can populate this model in an afternoon with a spreadsheet and one conversation with whoever currently does the work. Count executions for the last 12 months, time three real executions with a stopwatch, load the salary properly, get a build estimate with a maintenance percentage attached, and compute both sides. Then check the two flags: blast radius and peak failure.

The most common mistake at this stage is over-scoping. Founders describe the process as they wish it worked, not as it runs, and the resulting quote is for a system rather than for the automation of an existing task. Split the process into steps first and price each step, because in almost every case we have run, the economics are excellent for two or three steps and terrible for the rest. Partial automation with a human exception queue beats full automation on cost per task far more often than founders expect.

The second mistake is treating the decision as permanent. Volume moves. A process that fails the test at 400 executions a year passes at 1,800, so re-run the model annually against actual counts rather than assuming the original answer still holds. When we scope work at Jaspero, this is the arithmetic we run before quoting, and it is also the arithmetic that has led us to tell clients to leave two of these six processes exactly as they are.

• • Pull the real execution count for the last 12 months from your system logs, order table, or booking records
• • Time three real executions end to end, including the interruptions, and take the median
• • Load the salary: gross, contributions, equipment, seats, management time, recruitment amortised over tenure
• • Get a build estimate broken down per step, with an explicit annual maintenance percentage attached
• • Compute cost per task on both sides at current volume, at half, and at triple
• • Flag blast radius: what does one automated error cost, and how many records does it touch before detection
• • Flag peak failure: does the human option break during your busiest six weeks

For the operational detail behind these numbers, including the automations we built and then reverted, see our task-by-task automation audit from MOVE & MEET and Plodovi.