Why chatbots have a bad reputation
A chatbot gives people a conversational way to use a service. Rule-based chatbots follow predefined options or conditions and can be useful for bounded tasks. They still need validation, fallback paths and maintenance; neither perfect operation nor total failure outside a scripted path is inevitable.
An AI chatbot uses a model to interpret language and generate or select responses. It may handle varied phrasing or Hindi-English messages, but quality must be tested with the actual questions and languages customers use. Language flexibility is not proof of factual accuracy.
The design decision that matters most
Ground answers in approved, current material such as service details, policies and price lists. This reduces hallucination risk but does not eliminate it: retrieval may return the wrong passage and a model may misinterpret it.
Test unsupported questions, contradictory documents and stale prices. Configure uncertainty handling, source checks and human escalation. Use authenticated live lookups for private order details rather than putting customer records into a public knowledge base.
What a chatbot realistically does for a business
A chatbot may reduce friction, but benefits need measurement rather than promises.
- Out-of-hours capture: offer answers and an enquiry route when staff are unavailable, while stating when a person can respond.
- Useful answers: explain service areas, inclusions and next steps; do not assume an answer retains every visitor.
- Structured handover: collect only the details needed for the task and let a person see relevant context.
- Reduced repetition: compare staff handling time and correction work before and after a pilot.
- Content feedback: review privacy-safe question patterns to find missing website answers.
Track successful handovers, unanswered questions and errors alongside enquiry counts. A chatbot cannot guarantee sales, visitor retention or recovered enquiries.
What makes a chatbot annoying
Almost all of it is configuration rather than technology, which means it is avoidable.
- Interrupting immediately. A pop-up two seconds after arrival, before the visitor has read anything.
- Hiding the human. No visible route to a person is the single most resented pattern.
- Pretending to be a person. Customers work it out, and the ones who feel misled complain publicly.
- Being confidently wrong. A wrong price quoted by your own website is worse than no price.
- Implying someone is available at 2am. Say honestly when a person will respond.
- Demanding contact details before answering anything. Answer the question first; ask afterwards.
The knowledge base is the project
People assume building a chatbot is a technical exercise. In practice, the build is rarely the constraint — preparing the material is.
What has to happen:
- Collect the real material: current price lists, package inclusions, policies, service details, terms, and the answers your team already types out every week.
- Resolve the contradictions. Most businesses have an old price list somewhere, a superseded policy, a brochure with last year's timings. These have to be sorted out before the chatbot inherits them.
- Write down what was never written down. What happens if a booking is cancelled. Whether the price includes taxes. What the minimum order is. Which areas you will travel to.
- Decide what stays private. Internal margins, negotiation limits, staff information.
Step three identifies information visitors may need before contacting you. Filling those gaps can improve clarity on the website and the way AI systems describe you; neither a better answer nor an AI citation is guaranteed.
What it costs
Three separate numbers.
Build: one-off, driven mainly by how much knowledge preparation is required. A small business with clear, current content is a modest project. A large catalogue with many policies is not.
Running: AI model usage and hosting, scaling with conversation volume. Should be billed to accounts in your own name so you can see the usage and leave if you want to.
Upkeep: small but real. When prices, packages or policies change, the source material needs updating. A chatbot quoting last season's rates is actively harmful, and this is the most common way a good chatbot becomes a bad one.
Should your business have one?
A reasonable test:
Probably worth it if: you get a meaningful number of website visitors or WhatsApp messages each week; the same questions come up constantly; a significant share of enquiries arrive outside working hours; your information is documented or could be; and enquiries currently go unanswered on busy days.
Probably not yet if: your traffic is very low, in which case fixing visibility comes first; your enquiries are all genuinely unique; your information is not written down anywhere, in which case that is the project; or you already respond to everything within minutes, in which case a chatbot adds little.
There is also a middle path worth considering. Before commissioning a chatbot, publish clear answers to the ten questions you are asked most, on the relevant pages. Some businesses find that this alone resolves most of the problem — and if it does not, you have just produced the knowledge base the chatbot needed anyway.
Chatbot or agent?
A chatbot is a conversational interface. It can answer questions and, with integrations and permission checks, look up orders, create records or trigger actions. An AI workflow uses a model within predefined steps. An AI agent lets a model choose some next steps or tools towards a goal, within explicit limits. These categories can overlap: a chatbot may front either a fixed workflow or an agent.
Choose by the decisions the system must make, its permissions and the consequences of error, not by the label. A fixed booking flow can act without being an agent; an internal research agent may only read information. Start with the least complex design that meets the need and test the whole workflow.
For delivery options, compare chatbot development with agent development. Agree permissions and approval points before connecting either to customer records.
Privacy and failed handovers
Log enough to diagnose failures: event IDs, timestamps, action status, approval decisions and a limited sample of interactions where justified. Mask sensitive data, exclude credentials, restrict access by role and agree a retention and deletion period. Do not keep every conversation indefinitely. Use redacted examples for testing and explain the collection to users.
Plan for timeouts, rate limits and unavailable integrations. Use bounded retries for temporary failures, and a unique request or operation ID to prevent duplicate records, messages or bookings. A timeout can occur after an action succeeds: check its status before retrying. Alert a named owner after retries are exhausted, preserve a recoverable queue and offer human escalation. Test cancellation, duplicate delivery and partial failure before expanding access.
Sources and further reading
These sources explain platform guidance or engineering principles, not evidence of PresenticAI client results. Guidance checked on 14 October 2026.
Considering a chatbot for your website?
PresenticAI builds grounded chatbots that answer from your own material, capture enquiries properly and hand over cleanly — and will tell you if your enquiry volume does not justify one.