Which Business Tasks to Automate First: A Scoring Method, Plus the Two Things Most Guides Skip

Short answer: automate the task that happens most often, takes the most minutes each time, and causes the most expensive mistake when someone forgets it, provided it needs no judgement. Score every candidate on those four, build the top three, and insist on two things most guides never mention: a log you can read, and a defined answer to "what happens when a step fails".

The scoring method

List every repetitive task someone does by hand. For each, score 1 to 5:

Factor 1 5
Frequency Monthly Many times a day
Minutes per occurrence Under 2 Over 20
Cost of a missed or wrong one Annoying Lost customer or wrong invoice
Judgement needed None, it is mechanical Someone has to think

Add the first three and subtract the fourth. Highest score first. A task that needs judgement does not get automated yet; it gets a checklist, and maybe automation around it (the reminder, the hand-off, the record keeping).

This is close to the frequency-and-impact framing that lowcode.agency published in June 2026, with the judgement filter added, because that is where most failed automations come from.

The usual first three

Across small businesses the top scores land on the same jobs, and the July 2026 survey write-up on dev.to lists the same ones from Zapier, Make and n8n users:

  1. Lead capture to a record. A form, an email or a call note creates a contact and a task, every time, with the source recorded.
  2. Follow-up triggers. No reply in three days: create a task or send the next message. Payment received: start onboarding.
  3. Status-to-notification. When a record changes state (order shipped, booking confirmed, application reviewed), the right person is told, once.

Reporting usually comes fourth: the weekly numbers assembled from two systems and sent on Monday morning without anyone opening a spreadsheet.

Two examples from real pipelines

Scoring and routing. PodVerified needed podcast guests scored on authority, influence and performance for a matching platform. The pipeline runs in Zapier with Airtable as the record: each new guest is scored by rules, stored with the inputs that produced the score, and routed for review (/work/podverified). The point is the stored inputs: anyone can see why a score is what it is.

One event, three systems. Make My Hypno produces a personalised audio recording for a customer. When a recording completes, a single webhook fires to Pabbly, which fans out to a transactional email (Postmark), a logged row with delivery status (Airtable) and a new CRM contact (Go High Level) (/work/make-my-hypno). One trigger, three destinations, one place to look when something does not arrive.

The two things guides skip: logging and failure

Logging. Every run should leave a row somewhere a human can read: when it ran, what it received, what it did, and whether it succeeded. Airtable, a Google Sheet or a database table all work. Without it, "did the customer get the email?" becomes a search through three dashboards.

Failure. Decide, before building, what happens when a step fails:

  • Retry, and how many times.
  • Then alert whom, through which channel.
  • Then park the item somewhere visible (a "needs attention" view) rather than dropping it.
  • And never run a payment or a message twice because a retry fired. Each item needs an ID that the automation checks before acting.

The most expensive automations are the ones that failed quietly for a month. Build the failure path on day one; it is an hour of work.

Zapier vs Make vs n8n in one paragraph

Zapier is the fastest to start and has the widest app library; costs rise with the number of steps. Make is visual, cheaper per operation and better for branching logic, with a steeper first afternoon. n8n gives the most control, bills per workflow run rather than per step, and suits a technical owner or a team with a developer; self-hosting needs someone who can run a server. Most small businesses do well starting on Zapier or Make and moving heavy workflows to n8n or code later. Pricing for all three changes often; check their own pages.

When automation should become code

Three signs: the workflow has more than fifteen steps and branches; it processes hundreds of items a day and the per-step bill is now a line in the budget; or it needs to run on a precise schedule with guaranteed completion. At that point a scheduled job in code with a database table for state is simpler, cheaper and easier to test than a visual workflow. Clinical Stack's shift-cover escalation (notified, reminded, call offered, admin alerted) is a scheduled job for exactly this reason.

Do not automate a broken process

If the manual process has three exceptions a week, automating it produces three failed runs a week. Fix the process on paper first, then automate the fixed version. Several of the 2026 guides make the same point, and it is the one owners most often skip.

Want your list scored?

Send me the five tasks you most want off your plate and how often they happen. I will reply with the scores, which three I would build first, and whether they belong in Zapier, Make, n8n or a scheduled job. Form at /contact, or see /services/automation.

Sources

  • "How to Prioritize Processes for Zapier Automation", lowcode.agency, June 2026, accessed 2026-10-07.
  • "Automate These 5 Workflows First: Real ROI Data from Zapier, Make, and n8n Users", dev.to, July 2026, accessed 2026-10-07.
  • "Automate Your Processes with No-Code: Make, Zapier and n8n for an SME", kolonell.com, June 2026, accessed 2026-10-07.

Questions people ask

What should a small business automate first?

The task that happens most often, takes the most minutes, and causes the most expensive mistake when missed, as long as it needs no judgement. Lead capture to a record is the usual winner.

Zapier, Make or n8n for a small business?

Zapier to start fast with the widest app support, Make for branching logic at lower cost per operation, n8n for control and volume with a technical owner. Check current pricing on their own sites.

How do I stop an automation failing silently?

Log every run, define retries and alerts, park failed items in a visible view, and give every item an ID so a retry never acts twice.

When should an automation be rewritten as code?

When it has many branches, processes hundreds of items a day, or must run on a precise schedule with guaranteed completion.

Can automation fix a messy process?

No. It speeds up whatever the process is. Fix the exceptions on paper first, then automate the fixed version.

Have a project like this in mind?

Tell me what you're building