A website chat window next to a business system drafting a summary from its own record

Summary: AI chatbots have improved a great deal, and most business owners are now being pitched one. This guide is for owners deciding whether a chatbot will actually save time, and what to build instead when the real work is happening somewhere other than a chat window.

A few years ago a website chatbot was a script: a pop-up that matched your question to a list of prepared answers and handed you to a person when it ran out. Today’s chatbots are driven by large language models (LLMs), the same kind of AI behind ChatGPT, and they write their answers in plain language on the fly. They are far more capable, and far easier to buy.

That makes the real question sharper. A chatbot is one way to use AI. It is rarely the only way, and for most operations-heavy businesses it is not where the time goes. Before you sign up for one, it is worth checking which problem you are actually trying to solve.

What is an AI chatbot today?

An AI chatbot is a chat window, on your website or inside your own tools, where an LLM answers questions in plain language instead of picking from scripted replies. The better ones are “grounded”: before answering, they look up your own documents, such as your FAQ, product sheets or policies, and answer from those rather than from the model’s general knowledge.

Grounding matters more than the model. A chatbot that answers from your documents can be checked and corrected. One that answers from general knowledge will sound just as confident when it is wrong.

When is a chatbot the right tool?

A chatbot earns its place when the same questions arrive over and over, the answers already exist in writing, and an occasional imperfect answer costs little. Typical examples:

  • Store hours, shipping times, return windows and other policy questions a support team answers dozens of times a week.
  • “Where is my order?” lookups, when the chatbot can read order status from your store without being able to change anything.
  • First-line questions on a large product catalog, with a clear handoff to a person for anything specific to a customer’s account.

If that describes your support inbox, you probably do not need custom software. Most help desk and ecommerce platforms now offer a chatbot add-on that answers from your own help articles. Start there.

When does a chatbot make things worse?

Chatbots fail in predictable ways. These are the ones to check before launch, not after:

  1. Confident wrong answers. An LLM can produce a fluent answer that is simply untrue, known as a hallucination. Grounding reduces it; it does not remove it.
  2. Answers that commit you. Prices, warranties, refund terms and delivery promises. In February 2024 a Canadian tribunal ordered Air Canada to compensate a customer after its website chatbot wrongly told him he could claim a bereavement discount after booking. The airline argued the chatbot was responsible for its own words; the tribunal disagreed. Anything a chatbot says on your site can be read as something your company said.
  3. Customer data in the wrong place. A chatbot that can see accounts, orders, or health or financial details needs the same access controls as any other system that holds them. Many add-ons are not built for that.
  4. Stale knowledge. The chatbot is only as current as the documents behind it. When a policy changes and the document does not, the chatbot keeps giving the old answer.
  5. Nobody owns it. Someone has to read the conversations, fix the gaps and update the sources every month. Without an owner, quality drifts and customers notice before you do.
  6. It hides a process problem. If customers keep asking where their order is, a chatbot answers faster. Fixing the delay, or sending the tracking update automatically, removes the question.

Where does AI usually pay off instead?

For most businesses that run on real systems, the time is not lost answering questions. It is lost inside the work: re-keying data from one system into another, writing the same kind of document every week from information already recorded somewhere else, and reading through free-form responses to find what matters.

That is where AI built into your existing software pays back, usually behind a single button in a screen your team already uses. Three projects we have delivered, none of them chatbots:

  • MediaTrAiner for Fight or Flight, an international PR agency. A user uploads a practice media interview; the platform scores the spokesperson against the agency’s own framework and writes the article a reporter might have produced. Shortlisted for Best AI Platform at the PRWeek US Awards 2026.
  • AI report writing inside a commercial property inspection platform. The client’s team had been writing narrative report sections by hand in a consumer chat app. We built it into their platform: the narrative is generated from the report’s own data under a locked structure, with length limits enforced in code, and a person reviews it before it goes out.
  • The University of Washington PBIS Voice tool. A custom WordPress plugin that clones Qualtrics surveys from a request form, tracks each one to close, and summarizes free-form responses with the OpenAI API.

In each case the AI works on data the system already holds, its output lands in a place someone checks, and nobody has to copy anything into a chat window.

How to decide: six questions

Answer these about the specific task you have in mind, not about AI in general:

  1. Is the work answering questions, or producing something? Answering points toward a chatbot. Producing a record, a report, an entry or a summary points toward AI inside the system that holds the data.
  2. Do the answers already exist in writing? If yes, a grounded chatbot can use them. If the knowledge lives in people’s heads, write it down first; no AI fixes that step for you.
  3. What does a wrong answer cost? If a mistake means an annoyed customer, a chatbot with a handoff is fine. If it means a commitment, a compliance problem or a bad decision, keep a person reviewing the output before it matters.
  4. Does it need customer-specific or confidential data? If yes, access control is the project, and a generic add-on is rarely the right container.
  5. Who reads the output before it counts? Built-in AI with a review step fits most internal work. A public chatbot has no review step at all.
  6. Who will own it after launch? Name the person before you buy anything. If nobody comes to mind, that is the answer for now.

If most of your answers point toward the chatbot, buy an off-the-shelf one from your help desk or store platform and keep it grounded in your own documents. If they point the other way, the opportunity is inside your systems.

What should you do before buying either?

Find out where your team’s time actually goes. Most owners who are pitched a chatbot have never seen their systems, data and repetitive work laid out on one page, and that picture usually changes the question.

That is what our AI Readiness Assessment does: a fixed-fee review of your systems and data that ranks where AI would save real time or money, says which data to keep away from it, and gives you a roadmap. Smaller businesses with a few core systems start with the two-week Essentials version. Every report includes options that do not involve us, and “a chatbot add-on from the platform you already pay for” is sometimes the honest recommendation.

Where Sandcastle Fits

We do not sell chatbots. We build AI features into the software businesses already run: custom applications, portals and ecommerce systems where the data already lives, with review steps and limits enforced in code. We have been connecting business systems since 2001, and connecting them to AI is the newest part of that work.

If you are weighing a chatbot pitch against the work your team does by hand every week, tell us what you are trying to fix. We will tell you honestly which side of the checklist it falls on.