Talking to customers
Phone, chat, WhatsApp. Answering repeat questions, booking appointments, collecting what is needed for a quote. A person steps in where the case turns unusual.
AI in business
AI for business
The question is not whether AI will change your industry. It is which specific process in your company can be done cheaper and faster today, and which is better left alone.
65 min process auditQuote in writingNo commitment
What AI actually does in a company
Artificial intelligence is good at repetitive work grounded in language and data: reading text, answering questions, pulling information out of documents, scoring enquiries. It is weak wherever accountability for a decision and a feel for the situation matter. Most failed deployments come from confusing the two: someone tries to hand AI the decision instead of handing it the preparation that comes before the decision.
Four areas where this works today
Documents
Invoices, orders, contracts, scans. Reading the content and moving it where someone retypes it today. Usually the fastest return on the list.
Data and analysis
Summaries pulled from several systems, spotting discrepancies, the report someone assembles every Monday. Dull, repetitive, and exactly where AI is reliable.
Content
Product descriptions, language versions, first drafts of offers and emails. It does not replace the author, but it shortens the path from blank page to something worth editing.
Three reasons AI projects fail
We have seen these often enough to name them before anyone signs anything.
Buying a tool instead of solving a problem
A company buys seats for the team and waits for results. After a month three people use it, after a quarter nobody does. The tool alone changes nothing, because no process left anyone's desk. You start from the process, not the tool.
Automating a mess
If a process looks different every time and depends on who happens to be running it, AI will entrench that inconsistency and add speed to it. The way it should run has to be written down first. Sometimes that alone saves more than the deployment would.
No owner on the client side
A model-based system needs correction: the offer changes, new questions appear, something stops fitting. If nobody inside the company watches it, quality drops within six months and everyone concludes AI does not work. One person has to own it, even for an hour a month.
The first 30 days in practice
Not a year-long strategy, but what actually happens between the first conversation and something starting to work.
Week 1 — conversation and map
65 minutes on how the work runs today. Not about technology, but about what takes whose time and how often per week. The output is a list of processes ranked by real cost rather than by which sounds most interesting.
Week 2 — picking one process
We pick one: repetitive, measurable, and genuinely annoying to somebody. You get scope and a price in writing. This is the easiest moment to say no, and plenty of clients decide to wait right here. That is fine.
Weeks 3–4 — the build
We work on your data and your integrations. From you we need access and answers to settling questions, usually a few short exchanges rather than daily meetings.
End of month — first result
For simpler processes something is already running and the numbers are visible: how many cases the system handled alone. For projects integrating with industry systems we are typically still waiting on vendor-side access at this point. That is the most common cause of slippage, and we raise it at the start rather than afterwards.
Four promises not worth believing
The AI market is full of sentences that sound good in a meeting and end badly in delivery. These four we hear most often from companies arriving after a failed project.
“AI will replace half your department”
Small and mid-sized companies do not have spare people to replace. The real effect is a shift: someone stops retyping data and starts calling customers back. If headcount reduction is sold to you as the main benefit, it is worth asking which deployments that rests on.
“Return on investment in 90 days”
Nobody knows your numbers before an audit, so that promise is a guess presented as a fact. Return depends on how many hours actually disappear and what those hours cost, and that can only be calculated once the process is mapped. A serious firm gives a range after analysis, not before.
“Just connect a model to your data”
Connecting is the easy part. The hard part is what happens on an uncertain answer, how the system recognises it does not know, who approves doubtful cases and what happens on an error. Projects fail on those things, not on the integration.
“The system will learn from your data by itself”
Model-based systems do not quietly improve on their own. They improve because somebody reviews the cases where they hesitated and corrects the rules. Without that, quality does not rise, it slowly drifts as your offer changes.
Is my company too small for this
It is the question we hear most, usually from companies that are in fact at a good moment for it. Size matters less than repetition. A three-person company where one person spends six hours a week retyping orders has a better case than a fifty-person one where every process looks different. The threshold is simple arithmetic: how many hours a month a task eats, what an hour costs, and how many months until the build pays for itself. If it comes out beyond about eighteen months, we will say so ourselves. At a dozen events a month there is nothing to discuss, and it is better to hear that from us than to discover it after an invoice.
Where to start
With one process that is repetitive, measurable and annoying. Repetitive, or there is nothing to automate. Measurable, or you cannot prove it paid off. Annoying, because then the team helps instead of defending the old way. Company-wide AI strategy conversations usually end in a deck and nothing else. One working deployment changes the conversation more than any document.
What it costs
We do not quote ranges detached from the process, because the same capability in a five-person and a two-hundred-person company is two different projects. Cost is driven by the number of integrations with your systems, whether documents or images must be read (usually two to three times more), the number of languages, and whether the system only answers or acts on your behalf. The audit ends with a written quote, scope and schedule included, so you can compare it against another offer.
Will AI take my team's jobs
In the companies we work with it has not happened once, and not because that sounds good. The reason is mundane: small and mid-sized companies do not have spare people. Taking two hours of data entry off someone does not end in redundancy, it ends with that person finally calling customers back. If anyone offers you headcount reduction as the main benefit, it is worth asking what they base that on.
Frequently asked questions
Do we need our own IT person?
No. What is needed is someone with access to your systems, or a contact at the firm that supports them. The rest sits with us. Worth knowing though: if your industry software is maintained by an external vendor, their timelines will set the pace of the project, and that is not something we can speed up.
Does our data go to model providers?
It depends on the solution and we settle it at the start. Some processes can run without data leaving your side. Where we use external services you get it in writing: which provider, what data, processed where and on what basis. If your sector imposes constraints, we design for them from the beginning rather than bolting compliance on at the end.
How long before we see a result?
For simpler automation the first numbers arrive two or three weeks after launch, which is how long it takes for a representative volume to pass through. For agents talking to customers, allow a month, because the early weeks also involve tuning behaviour. The financial effect usually shows in the second quarter of use, once periods can be compared.
Does the team need training?
Briefly and concretely, not as a course. The team needs to know what the system handles alone, when a case reaches them, and how to report that something is behaving wrongly. Usually one meeting and a short guide. The opposite, deploying without talking to the team, is the main reason working systems get bypassed.
Where do we start on a limited budget?
With the process that hurts most, even if it is not the largest. A small implementation that works does more for the next decision than a big project that drags on for a quarter. The first process also teaches us your company, so we price the next one more accurately and build it faster.
Can it be extended later?
Yes, and we design for it, but we do not sell it as a promise of a platform that will handle everything. The first implementation has to stand on its own and make sense even if nothing follows. If something does follow, we reuse what is already there: access, integrations and knowledge of your process.
Let us start with one process, not a strategy
65 minutes on what your team does by hand and how often. You leave with processes ranked by what they cost you, and an honest note on which are not worth automating.
Book a consultation