Most conversations about AI in a company end with a list of ideas that never make it past the slide deck. Here’s how we pick the first process to automate, what we never hand to a language model, and how we measure whether an implementation is even worth it.
Before you pick a process, ask the right question
“Where could we use AI” usually leads nowhere, because it fits almost anything. The question that actually leads to a decision is different: which process today has a person reading, classifying, or summarizing a large volume of unstructured information, where a mistake on any single case doesn’t cost the company a fortune. That framing rules out most of the ideas we hear at the start of a conversation with a client, which is a good thing, because it means fewer dead ends.
Good first candidates
Documents
Invoices, contracts, applications, forms — anything a person currently opens, reads, and re-types into a system. A language model handles data extraction from a document well, even when the format shifts between vendors or customers. This is one of the safest places to start, because the output is easy to check against what a person would produce, and easy to roll back if something goes wrong.
Classification
Routing a ticket to a category, priority, or department; sorting incoming messages; identifying a document type before it moves further down the process. Classification has a clear success criterion — the label is either right or it isn’t — so it’s easy to measure and easy to notice when the model starts getting it wrong more often than usual.
Customer questions grounded in company data
An assistant that answers customer or employee questions using a company’s actual documentation, pricing, or order history — not the model’s general knowledge — is a completely different risk category than plugging in a generic chatbot. The answer is anchored to specific data, which makes it much easier to check for accuracy and to limit what the model can say in the first place.
Proposals with human escalation
AI can draft a reply, a quote, a recommendation, or a plan, as long as a person makes and signs off on the final call, especially where a customer’s money or the relationship with them is on the line. The model cuts down preparation time; the person owns the outcome. This pattern works well precisely because it doesn’t try to replace the decision, only to speed it up.
What we never hand to a language model
We hold to one rule across every implementation we run: AI proposes, code decides. Anything that computes an amount, a tax, a contribution, a balance, or any figure someone relies on financially stays with deterministic code, not the language model. The same rule applies to decisions that can’t be undone cheaply — an automatic rejection, an automatic contract termination, an automatic account lock. A language model is, by nature, sometimes uncertain and can get things wrong in ways that are hard to predict — not because it’s bad, but because that’s how it works. Financial calculations and critical decisions need the opposite: repeatability and a step-by-step audit trail. That’s why in Qkwit, our AI-powered accounting product for sole proprietors, Claude reads documents and extracts the data, but a deterministic engine calculates the tax and the social security contribution, not the model. The same split shows up across our other products too — it isn’t an exception carved out for one implementation, it’s how we design AI systems in general.
How to measure whether it’s working
An implementation without metrics is really just an opinion, not a business decision. Three numbers are enough to start.
Precision
The share of results that come out correct without a human correction. Measure it on a sample of real, unfiltered cases, including the messy, unusual documents someone would have quietly excluded from a demo.
Time saved
Not “how long one query to the model takes,” but how long the task took before and how long it takes now, including the time a person still spends checking the result. That second part is often left out, and it can eat up most of the savings.
Cost per document or ticket
The cost of the model query, multiplied by volume, plus the cost of the human time still supervising the process. Only this number, set against what the process cost before automation, tells you whether the implementation is actually worth it — not whether it “works” or “doesn’t work.”
Our way of working, in four steps
1. Process audit
Before we write a line of code, we look at the process itself: where the input data comes from, what today’s decision path looks like, where the exceptions live, and who currently owns the mistakes. This step also shows whether the process is even a good candidate for a first AI implementation, or whether it’s better to start somewhere else.
2. Prototype on real data
We build the prototype on actual, unfiltered examples from the company, not a sample curated to make the demo look good. This is the stage where most of the real problems surface: unusual formats, missing fields, edge cases that wouldn’t exist in an idealized version of the process.
3. Production with monitoring
Only at this point does the process go into daily use, with quality monitoring, a clear escalation path to a person, and a cost ceiling that keeps the budget from creeping up unnoticed as volume grows.
4. Ongoing operation
AI in production needs continuous attention: input data changes, the model gets updated by the provider, new edge cases show up. An implementation meant to work as well a year from now as it did in week one needs someone watching it, not just someone who launched it.
The traps we see most often
A demo that was never meant to become production. It looks great on stage because it runs on one prepared example, and nobody checked what happens on the thousandth, unusual document.
Input data quality. A language model won’t fix messy source data — at best it will hide the mess, which is worse than leaving it visible, because the error surfaces later and is harder to trace back.
Lock-in to a single vendor with no fallback. An implementation built so that switching model providers or moving the data requires a rewrite from scratch is a risk in itself, regardless of how well it performs today.
Prompt-only solutions. A well-written prompt on its own, without a validation layer, monitoring, and a clear split between what AI proposes and what code decides, is a demo pretending to be a product. We’ve seen this repeatedly: the gap between a pilot and an implementation that actually holds up rarely comes from the model — it comes from what does or doesn’t get built around it.
What this means for your company
If you’re wondering where to start, a good first process is one that bores someone today, repeats often, and doesn’t involve computing money or making an irreversible call. Measure it on a small sample first — precision, time, and cost — before committing to a full rollout. That’s a far cheaper way to find out whether a process is even a good fit for automation than building a full production system from day one.
FAQ
Which process should a company automate with AI first? One built on reading, classifying, or answering questions from company data — repeatable, and where a single mistake doesn’t cost much. Financial calculations and irreversible decisions stay with code.
Can AI calculate taxes or approve payments on its own? Not in our implementations. AI reads, classifies, and proposes; deterministic code handles anything involving money — exactly as in Qkwit, where Claude reads the documents and the engine calculates the tax and the social security contribution.
How do you measure whether an AI implementation is worth it? With three numbers: precision without a human correction, real time saved (including verification time), and cost per document or ticket at scale, compared against the pre-automation cost.
What’s the difference between an AI prototype and a production implementation? A prototype gets tested on curated examples. A production implementation has to handle real, unusual cases every day, with quality monitoring and a cost ceiling.
What are the most common mistakes when implementing AI in a company? Treating a demo as a finished product, ignoring input data quality, locking into a single vendor with no fallback plan, and relying on prompts alone without a validation and monitoring layer.
Want to check which process at your company is a good place to start?
If you’re wondering where to start an AI implementation that will actually make it to production, get in touch. We’re happy to walk through a specific process with you, no strings attached.