- Why might a business delay building a chatbot?Its information may be unreliable, its systems disconnected or its intended use case too broad to support dependable answers.
- Does a chatbot require perfect data?No, but it needs a sufficiently reliable and well-defined information scope for the claims it is expected to make.
- What should be built before a chatbot?Depending on the problem, this could include authoritative knowledge sources, data governance, APIs, access controls and an escalation workflow.
- How should a chatbot pilot be measured?Evaluate answer quality, appropriate abstention, resolution rates, escalation burden, user experience, and operational impact.
- Is a chatbot always the best use of AI?No. Search improvements, conventional automation or workflow redesign may solve the problem more simply and reliably.
Reading Time: 6 min
Why We Said No to Building a Chatbot First
A chatbot is often one of the first ideas that emerge when a business decides to adopt artificial intelligence. The appeal is understandable. It is visible, easy to demonstrate, and familiar to users. It appears to offer a straightforward way to reduce support workload, make information accessible and modernise a customer experience.
But a visible AI feature is not necessarily the right starting point for an AI initiative. Sometimes the most responsible recommendation is to delay the chatbot until the underlying information, processes and systems are ready to support it.
That is the thinking behind this series: not every promising technology idea deserves an immediate yes. Saying no to the first proposed solution can be the beginning of a better engineering decision.
The request sounds simple. The underlying problem rarely is.
Imagine a business that wants a chatbot to answer customer questions. During the initial discussion, the opportunity seems obvious: customers ask repetitive questions, the support team is busy and AI could provide answers around the clock.
Then the team examines the actual process. Product information differs across systems. Policies have not been updated consistently. Customer-specific information lives behind several applications. Some answers depend on order status, account permissions or an exception that requires human judgment. The support team itself uses internal documents that are incomplete or out of date.
A chatbot can be built against this environment, but the result is unlikely to be dependable. It may give a confident answer based on outdated information, fail to retrieve a critical detail or provide a generic response when the customer needs a specific action.
The immediate request was for a chatbot. The underlying problem was unreliable access to accurate information and the processes needed to act on it.
Those are different problems, and they require different engineering work.
A conversational interface cannot repair a broken source of truth
AI systems can make information easier to access, but they cannot automatically make the underlying information accurate, consistent or authorised for use. If multiple systems disagree, the architecture needs a policy for deciding which source takes precedence. If information is stale, the organisation needs a process for updating it. If a question requires customer-specific data, the system needs appropriate identity verification and access controls.
These requirements are not minor implementation details. They determine whether the chatbot can be trusted.
A responsible design may require a curated knowledge base, reliable APIs, clear ownership of business information, permission-aware retrieval, monitoring and escalation to a human. For transactions or consequential actions, it may also need explicit confirmation and deterministic validation before changes are committed.
This does not mean a chatbot must wait until every enterprise system is perfect. It means its scope should reflect the reliability of the information and actions available to it. A chatbot that answers a limited set of well-supported questions may deliver more value than a general-purpose assistant that promises to do everything.
The right question is not whether we can build it
Engineering teams are often asked whether a proposed AI feature is technically feasible. In many cases, the answer is yes. A model can be connected to a user interface, supplied with documents and integrated with selected services. A demonstration can be produced quickly.
However, technical feasibility is only one part of the decision. The more important questions are whether the feature solves a meaningful problem, whether its outputs can be trusted, whether users will adopt it, and whether the organisation can operate it responsibly.
A useful evaluation examines the current cost of the problem, its frequency, the quality of available data, the risks of incorrect answers and the operational work required to maintain the solution. It also compares the chatbot with simpler alternatives. Better search, improved help content, workflow automation, or a small integration may resolve the problem with less complexity.
The best solution is not necessarily the one that uses the most AI. It is the one that improves the outcome at an acceptable level of risk and cost.
Saying no should lead to a better next step
A refusal is not useful if it simply closes the conversation. When an engineering team recommends against building a chatbot first, it should explain the specific gaps, the consequences of ignoring them, and the smallest practical steps that would make the idea viable.
For example, the first phase might consolidate the most frequently requested information, identify authoritative sources and create a reliable retrieval interface. The next phase could introduce a narrowly scoped assistant that answers approved questions and cites its supporting information. Once the system demonstrates acceptable quality, the organisation could consider account-specific queries or actions, subject to authentication, permissions and appropriate controls.
Each stage should have explicit evaluation criteria. How often are answers correct? How often does the assistant abstain when information is insufficient? How many conversations are resolved without unnecessary escalation? Are customers receiving better outcomes, and is the support team’s workload actually improving?
These measures allow the organisation to expand based on evidence rather than enthusiasm.
AI adoption requires the discipline to reject bad starting points
The pressure to demonstrate AI adoption is real. Leaders want progress, teams want to experiment, and stakeholders often prefer a visible feature to less glamorous work on data quality or system integration. Yet the visible demonstration can create expectations that the underlying system cannot sustain.
A chatbot launched too early may generate misleading answers, frustrate users, and damage confidence in future AI initiatives. The organisation may then conclude that AI does not work, when the actual failure was a mismatch between the promised capability and the system’s readiness.
The alternative is not endless planning. It is disciplined experimentation: choose a meaningful problem, establish the minimum reliable foundation, start with a bounded use case and expand only when the evidence supports it.
At Prologic, this is the kind of distinction that matters when approaching AI as an engineering discipline rather than a collection of features. A strong technical team should be able to build what a client requests, but it should also have the judgment to explain when the requested solution is premature.
Saying no to a chatbot first does not mean saying no to AI. It means saying yes to solving the right problem in the right order.
Sometimes the best first step towards an intelligent system is to build the foundations that make its intelligence useful.