Automation goes for the boring task first

You have a list of things you do every week that a machine should obviously be doing. Invoice chasing. Renaming and filing client assets. Turning a call recording into a summary someone will actually read. You have probably tried to automate two or three of them, and the automation is now either switched off or quietly producing garbage that you fix by hand, which is worse than not having it.

The failure is almost never the tool. It is the choice of task. People pick the task that annoys them most, or the one that would be most impressive to have automated, and both are the wrong criteria. There is a better test, and the clearest illustration of it comes from a company with an effectively unlimited automation budget deciding what to automate first inside its own buildings. This guide is not for anyone running work where a single bad output has legal, medical or financial consequences; the test below deliberately excludes that work, and so should you.

Meta automated the power button, not the technician

On 30 August 2026, Ars Technica ran WIRED reporter Paresh Dave’s account of robots being tested inside Meta’s data centers, based on several current and former workers who asked to remain anonymous [1]. The task list is short and unglamorous: plugging in cables, resetting servers, cutting power to machines [1]. Meta is using robots and related hardware from several vendors including Watney Robotics, Kinova and ABB, and in one experiment is evaluating whether a Kinova Gen3 robotic arm could be used for power cycling [1]. A different robot is being tested to swap networking cables [1]. One Meta data center worker estimates that if it is successful, the bot could replace up to 80 percent of some people’s workloads [1]. Meta declined to comment on the testing; spokesperson Francis Brennan said the company needs “more workers, not fewer” [1].

The detail worth keeping is the smallest one in the story. At some facilities, Meta quietly adopted a robot that looks like a finger, or perhaps a pointy stick, that can press the power button on a Mac Mini or other device to restart it when remotely prompted by a human [1]. No model. No reasoning. No arm. A stick that presses a button.

That is what the first successful automation looks like at a company that could fund anything. It did not start with the hardest job in the building, or the one that would make the best announcement. It started with an action that happens constantly, is identical every time, and is instantly verifiable, because either the machine came back up or it did not. The same reporting notes why the ambitious version stayed unbuilt for years: robots were expensive, and in earlier trials in the industry they sometimes crushed servers while attempting simple tasks [1]. The cheap stick shipped. The clever arm is still an experiment.

The four tests a task has to pass

The first test is volume. The task has to happen often enough that you would notice it stopping. If you do it four times a year, automating it will cost more attention than doing it, because you will have forgotten how the automation works by the time it runs again. Count the actual number for last month before you estimate it, because the tasks that feel constant and the tasks that are constant are usually different tasks.

The second test is sameness. Write the task out as steps another person could follow without asking you a question. If you cannot, the variance lives in your head, and the automation will hit that variance on run three and produce something confidently wrong. A task that starts with “it depends on the client” fails this test until you have written down what it depends on.

The third test is checkability. You have to be able to tell in a few seconds whether a single output is right, by looking at one field, one number, or one sentence. This is the test that kills most content automation. A drafted email that is subtly off-tone takes as long to evaluate as it would have taken to write, so the automation saves nothing. A renamed file either matches the naming convention or it does not, which takes half a second.

The fourth test is blast radius. Being wrong has to be cheap and reversible. Pressing a power button on a machine that was already unresponsive has almost no downside. Sending a payment, publishing a post, or emailing a client list has a large one. Note that Meta’s own hard case, the arm near the servers, is the one still being evaluated, and the low-consequence button-presser is the one already adopted [1]. That ordering is not caution for its own sake. It is what makes the first automation survive long enough to be worth a second.

The pricing model decides which automations are affordable

Once a task passes, the cost question is usually answered in the wrong order. People budget for the model and ignore the plumbing, when it is nearly always the other way round.

The three main connector platforms meter differently, and that difference matters more than the sticker price. Zapier counts a task only when a Zap successfully completes an action, and never charges a task to check for new data; its free plan includes 100 tasks a month with two-step Zap workflows, and paid plans start at $19.99 a month [2]. Make charges credits per action inside a scenario, with most actions consuming 1 credit and some AI features consuming more, so a scenario that reads a row, transforms it and writes it somewhere costs three rather than one; its free plan includes 1,000 credits a month and the Core plan starts at $12 [3]. n8n counts one execution per run of your entire workflow, and it does not matter how many steps are in the workflow, with the Starter plan at 20 euros a month billed annually for 2,500 executions and a self-hosted Community Edition available on GitHub [4].

That means the same automation has a different price depending on its shape. A long workflow with many small steps is expensive on Make and cheap on n8n. A workflow that polls constantly but rarely acts is cheap on Zapier. Work out which shape yours is before you pick the platform, not after.

The model call is usually the rounding error. Sending roughly 3,000 tokens of input and getting 500 back on Claude Haiku 4.5 costs about $0.003 in and $0.0025 out, a little over half a cent per run at $1 and $5 per million tokens [5]. OpenAI’s gpt-5.6-luna is cheaper still at $0.20 and $1.20 per million [6]. Both vendors cut batch processing to half the standard rate for work that does not need an answer immediately [5][6]. Against that, a Claude Pro subscription at $20 a month [8] or a connector plan is the real recurring line.

The check is part of the task, not an extra

An automation without a failure path is not finished, it is just untested. The awkward part is that most platforms make silence look like success. Zapier counts a task only when an action completes successfully [2], so a Zap that has been failing every morning for a week shows up as a smaller bill, not a bigger one. Nothing in the invoice tells you that the work stopped.

Build the alarm at the same time as the workflow. In n8n this is a specific, documented thing rather than a habit: you create a new workflow with an Error Trigger as the first node, save it under a name like Error Handler, and select it under Error workflow in the settings of the workflow you want watched, after which you can send email or Slack alerts when a workflow execution errors [7]. You can use the same error workflow for multiple workflows [7]. You can also force executions to fail under your chosen circumstances with the Stop And Error node, which is how you turn “the client reference was empty” from a silent bad output into a loud failure [7]. To investigate failures afterwards, you review your executions, either for a single workflow or for all the workflows you have access to [7].

The other half of the check is the handover. Run the automation alongside the manual version for one full cycle, a week or a month depending on the task, and compare outputs before you stop doing it by hand. This is tedious and it is the step everyone skips. It is also the only way you find out that the automation works on the 40 normal cases and mangles the 3 unusual ones, which is the outcome you should expect rather than fear.

Run the same test on the work you sell

The uncomfortable version of this guide points outward. The four tests do not care whose task it is, and your clients can apply them to the work they buy from you.

If a meaningful share of your billing is for work that is high volume, identical each time, checkable in seconds and cheap to get wrong, that revenue is priced against the tools, not against your time, whether or not anyone has told you yet. That is the actual lesson in the Meta story: the company automating other people’s workflows applied the same logic to the maintenance labor in its own buildings, in an effort that had not been previously reported, and worker group chats in Altoona turned demoralized while a reporter put the pieces together [1].

The response is not to hide the automation. It is to move what you charge for. Bill for the judgment that decides what the automation should do, the cases it is not allowed to touch, and the responsibility for it being right. Sell the setup and the ongoing check as the product, and be the person who has already run the four tests on the client’s task list. That work fails test two and test three, which is exactly why it survives.

What still goes wrong

The tests are a filter, not a guarantee. Plenty of tasks pass all four and still fail in practice, usually because the thing on the other end of the connection changed. An app updates a field name, a form gets a new question, a client starts sending PDFs instead of spreadsheets, and the workflow keeps running while producing nothing useful. Maintenance is real work, and if you automate more than about five or six tasks you have acquired a small system to look after. That system has no on-call rotation and no colleague who knows how it works.

The checkability test is also the one people fudge. It is tempting to decide that you will “spot check” outputs, which in practice means you check for two weeks and then stop. If the only viable check is reading the whole output carefully, the task did not pass, and the honest move is to leave it manual. Content and client communication fail here far more often than people want them to.

Finally, the outward-facing section is a direction of travel, not a schedule. Meta is still evaluating an arm for power cycling rather than deploying it, and one robotics chief executive quoted in the same story says there have been a lot of pilots and demos but no provable working solution [1]. The gap between a working pilot and a changed job can run for years. Do not reprice your services in a panic. Do run the four tests on your own billable work once a quarter, and notice which line items keep passing more of them.