Automate the boring parts without automating the mistakes

There is a version of this that ends with the business running itself while you sleep. The version that actually happens is smaller and pays better: 3 or 4 recurring chores that used to eat a Tuesday morning now take 20 minutes, and you read the output before it counts for anything. Getting there is mostly a sequencing problem. Most people buy the tool first, discover halfway through the build that the tool needs a written recipe, and then write that recipe under time pressure while a half-finished workflow is already touching live data.

This guide is for solo operators, freelancers and small teams with nobody on staff to maintain something fragile. It covers picking the first task, writing instructions that survive a change of tool, where the single human checkpoint goes, and how to tell 4 weeks later whether the thing paid. It is not for automating a regulated process where an error has a named legal owner, and it is not a guide to letting an agent operate your accounts unattended. Those are different problems with a different cost when they go wrong, and they deserve a separate decision.

The first task is chosen by frequency, not by irritation

The task you most want to automate is usually the one you hate most, and that is a bad selection rule. Hatred tracks how unpleasant a job feels, not how often it runs, and setup cost only amortises over repetition. Pick by frequency instead. A 20-minute chore you do every Monday burns about 17 hours a year. A 2-hour job you do twice a year burns 4. The Monday chore is worth more automated even though the twice-yearly one feels heavier, and it is the one that will teach you fastest whether any of this works for you, because you get 52 trials instead of 2.

Past frequency there are 3 filters. The task should be text-shaped or document-shaped: drafting, summarising, extracting fields, classifying, reformatting between systems. You should be able to describe doing it as numbered steps without saying “it depends” more than once. And a mistake that surfaces a day later should be annoying rather than expensive, because in the first month some mistakes will surface a day later.

That combination rules out more than it sounds like. It rules out judgments about people, exceptions to policy, final numbers that move money, and any step where the honest description of your method is that you just know. What is left is the recurring middle of the week: turning call notes into an action list, first drafts of the same 4 emails you send every month, pulling fields off invoices into a sheet, tagging and routing what lands in a shared inbox. Unglamorous, which is the point.

Write the recipe before you touch a tool

Do the task manually one more time, slowly, and write down every input, every step, every decision rule, what done correctly looks like, and 2 or 3 real examples of good output taken from work you actually shipped. That document is the automation. Everything after it is just execution.

Keep it in a plain text file you own. This is not fussiness about formats. Anthropic’s own packaging for a repeatable procedure is a folder containing a SKILL.md file with YAML frontmatter, a name and a description, and a body holding “procedural knowledge: workflows, best practices, and guidance” [7]. The same documentation is blunt about the portability you do not get, even inside one vendor: “Custom Skills do not sync across surfaces”, so a skill uploaded to claude.ai is not available through the API, and Claude Code skills are separate from both [7]. If a procedure will not travel between two products from the same company, it will not travel from a visual flow editor to whatever you are using in 2028. Your file is the source of truth. The tool holds a copy.

There is a diagnostic buried in the writing. A recipe that fits on one page automates well. A recipe that keeps sprouting footnotes and special cases is telling you the task is judgment wearing a process costume, and the correct response is to stop and pick a different task. The briefing rules are the ones in prompting fundamentals: context, constraints and a worked example beat clever phrasing.

Level one is the assistant you already pay for

Before any workflow tool, run the recipe by hand in the assistant you already have. Paste the instructions, paste the real input, read the output, note what you had to fix. Ten runs like that tell you more about whether the task is automatable than a week of building, and they cost nothing beyond the subscription you already hold.

The next step is still inside the assistant. ChatGPT will “run one-time or recurring tasks, monitor for changes, and respond to supported events when available” [6]. The caps are worth knowing before you plan around them: active scheduled tasks are limited to 3 on Free and Go, 5 on Plus, 10 on Business and Edu, and 15 on Pro and Enterprise, free accounts can schedule a task no more than once per day, and paid plans go up to once per hour [6]. Event-triggered tasks are not available on Free or Go at all [6].

A ceiling of 5 standing jobs sounds restrictive and is close to the right number for a small operation anyway. The constraint is doing you a favour. If you find yourself wanting 30 scheduled jobs in the first quarter, the problem is rarely that the cap is too low.

Level two is a trigger, and the meter is the part to read

Level two is a workflow tool that runs the recipe on a schedule or an event while you are elsewhere. The selection logic in how to choose AI tools for a small business applies unchanged, with one addition: read how the tool meters you before you read what it can do, because the meter decides which shape of workflow is affordable.

The three usual candidates meter differently, and the difference is not cosmetic. Zapier bills per successful action: “A task is any successful action that runs in Zapier. Only successful actions count toward your task usage”, while triggers, filters, Paths steps, actions that error out, and steps from Formatter, Delay, Looping and Digest do not count [2]. Its free plan covers 100 tasks a month and two-step workflows, Professional starts at $19.99 a month and Team at $69 [1]. Make bills credits, defined as “Each action your scenario performs consumes a certain number of credits - most actions consume 1 credit, while some advanced features leveraging Make’s AI Provider may use more” [3]. Its free plan is 1,000 credits a month with a “15-minute minimum interval between runs”, and Core is $12 a month for 10k credits with scheduling “down to the minute” [3]. n8n bills whole runs: an execution is “a single run of your entire workflow”, and in n8n’s words “It doesn’t matter how many steps are in the workflow or how much data it processes. It’s still a single execution” [4]. Starter is €20 a month for 2,500 executions and Pro €50 for 10,000, with a self-hosted community edition available on GitHub [4].

Read that as a shape rule. Step count is free on n8n and billed by both Zapier and Make, so a long branching workflow that runs a few times a day is cheap in one place and startling in the other two. Run frequency is billed everywhere, so the automation that fires on every inbound email is the one to price before you build it. Do that arithmetic against your real volume from last month rather than your expected volume, which is always wrong in the same direction.

One checkpoint, placed where the money is

Every automation gets exactly one place where a person approves the output before it takes effect: before the email sends, before the row commits, before the file reaches a client. Put it where the risk actually is, which is usually the final step, rather than at 3 separate points until the workflow saves nothing.

This is a first-class feature, not a workaround. n8n’s Wait node exists to “pause your workflow’s execution”, and it can resume on a form submission, documented as “Wait for a form submission before continuing”, or on an HTTP call to a resume URL generated at runtime [5]. If your tool offers an equivalent, use it rather than improvising an approval out of delays and inbox rules.

One checkpoint rather than 5 is a claim about people, not about risk appetite. NIST states the mechanism plainly: “Due to the complexity and increasing reliability of GAI technology, over time, humans may over-rely on GAI systems or may unjustifiably perceive GAI content to be of higher quality than that produced by other sources. This phenomenon is an example of automation bias, or excessive deference to automated systems.” [8] Five approval prompts a day become 5 reflexes by Thursday. One prompt guarding the only step that matters keeps its meaning much longer.

The checkpoint also has to know what it is checking. Output arrives fluent whether or not it is correct, a failure NIST calls confabulation, “a phenomenon in which GAI systems generate and confidently present erroneous or false content in response to prompts” [8]. So write the check as a named list of fields, not a glance: the amount, the date, the client name, the one sentence a stranger could misread. The moves are the ones in the verification habit, with the difference that you are now checking a batch produced while nobody was watching.

Four weeks, one task, counted honestly

Run one automation for 4 weeks with a log. Three columns: time spent including your check, failures the checkpoint caught, failures that got past it. The third column is the valuable one and the first one people quietly stop filling in.

The accounting is end to end. Minutes the task used to take, minus minutes you now spend checking, multiplied by runs per month, minus the subscription. Five minutes saved on drafting is not a win if review now takes 8 because you do not yet trust the output. If the number is still negative after a fair trial, kill it without sentiment and keep the recipe. The recipe was the expensive part and it is still good.

At the end of 4 weeks you have failure examples from your own work, which beats any vendor demo, and a number you can defend. Then, and only then, pick task number 2. Sequential beats parallel here for a boring reason: when 4 new automations run at once and something goes wrong on Friday, you have no idea which one to look at.

The stopping point most operations blow past

Automation has a natural ceiling and it arrives sooner than the marketing implies. When the remaining chores all require judgment, a relationship, or somebody accountable by name, you are finished. The goal was never to automate the business. It was to clear the boring layer off the week so the judgment work gets your attention while you still have some to give it.

There is also a maintenance bill nobody quotes. Every live automation is a small standing liability: a field gets renamed, an app changes its API, a plan’s limits move, and something stops working without announcing it. Four automations you understand beat 12 you inherited from your past self. The same caution applies to the autonomous tier now sold beside the workflow tools and metered in activities rather than tasks, with Zapier’s agents offering 400 activities a month free and 1,500 on a $33.33 plan [1]. Autonomy is exactly the property that turns one small error into 400 copies of it before any checkpoint sees the first.

What still goes wrong

The failure that costs the most is silence. A checkpoint catches bad output and is completely blind to no output. A trigger that stops firing, a connection whose token expired, a folder somebody renamed: none of these produce anything for you to disapprove, and the first symptom is a client asking about something you assumed went out 3 weeks ago. The cheap defence is a standing reminder to open the run history on the same day each month and confirm the counts look like a normal month. Unglamorous, and it works.

The recipe problem is the second one. Some tasks look describable and are not, and you discover this in week 3 when the exceptions arrive: the client who invoices differently, the supplier whose format changed, the case everyone in the business handles by asking you. Each exception gets bolted onto the document until the recipe is longer than the task, and at some point the honest move is to admit the work was judgment all along. That is not a wasted month. Writing down precisely why something cannot be automated is genuinely useful, and unlike the automation it is a document you can hand to a person.

The last limit is portability, and it is worse than it looks from inside a working setup. Skills do not sync between one vendor’s own surfaces [7], plan limits and prices move, and a recipe that exists only inside a visual flow editor is a recipe you will one day rebuild from memory in a hurry. Keep the plain text version current, treat every tool as a tenant rather than a landlord, and accept that some part of this needs rebuilding every couple of years. That is the real running cost of automating the boring parts, and it is still cheaper than the Tuesday morning.