The first automation is the hardest — not technically, but decisionally. There are a hundred candidate tasks, everyone has an opinion, the tools all look equally plausible, and the graveyard of abandoned automation projects is full of businesses that picked wrong, got discouraged, and concluded “automation isn’t for us.”
Here’s the framework we use to pick a client’s first five automations, in order. It’s a scoring rubric you can apply in an hour, and it exists to answer the question that actually determines success: not “what should we automate?” but “what should we automate first, such that we’re still automating things a year from now?”
The four scoring dimensions
List every candidate task (get the team to help — the tasks you personally never touch are invisible to you), then score each 1-5 on:
Frequency. How often does it happen? Daily tasks score 5, weekly 4, monthly 3, quarterly or rarer 2 or less. Frequency dominates because automation ROI is a per-execution advantage multiplied by executions — the ROI math rewards nothing so much as repetition.
Pain. How much does each execution actually cost in time, errors, or dread? This is the term the team’s energy comes from — automating something everyone hates builds goodwill for the next four projects. But pain alone, without frequency, produces toys: automating the agonizing annual task feels great and pays back never.
Stability. Will the task look the same in six months? Same steps, same systems, same shape? Tasks built on systems you’re about to replace, or processes you’re actively redesigning, score low — you’d be automating sand.
Simplicity. Can it be built in a day with the tools you already have? Native integration between two apps you use is a 5. Anything requiring new infrastructure, custom code, or API work you’ve never done scores lower — for the first projects, at least. Simplicity is what makes the first project actually finish.
Multiply it out or just rank the columns; the top few are usually obvious once scored. But two factors override the raw score, and they’re the ones that separate “automating things” from “building an automation practice”:
Blast radius. A first automation should be low-stakes: internal, reversible, reviewed by a human before anything irreversible happens. The first lead routing build routes to a test sheet for a week before it touches the CRM that sales trusts. First projects need permission to fail, and failure teaches; first projects that fail visibly end the program.
Verification. Can you tell, within a week, whether it’s working? The first automation should produce output you can inspect and compare to the manual process. If “is it working?” requires a month of accumulation, you can’t build the team’s trust on it.
The classic profile of a great first automation
Meet the pattern that scores highest, again and again, across every business we’ve worked with: the daily/weekly data shuffle. Some version of “information lands in place A, a human moves it to place B, maybe formats it, and someone gets notified.”
- Form submissions into the CRM or sheet
- Order/invoice emails into a tracking spreadsheet
- Leads from a marketplace/directory into your intake
- A daily/weekly report someone assembles by hand
- Notifications that should go to the right person automatically
These score 4-5 on frequency (daily), decent on pain (everyone hates them), 5 on stability (they’ve existed unchanged for years), and 5 on simplicity (native integrations, buildable in an afternoon). If you recognize your own business in this list, that’s your week-one project.
The classic profile of a terrible first automation
For contrast, the pattern that derails automation programs: the judgment-heavy client-facing exception handler. “When a customer complains, automatically assess and respond” — it’s the loudest pain, it’s emotionally compelling, and it fails on every dimension: judgment varies per case, errors are client-visible, verification is muddy, and the build needs capabilities (tools, guardrails, approval gates) the program hasn’t earned yet. There’s a future where an AI agent drafts complaint responses for review — that future comes after the boring wins built the skills and trust to run it safely.
The sequencing logic
The order matters as much as the picking, because each automation builds assets for the next:
- First project: a data shuffle — teaches triggers, mappings, and the maintenance habit. Wins trust by being visibly, boringly correct.
- Second: a notification/routing flow — adds conditional logic; the team starts saying “could it also…” (that’s the sound of adoption).
- Third: a timer-based sequence — invoice reminders, onboarding — adds schedules and state. This is usually where the first real money lands (cash flow and retention effects).
- Then: the escalation ladder — scoring, lead routing with escalation, anything with a “if nobody acts” branch. Requires the debugging instincts from projects 1-3.
- Last: agents with external reach — the AI-agent layer goes on top of a working automation practice, not before it. Start small, guardrail everything.
Notice what this sequencing is: a curriculum. Nobody teaches it explicitly, but the teams that go from zero to “automation is how we operate” all climbed this ladder, whether or not they drew it first. The teams that stalled tried to skip to rung 5.
The framework applied: a 12-person commercial cleaning company
To show the framework doing real work, here’s the scoring session from a client — a commercial cleaning company, 12 people, contracts with office buildings and a handful of medical facilities. The owner’s instinct, before scoring: “we need to automate our bidding” (quoting new contracts). Everyone’s instinct is to automate the thing with the most money attached.
We listed 10 candidates with the ops manager and the two team leads in the room. The top of the scored list, after an hour:
| Candidate task | Freq | Pain | Stability | Simplicity | Notes |
|---|---|---|---|---|---|
| Nightly janitor check-in reports → client portal | 5 | 4 | 5 | 4 | Currently: supervisor transcribes ~25 texts/night into a client-facing sheet |
| Supply reorder alerts per site | 5 | 3 | 4 | 4 | Staff text photos of empty dispensers; someone orders weekly |
| New-contract bidding packet assembly | 1 | 5 | 3 | 2 | The owner’s pick — scores poorly |
| Weekly staffing schedule → SMS distribution | 4 | 4 | 4 | 3 | |
| Invoice generation from completed-visit logs | 4 | 4 | 5 | 3 |
The scoring changed the room’s mind about where to start. The bidding automation — the loudest pain, the most money per instance — scored 1 on frequency (a few bids a month, each highly judgment-shaped: which supervisor, which crew, what travel margin) and 2 on simplicity. Meanwhile the nightly check-in shuffle scored almost perfectly: 25 times a night, seven nights a week, unchanged for four years, transcribable to a native integration.
First build: the check-in pipeline (text-message reports → parse → client portal sheet → flag anything indicating a problem for the supervisor). One weekend, native integrations, zero new tooling. Second build: the supply reorder alerts. Third: the invoice generation.
Three months later they did automate bidding — partially. The scored sequence built the assets that made it feasible: the visit-logging structure from build one meant bid packets could be assembled from real site history instead of the owner’s memory, and by then the ops manager had three automations of debugging instinct. The owner’s instinct wasn’t wrong about bidding mattering — it was wrong about the order. That’s the whole discipline the framework encodes: instinct ranks by value-per-instance; the framework ranks by value-per-instance times instances, minus build risk. At small-business scale, the multiplication almost always wins.
The objections we hear every time
“Our processes are too messy to automate anything yet.” Then score specifically for stability and pick the exceptions: every business, however messy, has two or three tasks that have run unchanged for years precisely because nobody’s had the attention to redesign them. Messy processes contain stable pockets. Find them — they’re usually the data shuffles.
“We don’t have anyone technical.” The framework’s simplicity dimension exists precisely for this. Scored honestly, the top of a non-technical team’s list is native-integration work — form → sheet → notification — buildable by a careful person in an afternoon with no code. The technical-sounding stuff (custom API work, self-hosting, agents) scores low on simplicity for you and stays low until someone on the team wants to learn it. The framework grows with you.
“What if we automate people out of a job?” In our experience across dozens of small businesses: the hours automation removes are hours nobody wanted to be spending — transcription, chasing, copy-pasting between tabs. The people doing those hours move to the work that needed doing and wasn’t getting done: the supervisor who stopped transcribing check-ins started actually reading them and catching problems the same night. The cleaning company’s ops manager now spends the four hours a month the framework freed on the supplier relationships that were quietly decaying — and that work was always more valuable than the transcription. If your honest fear is a specific person’s role, that’s a management conversation to have openly, not a reason to keep everyone doing robot work.
Your one-hour exercise
- List 10 candidate tasks (ask your team — their invisible tasks are your blind spots)
- Score each 1-5 on frequency, pain, stability, simplicity
- Check blast radius (internal/reversible?) and verifiability (knowable in a week?)
- Pick the top scorer and build it this week — one, not three
- Run it in parallel with the manual process for a week, then cut over
A year from now you’ll have a dozen of these running. But the difference between the businesses that do and the businesses that abandoned their Make account in month two was decided by what got built first — and this framework is how to decide it on purpose.