The chat window added a step
The support assistant looked useful until a returning customer asked to change a delivery address. The account already contained the order, the address and the available actions. The chatbot still asked the customer to explain the situation, identify the order and confirm information the system could have loaded itself.
Nothing was automated. A form had been replaced by a conversation, and the conversation was slower.
Chat is valuable when the intent is genuinely unclear, the answer benefits from follow-up questions or the person needs help navigating a complex subject. It is a poor default for work that is structured, repeatable and already understood by the product. The interface should absorb complexity, not ask the customer to narrate it.
Some chat problems are search problems
A person asking where the refund policy lives does not necessarily want a conversation. They want the right passage, for the right market and order type, without opening several documents.
Better search is the honest answer when the task is retrieval. That means indexing the content properly, preserving titles and metadata, filtering by permissions and showing the source beside the result. Natural language can still help interpret the query, but the product should return a stable destination rather than simulate a helpful colleague.
The uncomfortable part is that search quality depends on content quality. A chatbot cannot repair duplicated policies, missing ownership and contradictory documents. It may only hide the mess behind a fluent answer.
Some chat problems are forms that should remember
Structured work deserves a structured interface. Booking an appointment, reporting an incident, requesting access or configuring a product all contain fields, dependencies and validation rules. A conversation makes those rules invisible. It also makes review difficult because answers are scattered through a transcript.
A better form remembers known details, saves progress and reveals only the next relevant question. It can explain unfamiliar fields and offer an assistant at the point of confusion without turning the whole task into chat.
This matters internally as well. An employee should not have to tell an assistant their department, manager and cost centre when identity and organisation data already provide them. Repeated questions are not personalisation. They are evidence that the systems were never connected.
Some work should run without asking
An invoice arriving in an inbox, a lead changing status or a stock level crossing a threshold is already an event. No person needs to open a chatbot and request the next step. The workflow should classify the input, validate the required data, perform the safe actions and route exceptions to an owner.
Chat can remain as an inspection surface. An operator may ask why a case stopped or request a summary. It should not become the ignition key for a process that the system can start reliably on its own.
This is where chatbot projects often reveal a deeper avoidance. The visible conversation is easy to demo. The invisible work, permissions, integrations, retries and ownership, is the actual product.
Audit the interface this week
Take recent chatbot conversations and label the underlying job. Separate retrieval, structured data entry, event-driven work and genuinely ambiguous advice. Then inspect every question the bot asks. If the answer already exists in an authenticated system, remove the question and load the data.
Replace retrieval conversations with searchable, cited results. Replace repeated interviews with remembered forms. Move predictable operations into workflows that run from events and surface only exceptions.
Keep chat where dialogue changes the outcome. Remove it where dialogue merely delays the action. A smaller chatbot attached to a better product is usually more useful than a chatbot asked to become the product.