AI automation vs hiring: compare tasks, not roles

Start from a normal week, not from the job description. List what the person would actually do, one task per line, in the words someone would use to describe it to a new colleague: answers routine customer email, enters orders into the accounting package, chases invoices that are late. A line such as customer service or admin is a heading, not a task, and it hides the parts that behave differently.

Put hours against each line, and take them from a system that already records the work where one exists: the inbox, the order log, the ticket queue. Memory favours the interesting tasks and tends to drop the small repeated ones, so a list built from memory can leave out exactly the tasks that are easiest to hand over.

For each line, ask whether the output can be checked by someone who did not produce it, and whether a mistake can be reversed cheaply. Which work AI can take on sets out that test in full. The tasks that pass are the candidates. The tasks that fail stay with a person, and that is not a defect in the plan; it is the plan.

Then count the exceptions. A task that is handed over still produces the odd order, the unusual request and the document that does not arrive, and each of those lands back on someone. Treating a task as fully handed over when its exceptions return to a person is a common way for the sum to flatter automation. The exceptions are a line in the list, with their own hours, and they join the tasks that stayed.

Every figure in this section is invented to show the arithmetic. None of it describes a real business, a real client or a result Praxis has produced, and none of it is a benchmark. Suppose a business is weighing a hire for 40 hours a week.

Taken apart, the week is: routine customer email, 10 hours; entering orders, 8; chasing late invoices, 4; scheduling and rescheduling, 5; calls with the largest customers, 8; and odd requests that fit no routine, 5. That is 10 + 8 + 4 + 5 + 8 + 5 = 40 hours.

Suppose the first four lines pass the test and are candidates to hand over: 10 + 8 + 4 + 5 = 27 hours. Suppose, again only for the sum, that the exceptions those four tasks throw up come to 4 hours a week and land back on a person. The hours handed over are then 27 - 4 = 23. The hours that stay with a person are the calls (8), the odd requests (5) and the returned exceptions (4), which is 17. Check: 23 + 17 = 40.

Read what that says. Automation covers 23 of the 40 hours, and 17 hours remain a person's work whichever way the decision goes. So the question was never one person or none. It is whether 17 hours a week of calls and judgment is a job, or part of someone's job already. If it is part of an existing job, the hire may not be needed at all; if it is a job, it is a different job from the one first imagined.

For the cost side, multiply the 23 weekly hours by 46 working weeks, the single assumption the savings estimator uses, to get 1,058 hours a year. Multiply that by your own loaded hourly cost, which is a number only you can supply and which this page does not. Set it against what the automation costs to build and keep running and what a hire costs to find, train and keep. Neither side is on this page, because neither is a fact about your business until you write it down.

The sum can come out the other way. If most of the week is judgment, relationships or work whose output nobody else can check, little passes the test, the handed-over hours are small, and the hire is the straightforward choice. The same is true when the volume is low: the estimator prints a floor, and below it says plainly that the work is not worth automating yet.

It is also true that the two are not exclusive. A hire whose week no longer contains the 23 hours is doing a different job from the one that would have existed without the automation. Writing that down before the hire is made is part of the decision.

Whichever way the sum goes, the task list with its hours is the baseline. Keep it, read it from the system that was already running, and measure the same lines the same way a month and three months after the change. If the hours did not move, the change did not do what the sum said, whether it was a hire or a build.

Faster and wrong is not a saving, so include what breaks alongside how long it takes: error rate, rework and how often the task is late. Estimating the hours on your own numbers is a reasonable first pass before any of this is measured properly.