The difference between a disappointing chatbot and a useful one rarely lies in the underlying language model. It lies in the connection: a chatbot that only gives generic answers adds little. A chatbot connected to your knowledge base, product catalogue or customer data can actually answer questions specific to your business.
Where the time savings come from
The biggest saving is usually not in taking over complex support questions, but in catching the simple, repetitive ones: opening hours, delivery times, how a process works. These are the questions that now often cost an email or phone call, and that a well-trained chatbot handles on its own around the clock.
When it is not a good idea
For businesses with few repetitive questions, or where personal contact is precisely what sets them apart, a chatbot adds little and can even create distance. We would rather build no chatbot than one that does not fit how a business treats its customers, and we say so honestly when that is the case.
Chatbot versus contact form
A contact form asks a visitor to wait until someone replies, often not until the next working day. A good chatbot answers immediately, at the moment the question comes up, even outside office hours. That is exactly where the conversion gain comes from: a visitor who instantly gets an answer to "do you also deliver at weekends" drops off less quickly than one who has to fill in a form and wait.
That does not make the form redundant. For questions the chatbot cannot answer, or a concrete quote request, a human contact moment remains necessary. The chatbot handles the run-up; the form or conversation remains where a deal is actually closed.
What a chatbot needs to work well
The quality of an AI chatbot depends on the source data it is based on: an up-to-date knowledge base with FAQs, product information or service descriptions, and ideally a connection to systems that already exist, such as a CRM or inventory system, so the chatbot does not give outdated or incorrect information. Building a chatbot without that source data in order produces a system that sounds plausible but is regularly wrong, which damages visitors’ trust.
Maintenance is just as important as for a website: new products, changed opening hours or adjusted terms must be updated in the source data, or the chatbot falls behind reality.
Privacy and GDPR considerations
A chatbot that processes personal data, such as a name, email address or a question traceable to a specific customer, falls under the GDPR. Among other things this means making clear to visitors that they are talking to an AI system, not keeping data longer than needed, and having a data processing agreement with the party hosting the underlying language model. We include these points as standard when setting up a chatbot, so you do not run into a compliance problem later.
How TechGents approaches it
Our AI projects start at €3,500. After a short call we map out which questions come up most, which systems the chatbot should connect to, and what realistic expectations are: a chatbot does not solve everything, but it can take away most of the repetitive questions. You then receive a fixed quote, not an open-ended project where costs rise as it progresses.
How to make results measurable
An AI chatbot without measurement is a cost you can never be sure pays for itself. Useful statistics: how many conversations the chatbot handles per week, what percentage is resolved without human help, and which questions are asked most often but cannot be answered well. That last category is particularly valuable: it shows exactly where the knowledge base needs to be added to.
We advise scheduling a short evaluation after the first month: what works well, what is still missing, and have emails and phone calls about common questions actually decreased? Based on that the chatbot is refined, instead of being delivered once and then left alone.
A chatbot as part of a wider system
Most value arises not when a chatbot stands on its own, but when it is embedded in a wider process: a chatbot that passes a lead straight to the right team member, schedules an appointment in the calendar, or pre-fills a quote request based on the conversation. Such connections make the difference between "a nice addition to the website" and a system that actually saves the team behind it time.
Which language model is behind it, and why it matters less than you think
Business owners often ask which AI model we use, assuming it is the main difference between chatbots. In practice the large language models from the major providers are all capable enough for most applications on a business website. The difference, as described above, almost always lies in the connection to your own data, not in which brand of model runs in the background. We choose the model per project that best fits the desired speed, cost and languages, without tying ourselves to one supplier.
Can a chatbot give wrong answers?
Yes, and that is exactly why a chatbot is always set up to stay within clear boundaries: it answers questions based on the knowledge base provided, and is explicitly configured to refer to a person as soon as a question falls outside those boundaries, instead of guessing. That is a deliberate design choice, not a technical limitation: better a chatbot that honestly says "I do not know, let me connect you" than one that confidently claims something incorrect.
Managing visitors’ expectations
Visitors respond better to a chatbot that presents itself clearly as an AI assistant from the start than to one pretending to be human. Being transparent about it builds trust instead of breaking it as soon as someone realises they are not talking to a person. The same goes for managing expectations about what the chatbot can and cannot do: a short introduction stating what the assistant can help with prevents disappointment with questions outside that scope.
Start small, then expand
The most effective chatbot projects we have built started small: a limited set of common questions, answered well, rather than an attempt to automate everything at once. From that base you expand based on what users actually ask, instead of guessing what they might ask. This keeps the first investment manageable and ensures every next step is based on real data rather than assumptions.