Start with the work, not the tool
Almost every business has tried an AI tool by now. Far fewer have something running that saves real time every week. In 2025, a preliminary MIT study of more than 300 public AI initiatives found that most of the organizations it looked at saw no measurable return on the profit and loss statement from their generative AI pilots. The authors put the gap down to how the tools were used, not to the AI itself: workflows that broke easily, and tools that didn't fit how people actually work.
That matches what we see. The projects that stall usually start with a question like "how do we use AI?" The ones that work start with a sentence like "Maria spends every Monday keying 200 invoices into accounting." One is a technology looking for a problem. The other is a problem with a cost you can measure.
Pick one workflow
Your first project should be one workflow, not a strategy. The best candidates share six traits:
- It happens often. Daily or weekly, not once a quarter. Volume is what turns small savings into real hours.
- It hurts. People complain about it, it causes delays, or it's where most of the mistakes come from.
- The rules can be written down. If two experienced people would make the same call, a system can be checked against that call. If every case is a judgment, start somewhere else.
- The information already exists. The emails, PDFs, forms or records it depends on are already there, even if they're messy.
- A mistake can be caught. Early on, someone should be able to spot an error before it reaches a customer or moves money.
- Someone owns it. One person who does the work today, and who will tell you honestly whether the new way is better.
In practice, good first projects look like this: invoices and orders that sit in an inbox waiting to be keyed in (automation); a team that spends hours searching shared drives and email for answers (AI assistants); quotes built by hand from a price list in a spreadsheet (custom apps); or a coverage check that compares a policy with what a lender requires, line by line (insurance).
Measure it before you build anything
You can't show a saving you never measured. Before anything is built, take a week to write down how the work runs today. You don't need a study: a sample of 20 to 50 real items, timed by the person who does them, is usually enough.
- Volume: how many items come in a week, and how that swings in a busy month.
- Time per item: from the moment it arrives to the moment it's done, including the chasing.
- Turnaround: how long an item waits before anyone touches it.
- Rework: how often something has to be corrected, and who catches it.
- Cost of a mistake: what happens when one slips through: a refund, a missed shortfall, a lost customer, a finding in an audit.
Those same five numbers become the test for whatever gets built. If the new way doesn't move at least one of them clearly, it isn't finished, however impressive the demo looked.
Keep a person approving what matters
The fastest way to lose a team's trust in AI is to let it act on its own before it has earned that. We build every system so the business chooses what runs by itself. Anything that spends money, or is out of the ordinary, waits for a person on your team to approve it. Every step is recorded: what came in, what was checked, who approved it and what was sent.
A sensible path is to start in suggest mode. The system reads the invoice, drafts the entry and flags anything unusual; a person checks and approves. Once the numbers show it's reliable on routine items, those can run on their own, while exceptions still go to a person. Trust is earned item by item, not switched on in a meeting.
Why discovery comes first
Most of what decides whether an AI project works is learned before any code is written: what the rules really are, what the messy cases look like, which systems hold the data and whether they let anything in. Skip that, and you find out halfway through the build.
That's why we start every engagement with discovery, and why ours is free. It begins with a 40-minute call. If there's a fit, we spend one to three weeks with the people who do the work: we watch it, collect real files (including the messy ones), write down the rules and test what's possible on your own documents. It ends with a written recommendation: what we would build, why, and what it costs. If the honest answer is that off-the-shelf software would do the job, or that the workflow isn't ready, the recommendation says so.
What happens after the first project
- The first release runs in suggest mode, so your team checks everything it does.
- Results are measured against the baseline you took before the build, on your own numbers.
- Routine items move to running on their own where the record shows they can, with people still approving exceptions.
- The next workflow is chosen using what the first one taught you about your data, your systems and your team.
Each project after the first is cheaper and faster, because the connections to your systems, the permissions and the habits of checking are already in place. That's how a business gets from one tool that works to AI that's part of how it runs.
If you have a workflow in mind, or a list of five and no idea which comes first, book a free discovery call (opens in a new tab). For a way to judge the candidates yourself, our checklist for deciding whether an AI project is worth building is a good place to start.