AI Chatbots for Business: Build, Buy or Connect

An AI chatbot for business is a conversational assistant, built on a large language model, that answers customers or staff in plain language using your company’s own information. You have three ways to get one. Buy it as a feature of a tool you already pay for, such as your help desk or website builder. Build it yourself on a model provider’s API, with retrieval over your documents. Or connect an assistant your team already uses, such as ChatGPT, Claude or Copilot, to your own systems. Whichever you pick, the same four things decide whether it helps or embarrasses you: it answers from your content, it hands off to a person, it keeps a log, and it treats people’s data the way you promised.

First decide who the chatbot is for

The word “chatbot” covers two very different jobs, and the choice between build, buy and connect depends on which one you mean.

• Customer-facing: a chat window on your website or app that answers questions about orders, hours, returns or your product. Strangers use it, so mistakes are public and every answer is a statement by your business.
• Internal: an assistant your own staff use to find a policy, draft an email, summarize a long thread or look something up in your systems. Mistakes stay inside, and the people using it can judge the answers.

Most small businesses get value from the internal kind first, because it is cheaper to get wrong. Customer-facing bots need more care, which is what most of this page is about. The day-to-day support side, triage, escalation and what stays human, is covered in AI agents for customer service.

Option 1: buy a chatbot inside a tool you already use

Help desks, website builders, ecommerce platforms and CRMs now commonly offer an AI chatbot as a feature or add-on. It reads the help articles already in the tool, sits in the chat widget you already have, and hands conversations to the same agents who answer email today.

• Good for: customer questions that your help center already answers, with a support team already working in that tool.
• You control: which articles it reads, the tone, when it hands off, and the hours it runs.
• You give up: control over the model, the retrieval and often the logs, which stay inside the vendor’s product.
• Check before buying: whether it can say “I don’t know,” how handoff works, what it does with transcripts, and whether the vendor trains on your data.

Option 2: build one on a model API

Building means calling a model provider’s API from your own code, retrieving the right passages from your documents for each question, and putting them in front of the model with instructions to answer only from them. That retrieval step is called RAG, explained in what is RAG.

• Good for: answers that need your own data, such as order status or account details, or a product where the chatbot is part of what you sell.
• You control: everything, including which model, what it can look up, how answers are checked and how long logs are kept.
• You take on: building it, testing it, watching it, and fixing it when the model or your content changes. It is a product, not a setting.

Option 3: connect an assistant your team already has

For internal use there is a third route that did not exist a few years ago. The assistants your staff already use can be connected to your own tools, so they can read a shared drive, a ticket queue or a task board without you building a chatbot at all. The common way to do that is the Model Context Protocol↗ (opens in a new tab), which its own documentation calls “an open-source standard for connecting AI applications to external systems.” Each tool publishes an MCP server; the assistant signs in to it as the person using it.

This route suits teams more than customers: the people asking are your staff, signed in under their own names, with the access they already have. How business plans of one popular assistant handle data and admin controls is covered in ChatGPT for business.

What every business chatbot needs

Grounding in your own content

A model on its own knows the internet up to its training date, not your return policy. Give it your content and tell it to answer only from that content, cite the article it used, and say so when the answer is not there. Then keep the content current: most bad chatbot answers trace back to an outdated help article, not to the model.

A handoff to a person

Decide before launch when the bot stops and a person takes over: when the customer asks for a human, when it is not confident, when money, account access or safety is involved, and when the same question comes back twice. The handoff should carry the conversation so far, so the customer does not repeat themselves. Outside business hours, say when a person will reply rather than pretending.

Logging

Keep a record of what was asked, what the bot answered, which sources it used and whether it handed off. Without logs you cannot find wrong answers, prove what the bot said, or improve it. Read a sample every week. The NIST AI Risk Management Framework↗ (opens in a new tab), which NIST describes as “intended for voluntary use,” is a reasonable US reference if you want a fuller structure for measuring and managing these risks.

Privacy and security

Customers will paste in things you did not ask for: card numbers, health details, passwords. Decide how long transcripts are kept, who can read them, and whether the vendor may use them. The FTC has warned AI providers that companies which fail to abide by their privacy commitments to their users and customers↗ (opens in a new tab) “may be liable under the laws enforced by the FTC,” including promises not to use customer data to train models. Read your vendor’s terms, and make your own privacy policy match what actually happens.

Treat everything a user types as untrusted. OWASP↗ (opens in a new tab) lists prompt injection first among its risks for LLM applications: input that alters the model’s behavior “in unintended ways.” A chatbot that can only answer is low risk; one that can issue refunds or change accounts needs those actions behind a person. More on this in indirect prompt injection.

What the FTC expects from AI chatbots

There is no single US chatbot law, but the FTC Act’s ban on deceptive practices applies to what your bot says and to what you say about it. When the FTC announced Operation AI Comply↗ (opens in a new tab) in September 2024, one case concerned a service sold as “the world’s first robot lawyer”; the complaint alleged the company did not test whether its chatbot’s output was equal to a human lawyer’s. The lesson for any business: do not claim your chatbot can do more than you have tested, and do not let it imply it is a person.

If children or teens may use your chatbot, take extra care. In September 2025 the FTC opened a study of seven companies↗ (opens in a new tab) whose chatbots act as companions, asking how they measure and limit harm to young users and how they comply with the Children’s Online Privacy Protection Act Rule. None of this is legal advice; ask counsel about your own case.

A launch checklist

1. Write down the twenty questions the bot must answer well, with the correct answers, and test against them before launch and after every change.
2. Write down what it must never do: give legal, medical or financial advice, promise refunds, discuss other customers.
3. Set the handoff rules and test each one with a real person on the other end.
4. Tell users they are talking to an AI, and show how to reach a person.
5. Decide log retention and who reads the weekly sample.
6. Pick one owner for the bot’s content and one for its behavior.
7. Launch to a slice of traffic or to staff first, and read every transcript for the first week.

Where fenbs fits

fenbs is not a chatbot and has no customer inbox. It is a task board shared by people and AI assistants, and it is where the work a chatbot creates gets done. Every wrong answer found in the weekly sample becomes a bug, every missing help article an enhancement, and every repeated request for something you do not offer a feature, each with a priority from 1 to 10. Your “never do” list and handoff rules go on the Decisions and rules page, where a person decides each rule and every connected AI assistant reads the rules first. An assistant connected over MCP can file those tasks itself, and History records each change under the name of whoever made it.