A chatbot for your business: when AI customer service pays off and when it hurts
A chatbot can take load off your team and answer clients at any hour — but only under three conditions. Below: when it pays off, when it hurts and why the most important moment is the one where the bot stops answering.
The short answer
A chatbot pays off when three conditions hold at once: clients keep asking the same questions, the answers are written down somewhere and there are enough questions that someone loses real time on them every day.
The most important part of a well-built chatbot is not answering, but the moment it stops answering and hands the case to a person. A bot that cannot step back does more harm than no bot at all.
What it is in practice
When we talk about AI customer service, we do not mean a little robot window in the corner of a page pretending to chat. We mean three elements joined into one flow.
The bot handles the first line of questions. Opening hours, order status, delivery terms, how to change a booking, how much a service costs — anything where the answer is always the same.
Harder cases go to a person. A complaint, an unusual order, an upset client — the bot recognises them and passes them on, together with the whole conversation so far.
Everything lands in one shared inbox. The team sees every conversation — the ones the bot closed and the ones it handed over — in one place, not in five channels.
Without the third element you have two separate worlds: a bot that answers something, and a team that does not know what.
When a chatbot makes sense
Clients keep asking the same thing
Run a simple test: look through the last fifty messages from clients and count how many are questions you have already answered word for word. If it is more than half — you have material for a chatbot. If every message is different — you do not.
The answers are written down somewhere
A chatbot knows nothing about your company. It answers from the knowledge you give it: the price list, terms, service descriptions, frequent questions. If that knowledge lives only in people's heads, the bot has nothing to draw on — and it will start guessing, sounding confident as it does.
The good news: writing that knowledge down takes a day or two, and it helps new employees as well.
There are enough questions
With a few messages a week a chatbot will never pay for itself — it is faster to reply by hand. It starts to make sense when someone on the team answers repetitive questions every day, and some of them arrive in the evening and at weekends, when nobody replies.
When a chatbot hurts
When it cannot hand a case to a person. The worst thing that can happen to a client is a loop: they ask about something unusual, the bot answers off-topic, they ask again, the bot is off-topic again. After the third attempt the client is no longer your client.
When it handles emotional cases. A complaint, a late order, an invoice error — here the client wants to know somebody is dealing with them. The bot can take the report and confirm it reached the right person. It should not try to resolve it.
When the answer has to be identical word for word. Contract terms, rules, prices in a quote. A language model phrases its answer slightly differently each time — where exact wording matters, the bot should point to the source rather than paraphrase it.
When it pretends to be human. A client who realises they were talking to a bot introducing itself as "Kate from support" loses trust in the whole company. And since August 2026 it is simply unlawful — more on that below.
The most important part: handing over to a person
A chatbot's quality is decided not by how many questions it answers, but by how well it recognises when it should not answer.
A well-set handover follows simple rules:
| Situation | What the bot does |
|---|---|
| A question from the knowledge base | answers itself |
| A question outside the knowledge base | says plainly it is passing the case on, and does |
| A complaint | takes it, confirms it, hands it over |
| The client asks for a person | hands over at once, without persuading |
| A second failed answer in a row | hands over before a loop forms |
At handover the bot leaves the person the whole conversation so far. The client should not have to explain again from the start what they want — one of the most irritating things in customer service in general.
The bot tells the client when a person will respond. "I have passed on your question, we will reply by 12:00 tomorrow" works completely differently from "I have passed on your question".
A chatbot or a plain rule
Not all customer service needs artificial intelligence. If the client picks from a list what they want to ask about, and the answer depends only on that choice — plain rule-based automation is enough. It is cheaper, faster and never makes a new kind of mistake.
A language model is needed only when clients write in their own words and questions arrive in dozens of different phrasings. We covered this distinction in detail in the piece on when a rule is enough and when you need an AI agent.
An obligation you need to know about
Since 2 August 2026 a client must know they are talking to artificial intelligence. This follows from Article 50 of the EU AI Act and applies to every chatbot based on a language model that talks to clients.
In practice a clear notice at the start of the conversation is enough. We covered the details in the piece on the new AI disclosure obligation.
What it costs
The cost has two parts.
Implementation — one-off. It covers preparing the knowledge base, setting the handover rules, connecting the channels clients write in and the team's shared inbox. In our pricing this is usually the scope of automating a whole process.
Running the model — monthly. At typical small-business volumes this is usually PLN 50–300, depending on the number of conversations and the length of replies.
When comparing costs, count not only the hours saved on replying but also the enquiries that arrive in the evening and at weekends and get an answer on Monday. By Monday some of them are already with a competitor.
Where to start
Write down the twenty most frequent questions and answers. That is the foundation — and a test. If they cannot be written down because every case is different, a chatbot is not for you.
Set the handover rules. When the bot hands a case over, to whom, and how soon that person replies. It is a business decision, not a technical one — and whether clients are happy depends on it.
Start with one channel. The website form or a messenger — wherever most questions come in. After a few weeks you can see what the bot answers well and where it hands over too often, and only then is it worth expanding.
Frequently asked questions
No, and it should not. It takes over the repetitive part of the work — questions whose answer is always the same — so the team has time for cases that need a person. In a well-set flow the team handles fewer but more important conversations.
The risk drops when the bot answers only from written-down knowledge and has a clear rule: if the answer is not in the base, it hands the case over instead of guessing. That is why building the knowledge base and the handover rules is the most important part of the implementation.
They want a fast answer. If the bot gives one — say at 22:00 on a Saturday — the client is happy. If the bot goes round in circles and will not hand the case to a person — the client is furious. What decides is whether the bot solved the problem, not that it was a bot.
Yes. Since 2 August 2026 Article 50 of the AI Act requires it. A clear notice at the start of the conversation is enough.
There is no single threshold. It starts to make sense when someone answers repetitive questions every day and some messages arrive outside office hours. With a few messages a week it is faster to reply by hand.
Yes, it can handle several channels at once — the website form, messengers, email. But it is worth starting with one, the one with the most questions, and expanding only after a few weeks.
He spent five years building operations at WebWave: from creating a support department from scratch to the role of Head of Operations and leading the integration after the company was acquired. While putting those processes in order he noticed how much time is taken up by work that develops nobody — and that the tools capable of taking it over already exist. A graduate in corporate finance from the SGH Warsaw School of Economics.
LinkedIn profile →