What to automate first: scoring a business workflow before we touch it

The first call usually opens with the impressive idea: an AI assistant on the website, answering customers at midnight. Halfway through, someone mentions the intake form — the one re-keyed into the CRM every morning, where a mistyped phone number is a lead nobody calls back. We start with the form.

The business processes to automate first are the ones with the highest hours-times-error cost, the lowest implementation friction, and a clear owner. In the businesses we see, that is almost always intake — the moment a lead, an order, an application, or a document arrives. Score the candidates, pick one, baseline it, ship it in weeks, then take the next. Prestige projects come after the boring ones pay for them.

Here is the scoring, the rule behind it, and the first 90 days.

Why we start boring

We start boring because the boring workflows are where the hours and the errors live, and because the first project sets the terms for every project after it. A measurable win on intake pays for the next build and teaches the team how automation behaves in production. A prestige project rarely does either.

The prestige trap is the most common way we see business process automation go wrong. The impressive idea wins because it demos well and fits a budget line that says AI. Then it meets reality: it faces customers, so every mistake is public; it needs knowledge nobody has written down; it replaces a few hours a week at most; and its success criterion is some version of "people seem to like it." When it underwhelms, the room concludes that automation doesn't work here.

That conclusion is the real cost. The price of a wrong first project isn't its invoice. It's the second project that never gets approved — and the intake form that keeps eating someone's mornings for another year.

Boring projects compound instead. Clean records at the start make every later step cheaper: reports built from data nobody had to fix, follow-ups triggered by real fields instead of memory, and eventually a website assistant with something true to answer from. The boring project is often what makes the impressive one possible.

The intake-first rule

The intake-first rule: when workflows compete for the first slot, automate the point where work arrives — the lead, the order, the application, the document — before anything downstream of it. Every later step inherits the speed and accuracy of that first capture, so fixes at the door compound, and fixes further down mostly treat symptoms.

Intake tops the list so often because it has everything a first project needs. Every item passes through it, so the hours are real. Its mistakes travel: a wrong address becomes a wrong quote, then a wasted trip, each costlier than the typo that started it. Speed counts most at arrival, because the inquiry answered first is often the one that becomes the job. And the build is usually tractable: known fields, one destination.

Field note: A residential roofing company had leads arriving by phone, web form, and marketplaces — and sitting unanswered through storm season, while every crew was on a roof. Slow response meant lost jobs. We automated the arrival: one queue for every lead, automatic answers to routine questions, structured collection of the address, photos, and roof type, and estimates drafted for the owner's approval. Response time went from "when someone got to it" to minutes, and quotes now go out the same day.

The same rule holds when what arrives is paperwork. A professional-services firm in Ontario had staff re-keying client-submitted forms, scans, and email attachments, with errors surfacing downstream. The intake assistant we built extracts and validates the fields on arrival and flags anything ambiguous for a person. Staff review instead of transcribe, turnaround went from days to same-day, and errors get caught at the door. The pipeline — extract, validate, flag, review — has its own note: turning forms, PDFs, and voicemail into structured data.

Intake is also where personal data enters the building, so the privacy design happens here, before the build: where data is processed, what is masked before any model sees it, and how long anything is kept. For the Ontario firm, processing stays in a Canadian cloud region, identifiers are masked inside that environment before any external model call, those calls run under zero-data-retention terms, and every extraction is logged against its source document. For the roofing company, contact data is minimized, text follow-ups are consent-tracked, and call recordings are transcribed, then discarded on schedule.

The triage score

The triage score ranks candidate workflows by what they cost you today against how hard they are to fix: hours per week times the cost of a mistake, raised for risk, divided by implementation friction. It's how we prioritize automation without a debate — one afternoon with the people who do the work turns opinions into a ranked list.

Triage score = (hours per week × cost of a mistake) × (1 + risk) ÷ friction

• Hours per week — the human time the workflow takes across everyone who touches it, rework included. Use a normal week, not the worst one.
• Cost of a mistake — what one error costs directly, from 1 (a nuisance fixed in a minute) to 5 (a lost job, a lost client, or work redone for free).
• Risk — who sees the mistake: 0 if it stays internal, 0.5 if a customer sees it, 1 if it carries a compliance or legal consequence.
• Friction — how hard the build is: how many systems, how clean the data, how clearly the rules are written. Score it from 1 (one system, clean data, written rules) to 5 (five systems, messy data, rules that live in one person's head).

Two choices in the formula are deliberate. Risk raises the score instead of disqualifying the workflow: a mistake a customer or a regulator sees costs more than its direct price, so preventing it is worth more — and risk tells you where the human checkpoint goes. Friction divides because the first project's job is to ship. A workflow that needs six months of data cleanup is a worse start than a slightly less valuable one that can be live in four weeks.

Here is the score run on a typical service business. Illustrative example: the numbers are invented to show the mechanics. This is not client data.

Intake wins on volume and error cost. The website assistant — the idea that opened the call — lands near the bottom: it saves a few hours, its mistakes are public, and it needs a knowledge base nobody has written yet. Appointment reminders score respectably and still shouldn't be built, because a cheap tool already does them. And nothing in the score asks whether the fix involves AI. The triage picks the workflow; the design decides which steps need a model.

Rule of thumb: If two candidates land close together, pick the one with lower friction and a named owner. The first project's job is to ship, get measured, and earn the second.

Three workflows that usually win

Three workflows top the list in most of the service businesses we see: intake, the recurring report, and follow-ups. They share a profile — real weekly hours, mistakes that cost money, rules someone can write down, few systems involved — which is exactly what the triage score rewards. None of them demos well.

Intake. Covered above, and the purest back-office automation there is: forms, orders, applications, and supplier documents with known fields and one destination. If someone re-types information from one screen into another, that workflow belongs on the list.

The recurring report. Any report assembled by hand on a schedule is a strong candidate. The hours come back every cycle, the numbers are the numbers, and the format rarely changes.

Field note: A digital agency assembled client reports by hand every month from ad platforms, search data, and analytics — senior time spent on copy-paste, delivered too late to act on. We built a pipeline that consolidates every platform per client; a model drafts a weekly brief from the numbers, and the account lead reviews it before it goes out. Reporting went from a monthly scramble to a weekly rhythm, and account leads spend the saved time on decisions.

The pattern holds when the report is prose. For a children's-services nonprofit, grant reports now begin as drafts built from the organization's own program documents and templates — deliberately no case records or family data — with staff in the loop. Drafts start at eighty percent instead of zero, and program leads get hours back.

Follow-ups that never forget. Nobody times follow-up, because its hours hide in memory: who to call, whether they replied, when to try again. A mistake here is a lost job. For the roofing company, follow-up continues until the job is scheduled or closed, and no lead falls through the cracks. Our default: anything that commits to something new — a price, a date — goes to a person first.

What not to automate (yet)

Don't automate a process that isn't stable, a process that shouldn't exist, a one-person task under two hours a week, or anything a $30-a-month tool already does. Each of these fails the triage for a reason, and the honest recommendation — including from us — is to fix it, delete it, leave it alone, or buy it.

Unstable processes. If two people would handle the same case differently, automation doesn't settle the argument; it picks one version and runs it at speed. Agree on the process on paper first. That conversation is often cheaper and more useful than any build.

Processes that should be deleted. Before scoring anything, ask who uses the output. The report nobody opens, the approval step that outlived its reason, the spreadsheet that exists to copy another spreadsheet — automating these makes waste faster and harder to see.

Small tasks with one owner. Under two hours a week, done well by the person with the judgment: leave it there. Automation pays back on volume and error cost, and this has neither.

Problems a cheap tool already solves. Scheduling, reminders, e-signatures, a basic form feeding a CRM. Custom work there is money spent on pride.

When not to do this: If your top-scoring workflow turns out to be a solved problem, don't hire anyone to build it — including us. Buy the tool, spend an afternoon configuring it, and move to the next line on the list.

The 90-day arc

A first automation engagement fits in about 90 days: two weeks to observe and baseline, four weeks to put the first workflow live with a human in the loop, four weeks for the second workflow, and three weeks to measure and hand over. Each workflow ships in weeks, not quarters.

Weeks 1–2: observe and baseline. We watch the work happen: time the workflow, count the errors, note where things wait. Then we write the success criterion — the number that will say it worked — before any code exists. Without a baseline, automation ROI is a guess made after the fact; what to capture is in how to measure an AI project before and after.

Weeks 3–6: the first workflow, live, with a human in the loop. It runs on real work, not a demo, with a person reviewing outputs before they matter. It's built with retries, idempotency, an audit trail, and a place for humans from day one — the four properties of automations that don't break — because the first workflow is the one everyone will judge the next by.

Weeks 7–10: the second workflow. The next line on the triage list, usually follow-ups or the recurring report. It tends to move faster, because the connections, queues, and review screen already exist. Meanwhile, what reviewers correct on the first workflow shows where its rules need work.

Weeks 11–13: measure and hand over. We measure against the baseline, then document every workflow: what triggers it, which steps are rules and which are model calls, what a person reviews, how to change it, and what to do when it stops. The business should be able to run it without us.

That is the shape of our business automation engagements, and it's a reasonable template for an in-house team too.

Run it yourself

You can run the triage this week with one meeting and a spreadsheet: list eight workflows, score each on hours, error cost, risk, and friction, pick the top one, and write its success criterion before anyone builds. The automation triage worksheet below walks through the same steps on paper, with room for eight workflows and a 90-day plan.

1. List eight workflows. Ask the people who do the work, not only the people who manage it: where do the hours go, where do mistakes happen, what gets typed twice? Put the impressive idea on the list too. Let it compete.
2. Cross out before you score. Strike anything unstable, anything nobody uses, anything under two hours a week that one person handles well, and anything a cheap tool already does.
3. Score what's left. Hours per week, cost of a mistake from 1 to 5, risk at 0, 0.5, or 1, and friction from 1 to 5. Rough numbers are fine; you're ranking, not budgeting.
4. Pick the top one and name its owner — the person who will review the exceptions and notice when it drifts. If nobody will, take the next one down.
5. Write the success criterion. One sentence with a number and a date. For example: every new inquiry gets a first response within an hour during business hours, by the end of week six.
6. Baseline it for two weeks before anyone builds, so the result has something real to beat.

None of this cancels the impressive project. It schedules it — after the boring one has paid for it, and after the business has learned, on a workflow it understands, what running automation in production actually takes.