When we scope an automation project, the first thing we build is never the part that makes a good demo. It's the step someone on the team does forty times a day and hates. Sort inbound emails into categories. Copy data from a PDF into a spreadsheet. Rewrite the same three paragraphs with slightly different names. That's where we start, and it's almost never where the client expects us to start. They usually want to lead with the part that looks like AI — the agent that drafts the whole proposal, the model that reads a contract and flags risk. We build that too, eventually. But last.
The wrong order: start with the impressive part
The common mistake is sequencing by wow-factor instead of by friction. A founder or ops lead has one shot at internal buy-in, so they pick the automation that will look best in a demo to the exec team — an agent that handles customer replies end to end, or a system that generates full reports from raw data. It's a reasonable instinct. Impressive demos get budget approved for phase two.
The problem is that the impressive step is usually the least repetitive and the most exception-laden part of the workflow. End-to-end customer reply handling touches edge cases, tone, and judgment calls that take months to get right. Three weeks in, the team is still fighting hallucinated details and inconsistent formatting, nobody on the ground is using it, and the person who championed the project is now explaining to their boss why the "AI initiative" hasn't shipped anything. The flashy step burns the goodwill needed to fund the boring steps that would have actually worked.
The better approach: automate what people already hate doing
We rank candidate steps by two things: how often they happen, and how little judgment they require. High frequency plus low judgment is the sweet spot — it's where automation produces immediate, measurable relief, and where a model is least likely to embarrass anyone. On AutoArchive Mail, that meant starting with attachment extraction and filing, not the smart-reply feature the client originally asked for. Nobody's job depended on nuanced judgment in file naming; everyone's day got a little worse every time they did it manually. We shipped that in the first two weeks, and it worked reliably from day one, because there was almost nothing to get wrong.
The same logic drove Email Triage: category tagging and priority sorting came before anything resembling autonomous response drafting. Triage is a classification problem with a small, stable label set. It's the kind of task where a well-tuned Claude prompt with a handful of examples gets you to 95% accuracy fast, and where a wrong answer costs someone ten seconds of re-filing rather than a wrong answer sent to a customer. That reliability is what earns the next conversation. Once triage is running quietly in the background and nobody's complaining, you've bought the credibility to tackle something harder — like Ghost Writer's draft generation, which we only introduced after the lower-stakes steps had already built trust in the system.
The pattern holds across CV Matcher and BrightPath too: we always automate the sorting, tagging, or extraction layer before the generation or decision layer. Sorting has objectively checkable outputs. Generation and decisions don't. Start where you can measure correctness, not where you can't.
Where this sequencing breaks down
This isn't a universal law. Sometimes the highest-friction step is also the highest-judgment one, and there's no easy low-risk entry point — a small team doing bespoke client work, for instance, where every task genuinely requires human discretion. Forcing a "start boring" sequence there just delays the thing that actually matters. And if the repetitive task is already tolerable — five minutes a week, not five hours a day — automating it first wastes the political capital you're trying to build, because nobody notices the improvement. The sequencing rule is about maximizing visible relief per unit of engineering risk, not about always picking the most tedious task in the abstract. If the boring step is trivial and the judgment step is what's actually costing the business money, lead with the one that moves the number people care about.
What to do this week
Pick one workflow your team runs constantly. List every step, then mark each one on two axes: how often it happens, and how much judgment it takes. Automate the highest-frequency, lowest-judgment step first — even if it feels too small to justify a project. Ship it, measure the time saved, and use that number to justify the next, harder step. If you want a second opinion on where that first cut should be, start a project with us and we'll help you map the sequence before you write a line of code.