A bad chatbot costs more than none, because it spends the customer’s patience before they reach a person. We build bots grounded in your own documentation that admit when they don’t know and hand the conversation over cleanly.
Most people have already met the bot that asks the same question three times and finally offers a phone number. That bot doesn’t save you support work — it spends the customer’s patience before they reach a person, and your team picks up a caller who is already annoyed. The saving is an illusion, because the wrong thing was measured: conversations answered rather than problems solved.
Our starting point is the opposite. The bot has to know what it doesn’t know. Where confidence is low, or the question touches money, a contract or health data, the conversation goes to a person along with everything said so far — not back to the beginning. A good bot is judged on how many problems it closes, and on how cleanly it gives up when it can’t.
Choosing the model is the smallest part of the work. Most of the time goes on making the bot answer from your data, know its limits, and reach the places your customers already are.
The bot answers from your documentation, your FAQs and your systems rather than from the model’s general knowledge. Every answer carries a reference to its source, so the user can check it and you can correct it.
Confidence scoring and explicit rules about when the bot gives up. The agent receives the conversation with its full context — the customer never has to tell their story from the start again.
Order status, an invoice, a booking or customer data from your CRM and ERP. A bot that cannot see your data can only answer general questions — and those are the ones the customer could already answer without it.
Web chat, your mobile app, WhatsApp, Telegram, Messenger, and Slack or Microsoft Teams for internal use. The conversation’s context follows the user between channels.
Estonian is a small language and models handle it unevenly. We test it separately rather than assuming it comes along with English — and we say honestly when the result isn’t good enough.
The conversations that went wrong are the most valuable data you have. We review where the bot was wrong or gave up and fix it — this is continuing work rather than a one-off project.
The model is a replaceable part, not the architecture. We build so the provider can be swapped without rebuilding everything — this field moves fast, and today’s best model won’t be the same one in a year.
The number of conversations answered tells you nothing — a bot that answers everyone wrongly scores brilliantly on it. These four are what actually matter.
How many conversations end with the customer’s problem solved — not merely with the conversation ending.
Giving up is not a failure. The failure is the customer having to explain everything again to a person.
A wrong answer delivered confidently is the worst possible outcome — worse than no answer at all.
The two places where chatbots produce the most unpleasant surprises.
We start from your existing conversations. Support tickets, emails and chat logs show what is actually asked — and it almost always turns out that a small set of questions covers most of the volume. The bot is built around those rather than around your entire documentation.
Then we agree the boundaries: what the bot may say, what it may not, and when it hands over. Money, contracts, health data and complaints usually go straight to a person. A narrow bot that does one thing well beats a broad one that does everything badly — and the first can actually be tested.
You get the first version in two weeks, and at first it runs against your own staff rather than your customers. It goes public only once the answer quality has been measured. After launch the work continues: we review the conversations that went wrong and fix them. A chatbot is not a project with an end.
If most of the questions would be solved by better search or one decent FAQ page, we’ll recommend that. It’s cheaper and it works better.
Every answer cites a source in your content. That shows where the bot got it, and a wrong answer is fixed at the source rather than by guesswork.
The boundaries are agreed before anything is built. A bot that cannot say “I don’t know, let me pass you on” does more harm than good.
We don’t assume Estonian comes along with English. Quality is measured in both languages, and we tell you the result plainly.
The architecture doesn’t depend on one provider. If the price rises or a better model appears, it can be swapped without rebuilding everything.
We agree what may be sent to a model at all, and can host the whole thing inside the EU. We are in Tallinn, in the same legal framework.
Any system can be wrong. We reduce the risk by grounding answers in your own documentation with a source citation, routing low-confidence cases to a person, and measuring quality continuously with evaluation suites.
A working bot on your documentation normally takes three to five weeks, including integration with your existing support desk. Most of that time goes on tidying the content rather than on the model.
No, and we don’t sell it that way. The bot covers repetitive questions, which are usually a large share of volume, and frees your people for the cases that genuinely need judgement.
A platform gives you a template and you adapt your business to it. It goes live fast, and for a smaller scope it’s entirely the right choice — if your questions are standard and no integrations are needed, we’ll recommend it.
The difference shows when the bot has to see your data: order status, an invoice, a booking. On a platform that usually means either a limited connector or a hand-maintained middle layer, and that is where things get stuck. A custom build costs more and takes longer, but integrates directly and lets you swap the model later without swapping the platform.
We agree before building what may be sent to a model at all. Personal data, payment numbers and health data are filtered out before anything leaves, and where a question touches them the conversation goes to a person anyway.
On business API tiers, what you send isn’t used to train the model — that’s a term in the providers' contracts rather than a promise from us, and we’ll show you where it says so. If that still doesn’t suit, an open model running entirely on your own infrastructure inside the EU is an option. It costs more and is usually somewhat weaker, but nothing leaves the building — and in some sectors that’s the only workable answer.
Conversations are logged, and the retention policy is agreed in writing.
Three separate costs worth looking at individually. First, building it. Second, model usage, billed per request — that depends on how many conversations you have and how much context goes with each one, and in a well-built solution it’s small next to one support agent’s hourly rate. Third, the ongoing improvement, which is the one most often underestimated.
We set up cost tracking and ceilings from the start, so the invoice can’t creep up quietly. We’ll also say upfront when your conversation volume is low enough that a bot simply won’t pay for itself — in which case better search or a proper FAQ page is the cheaper answer.
Well enough, but not automatically. Estonian is a small language and models handle it less evenly than English — inflection, phrasal verbs and domain vocabulary break more often, especially when an answer is translated on the fly from an English source.
So we test Estonian separately, with real questions from your own domain, and show you the result before it goes public. Often the fix is to hold the source material in Estonian rather than translating answers at request time. If the quality isn’t good enough, we’ll say so — a bot that answers intelligibly but slightly wrongly is worse than one that hands over to a person straight away.
Describe your situation in a couple of sentences. We reply within one working day.