Most AI projects we're asked to build start in the wrong place. Someone watches a demo or sits through a vendor pitch, and arrives at our first call with the solution already picked out: a chatbot, or a copilot for a process nobody has ever written down. Then we ask what actually hurts. The answer is almost never the thing they asked for. It's invoices piling up in a shared inbox. It's leads sitting untouched for two days because routing lives in one person's head.
This post is the sequence we walk those clients through. Nothing about it is original. It works anyway, which is more than we can say for most AI initiatives we see pitched.
Start with a workflow, not a model
The right unit for a first AI project is a workflow: a repeatable process with a clear start, a clear end, and at least one person who hates doing it. Not a department. Not "customer service." A specific, nameable thing, like triaging supplier invoices or routing inbound leads.
Model selection is a detail you settle in week three. We've argued elsewhere that the interesting question has moved from models to the systems around them; the buyer version of that argument is simpler. Claude or GPT-5.5 are both good enough to extract fields from an invoice. Neither will tell you which workflow is bleeding hours.
A good first workflow has four properties: it runs often (daily or weekly, not quarterly), the steps can be written down, a human already checks the output, and an occasional mistake is annoying rather than catastrophic. Invoice triage passes all four. Payroll fails the last one. That last property matters more than people expect, and we'll come back to it.
If nobody at the company can describe the workflow step by step, that's the real first problem, and no model will fix it. You'd be surprised how often the discovery week ends with a process document as the most valuable deliverable.
The 80% heuristic: automate the boring part
The 80/20 split is a working heuristic from our own projects, not a law of nature. Across the workflows we've automated, the boring 80% looks the same: fetch the thing, read it, classify it, extract the fields, route it, draft the response. The hard 20% is where the judgment lives: the angry customer, the invoice that matches no purchase order, the refund request that bends policy, the call someone gets paid to make.
The playbook is to automate the boring part and hand the judgment calls back to a human in a clean review queue. This is also where we earn our keep as an AI automation agency: knowing which parts should be a model and which should be fifty lines of deterministic code. If a rule can be written down, we write it down. "Every invoice above €10,000 needs a second approval" is an if-statement, not a prompt. Models go where the input varies in ways rules can't capture: reading a free-text email, extracting line items from a PDF layout we've never seen, judging whether a lead sounds like a hospital or a hobbyist.
A few examples from real projects, anonymized but with honest ranges.
Invoice triage
A client around the 50-person mark had two people spending a combined 15 to 20 hours a week opening invoices, matching them to orders, keying totals into the accounting system, and chasing mismatches by email. Across the invoice projects we've run since 2023, that manual load has sat between 10 and 25 hours a week depending on volume.
The automated version: invoices arrive by email or scan, OCR plus a vision-capable model extracts the fields, deterministic code matches against purchase orders, and anything above a threshold or below a confidence score lands in a review queue. The humans now spend 1 to 3 hours a week on exceptions. The model never touches a payment; it prepares, a person approves.
Lead routing
Inbound leads arrived through a website form, a generic inbox, partner referrals, and the occasional trade-show spreadsheet. Routing depended on one senior person reading everything and forwarding it, which meant leads waited anywhere from 4 hours to 2 days when that person was busy or on holiday.
Now a model reads each inquiry, classifies it by product area and urgency, enriches it with public company data, assigns it to the right person, and attaches a draft first reply. Routing happens in minutes. The senior person reads only what the system flags as unusual. The part nobody anticipated: the draft replies got adopted faster than the routing, because writing the first response was the step salespeople actually dreaded.
Report drafting follows the same pattern. A monthly operations report used to take one person half a day to a full day: pull numbers from three systems, paste them into a deck, reconcile the discrepancies, and write the "what changed and why" narrative. In the reporting workflows we've automated, the manual cost has landed between 4 and 8 hours per report. The automated version pulls the numbers with plain integrations and lets a model write the first draft of the narrative; the human edits for 30 to 60 minutes. The honest limit: the model is good at "revenue dipped in week two because shipment volume fell" prose, but it has no idea which of the seventeen changes actually matters to the CEO. That judgment stays with the human, which is why we call this report drafting, not report automation.
What to measure
Measure before and after. Skip the before, and you'll never prove the after.
Hours saved is the one that pays for the project. We insist on a baseline: someone shadows the workflow for a week and logs real time, not estimates. In our baseline weeks, people systematically undercount the tasks they do on autopilot, sometimes by half.
Error rate is the one that keeps you honest. Sample the output weekly and have a human grade it. This is where a fixed test set earns its place: real inputs with known-correct outputs, re-run against the workflow every time we change a prompt or swap a model. Without one, every change is a guess dressed up as progress.
Cycle time, from submission to done, is the one the rest of the company feels. Invoices that sat for five days now clear in one. Leads that waited overnight get answered before lunch.
Budget for running costs too, because they're real. Tokens are cheap per call and add up at volume. Retrieval, where the model searches your documents before answering, adds a search round-trip and a longer prompt to every request: latency goes up, token cost goes up, accuracy gets harder to reason about, and you now maintain a second system. None of this is a reason not to build. It's a reason to measure cost per processed item from day one instead of discovering it in month four.
Where first AI projects die
The failure modes repeat across the projects we've been called in to rescue. In ascending order of money burned:
Chatbot-first
The chatbot is the highest-variance, hardest-to-evaluate interface you can pick, and it puts the model directly in front of your customers on day one. A wrong answer goes straight to the customer; there is no review queue or confidence threshold to catch it. Our rule: don't start with a chatbot. Start where a human already checks the output, earn trust in the system's accuracy, and let customer-facing use cases come later if the numbers justify them.
Platform-first
The enterprise AI platform pitch arrives early: one contract, one vendor, every use case solved. What it actually delivers, in the platform rollouts we've watched clients sit through, is a six-month implementation before your first workflow runs, and a process you end up bending to fit the tool's assumptions. A first workflow needs an API key, a few hundred lines of glue code, an orchestrator like n8n or Make, and a database. Platforms have their place, roughly at the point where you have five working automations and a governance problem. Not before.
The third failure mode is quieter: the pilot that never ships, because nobody defined what shipping means. We set the criteria in week one: if the error rate is below an agreed number and hours saved clear an agreed bar by week eight, it goes to production. Otherwise we stop, and the client has lost weeks, not quarters. A pilot without kill criteria isn't caution. It's how AI budgets die while everyone stays busy.
A realistic 8-week rollout
Here's what this looks like with us, end to end:
- Weeks 1–2: discovery. We shadow the workflow, log the baseline hours and error rate, and agree on the slice to automate plus the ship-or-kill criteria.
- Weeks 3–6: the build. This is our fixed-scope sprint, about four weeks, with a working demo every Friday to the people who actually do the work, not just the sponsor.
- Week 7: parallel run. Old process and new system side by side, every discrepancy investigated. This week is non-negotiable; it's where trust gets built.
- Week 8: handover. You get the evaluation setup, a runbook, access to every prompt and flow, and a training session. If you want your own team running it long-term, we do build-operate-transfer; if you'd rather we operate it, we do that too.
The team shape matters here. Project leadership sits in Germany, the senior engineering team works from Pakistan, and delivery runs in English or German, so a Mittelstand COO and a senior engineer end up in the same weekly call with no telephone game in between. You can see what this pattern produces in our case studies.
One more thing, because it's the trade-off most agencies won't put in writing: sometimes AI is the wrong tool. If your workflow has zero tolerance for variance (payroll or anything a regulator reads), a probabilistic model is the wrong instrument, and the right answer is plain automation or better software. Over the past two years, roughly a third of the "AI projects" we've been asked to quote ended with us recommending no AI at all. We consider those some of our best AI automation engagements, because the client got the outcome without the science project.
The companies getting real value from AI right now aren't the ones with the fanciest model or the biggest platform contract. They're the ones that picked one painful workflow, automated the boring part, measured honestly, and finished. If you want that first discovery week run against your own operations, talk to us.
Frequently asked questions
How much does a first AI automation project cost?
With us, discovery plus a fixed-scope first build typically lands in the low five figures. Our rate band is $25–49 per hour, the build phase runs about four weeks, and scope is fixed before we start, so the number you approve is the number you pay. Running costs (API tokens, hosting, monitoring) are separate and usually a few hundred dollars a month at single-workflow volume.
Do we need clean, organized data before starting?
No. You need access to whatever systems the workflow touches and one person who can explain the steps. The discovery week exists precisely to find out what shape your data is in, and most workflows run fine on imperfect data because a human still reviews the output.
What happens when the AI makes a mistake?
The system is designed around mistakes: low-confidence or high-value items route to a human review queue, and a person approves anything irreversible like payments. Error rate is a number we measure weekly against a fixed test set, so accuracy problems show up in a dashboard before they show up in your operations.
Should we build this in-house or hire an agency?
If you have engineers with production LLM experience and spare capacity, in-house can work. Most 50-person companies have neither, which is why our engagements are built to hand over: you get the code, the evaluation setup, and a runbook, and we offer build-operate-transfer if you want your own team running it after launch.