The question almost always arrives the same way: "can this be done with AI?".
And the answer is almost always yes. But can is not the same as should. A good part of our work in the first meetings consists of separating one from the other, because an AI project that shouldn't have existed doesn't fail on day one: it fails eight months in, once the budget is already spent.
The filter we apply first
Before talking about models, we look at three things about the process:
Is it repetitive, and does it have volume? Automating something that happens twice a month almost never pays off. Not because of the cost of building it, but the cost of maintaining it: every system needs updates, monitoring, and fixing when something around it changes. Without volume, that upkeep weighs more than the savings.
Are the rules written down somewhere, or do they live in someone's head? If the process is already documented step by step and has no ambiguity, you often don't need AI: you need classic automation, which is cheaper, faster, more predictable, and doesn't hallucinate. AI wins when something needs to be interpreted: free text, a document with a variable format, a question written by a person.
How much does a wrong answer cost? This is the one that shapes the design the most. Misclassifying a sales email isn't the same as sending a patient the wrong information. The more expensive the error, the more human oversight the loop needs.
The "it saves time" trap
When someone says "this would save us a ton of time," the follow-up question is: whose time, and time to do what?
If a person spends 20 minutes a day on the process, automating it doesn't give them back 20 useful minutes. It gives them 20 fragmented minutes throughout the day, which will probably fill themselves up. The real savings show up when one of two things happens:
- The volume is such that there's a full-time person dedicated to it.
- The process is a bottleneck: it doesn't matter how much time it consumes, but that everything else waits while it isn't done.
The second case is the most interesting and the easiest to overlook. A process that takes two minutes but can only be done by one person, and that stalls the whole operation whenever that person is busy with something else, is worth automating more than one that takes hours but blocks nobody.
What we learned doing this
In a healthcare project, the workflow was: every time a patient made a query, the protocol required sending specific information. Repetitive, with volume, and with a high cost of error.
What made the difference wasn't the model. It was understanding that the problem wasn't writing the message, it was deciding which one applied. That distinction changes the whole design: if the heavy lifting is the decision, the automation has to focus there and leave the sending as something trivial. Get that wrong, and you build a very nice text generator that doesn't solve the bottleneck.
That's why we insist so much on understanding the process before proposing technology. It's slower at first and saves months later.
When we say no
We're pretty upfront about this, and sometimes it's uncomfortable:
- When there's no data. A model that learns from your operation needs history. If nothing was ever recorded, the first project isn't AI: it's starting to record.
- When the process is broken. Automating a bad process gives you a bad process, faster. Fix it first, automate it second.
- When the right answer is an
if. If there are five fixed rules and they don't change, five fixed rules is the solution. Putting a model there adds cost, latency, and uncertainty in exchange for nothing. - When nobody is going to own it. Every AI system degrades: the data changes, the business changes, the model provider changes. If nobody checks in on it every so often, it will fail silently.
The order we recommend
- Understand the process end to end, with the people who do it.
- Measure it. How much volume, how long it takes, where it gets stuck, what happens when it fails.
- Ask whether it actually needs AI or classic automation is enough.
- If it needs AI, start with the most expensive part of the process, not the flashiest one.
- Keep a person in the loop until the numbers say it's no longer needed.
It's not glamorous, but it's what makes a project still work a year later.
In our AI case studies we show projects where this was actually applied. If you have a process in mind and don't know if it qualifies, get in touch and we'll take a look together.
