A chatbot for your business: contract before technology
Before choosing a system, define what the bot may say, do, and hand over to a human agent.
In this article
In a sales meeting they promise you a chatbot that answers customers, sets meetings and saves work. You ask what you need to prepare, and you get an answer about an AI model, a WhatsApp connection and a demo that looks smooth. This is the wrong start.
A chatbot is a contract with the customer: what it is allowed to answer, when it must hand over to a human, which actions it is allowed to perform and how you will know the conversation succeeded. Without this contract, you are not buying customer service. You are adding another place where the business can make a mistake.
A chatbot is not a tool — it is a contract with the customer
The first decision is not which chatbot to buy. It is what you are willing to promise the customer through an automated conversation. A clinic with two reception stations needs to decide whether the bot only gives opening hours, or also coordinates an appointment and identifies a situation that requires a staff member.
The contract defines four things:
- Knowledge boundary: which sources the bot relies on and what it does when there is no answer.
- Responsibility boundary: when it stops answering and transfers the conversation to a human representative.
- Action boundary: whether it only presents information or also sets, orders and updates.
- Definition of success: whether you solved a question, shortened handling or only increased the number of conversations.
An office supplies store can make do with a menu that directs to shipping and returns pages. A law firm needs different caution: a question that sounds general can turn into personal advice. That is why the same technological product can suit one business and be dangerous for another.
The practical rule: if you cannot write in one sentence what the bot does when it has no answer, you have not yet written its requirements document.
Three levels of chatbot: menu, Q&A, AI agent — and how to choose between them
There are three useful levels: a fixed menu, a question-and-answer system, and an AI agent that manages a conversation and performs actions. For a small business with recurring questions, the first level may be the right choice. More capability is not necessarily more value.
First level: fixed menu
The customer chooses from options you defined in advance. The bot displays hours, address, cancellation policy or a link to a form. It is easy to test, but it breaks when the customer writes in different words.
An accounting firm in February can use it to route requests for documents, appointment scheduling and questions about a receipt. If most inquiries repeat themselves, there is no reason to pretend that a smart agent is required.
Second level: Q&A
The system identifies different phrasings and returns an answer from a repository you approved. It suits a customer service chatbot, when you have a clear policy and content that is updated.
The disadvantage is maintenance. A change in the returns policy, reception hours or price list must reach the knowledge source. A correct answer a month ago may be wrong today.
Third level: AI agent
An AI agent understands intent, asks follow-up questions, uses sources, and connects between systems. It can check availability, create a request, and pass context to a representative.
This capability requires more testing. An insurance agency needs to decide what the agent is allowed to explain and what requires human review. When an action affects a commitment, a payment, or an official document, human approval is sometimes a condition.
Choose a level according to four questions:
- How many different phrasings does the same request have?
- How often does the information change?
- Does the bot need to read from an internal system?
- Does a mistake on its part create operational or legal damage?
For a broader discussion of the difference between a demo and a working system, read AI for businesses: is the AI you bought actually working, or does it just look good in a demo?. In a WhatsApp bot, the difference between a menu and business knowledge is also described in WhatsApp bot for business: the difference between a bot that answers and a bot that actually knows you.
Decision 1: Where the bot gets knowledge from (and setting the knowledge boundary)
A good bot does not know everything. It knows which sources it is allowed to learn from, who updates them, and what it says when a question falls outside the boundary.
A private clinic needs to separate general information about treatments from a patient's personal information. One source can be the business website, another source a scheduling system, and a third source an internal document for the team. They must not be mixed without deciding what the bot is allowed to expose.
Define for each source:
- The name of the source and the person responsible for it.
- The type of information it contains.
- The date of the last check.
- Who is allowed to change it.
- Which answers may be produced from it.
- What happens when there is a contradiction between two sources.
Also set an exit phrasing. For example: the bot says it has no approved information, offers to transfer to a representative, and explains what needs to be attached. It does not fill gaps by guessing.
A computer services company with a site full of articles needs to decide whether every article is a binding source. Sometimes a marketing article describes a possibility, while the operations document defines a different condition. Without a hierarchy, the bot will choose an answer that sounds convincing and is not necessarily correct.
The acceptance question: Present the bot with a question that does not exist in the database. Does it admit the boundary, or invent an answer that looks professional?
Decision 2: When the bot hands over to a human — escalation rules
Handing a conversation over to a human representative is not a failure. It is the system's safety mechanism, and its rules determine whether the customer will feel heard.
A customer service office needs to define clear triggers:
- The customer asks to speak with a person.
- The customer expresses frustration or repeats the same request.
- The question concerns an unusual price, a commitment, law, medical treatment, or a complaint.
- The bot fails to understand the request for the third time.
- A change is required to customer details, an order, a payment, or a document.
- The conversation takes place outside operating hours and there is no approved emergency route.
A good handover is not just a message that a representative will answer later. It includes a summary of what the customer asked for, the answers already given, and the details collected. A representative at a delivery center should not have to ask the customer to start over after the bot has already clarified the address and order number.
In the clinic, WhatsApp AI agent for a clinic: what it must know before it answers a patient demonstrates why questions about symptoms, urgency, or a change in treatment need a defined route. This is not a place for the system to improvise.
What needs to be decided about the handover
- Which team or person the conversation is transferred to.
- Which hours are covered.
- What information is passed to the representative.
- Whether the customer receives confirmation that the inquiry was received.
- What happens if no representative is available.
- Who reviews conversations that were transferred and not handled.
How you know it works: in a transferred conversation, the representative sees the reason, the context, and the next step. If they still have to investigate the entire event, the bot did not really save work.
Decision 3: Which actions the bot is allowed to perform (book, order, update)
Start with read-only, and only then add actions. A bot that reads opening hours is less dangerous than a bot that books an appointment, changes an order, or confirms payment terms.
Classify every action into one of three groups:
- Read: displaying status, hours, balance, or availability.
- Action with conditions: booking a meeting, opening a ticket, or creating a quote.
- Action that requires approval: cancellation, refund, changing a commitment, deletion, or sending an official document.
A furniture store can let the bot check shipping status. It can let it open a service request, but require approval before a refund. A brokerage can book a visit, but not change the terms of an offer without a professional.
For every action, write:
- Which required fields are collected.
- How the customer's identity is verified.
- What happens if the external system is unavailable.
- Which message is sent after success.
- Which message is sent after failure.
- Whether the action is reversible.
If the bot is connected to many systems, do not assume that a technical connection is a business process. Automation for businesses: when a connection between tools stops being enough explains why an action needs an owner, exceptions, and oversight, and not just an interface that responds to a request.
Where the bot lives: WhatsApp, website, and Instagram — the same rules, different behavior
The contract stays the same, but the channel changes the message length, the expectation, and the type of action. A WhatsApp chatbot needs to continue a conversation that was cut off; a website chatbot needs to direct the visitor to the right page; on Instagram the context is shorter and the entry sometimes comes from a comment or a direct message.
The customer expects a personal and fast conversation. A message that is too long will weigh it down, and a handoff to a representative needs to preserve the history. Also define what happens when a person comes back after hours with a partial sentence.
Website
The bot can display links, collect a form, and identify which page the customer is on. A software company on a sales website needs to distinguish between a question about product capability and a request for a quote.
The channel is suitable for opening a conversation, but not always suitable for collecting sensitive details or completing a deal. Set when the customer is moved to the website or to a more verified channel.
The common mistake is copying the same script to all three channels. Instead, keep the same knowledge and handoff boundaries, and change the message length, the type of buttons, and the details that are allowed to be requested.
How to measure a chatbot: self-service resolution rate, handoff rate, response time, cost per conversation
Measure a business outcome, not the number of messages the bot sent. Four metrics are enough to start: self-service resolution, handoff, response time, and cost per conversation.
| Metric | What it checks | How to calculate | Warning sign |
|---|---|---|---|
| Self-service resolution | Whether the customer got an answer without a representative | Conversations closed without handoff out of all conversations | Closure without customer confirmation |
| Handoff to a representative | How many conversations require a person | Conversations handed off out of all conversations | Many handoffs for the same intent |
| Response time | How long the customer waits for an answer | Time from the customer's message to the bot's or representative's reply | Gaps in a particular channel |
| Cost per conversation | What it costs to handle a conversation | Infrastructure, maintenance, and partial human handling | Cost higher than the value of the inquiry |
| Resolution quality | Whether the answer actually helped | Sampling and post-conversation feedback | Closure and the same inquiry returning |
A clinic with an appointment calendar should not aim to hand off as few conversations as possible. If the bot hands off every medical question to a person, that may be the right outcome. If, on the other hand, it hands off every request for opening hours, the knowledge or the menu is not built well.
For each metric, set a desired direction, a data source, and an owner. Do not define a number that looks good without asking what it hides. A high self-service resolution rate can indicate that the bot ends conversations before the customer has received a solution.
The bot contract: the full document, clause by clause
This is the structure you can copy into a work document. There is no need to start from the technology; you start by filling in the decisions and testing them.
1. Purpose of the bot
- What business problem the bot solves.
- Who the target audience is.
- In which channels it operates.
- What is not included in the purpose.
- What improvement will look like for the customer and the team.
2. Type of bot
- Fixed menu, question-and-answer, or AI agent.
- Why this level suits the process.
- What risk is created if you move to a more advanced level.
- Which capabilities are deferred to a later stage.
3. Knowledge sources
- The list of approved sites, documents, and systems.
- The source of truth in case of contradiction.
- An owner for each source.
- The update process and review frequency.
- Information the bot never presents.
- The default answer when there is no suitable source.
4. Conversation boundaries
- Topics the bot may explain.
- Topics that require careful wording.
- Topics it must not answer.
- Keywords that trigger a handoff.
- Languages and writing style.
5. Transfer rules to a representative
- An explicit request to speak with a person.
- Frustration, a complaint, or a repeated question.
- A third attempt at understanding that failed.
- Price, commitment, law, medical treatment, or a complaint.
- Operating hours and exceptions.
- The target team for each type of inquiry.
- The summary the representative receives.
- The message the customer receives after the transfer.
6. Permitted actions
- Information the bot is allowed to read.
- Actions it is allowed to perform without approval.
- Actions that require human approval.
- Required fields for each action.
- The method of customer verification.
- Handling a fault or system availability.
- Success message and failure message.
7. Channels
- WhatsApp, website, Instagram, or another channel.
- The difference in message length and structure.
- Information that may be requested on each channel.
- A path to move to a more secure channel.
- What happens in a conversation that was cut off and resumed.
8. Metrics
- Definition of independent resolution.
- Definition of transfer to a representative.
- Definition of response time.
- Definition of conversation cost.
- The data source for each metric.
- The frequency of the check.
- The person who decides on a change.
9. Acceptance tests
- A question whose answer exists in the approved source.
- A question with no answer in the sources.
- An ambiguous phrasing with two possible intentions.
- A request to speak with a person.
- Three consecutive misunderstandings.
- A change, cancellation, or sensitive action.
- An external system that is unavailable.
- A conversation outside operating hours.
- A customer returning after a pause.
10. Maintenance and responsibility
- Who updates knowledge.
- Who approves a change in an answer.
- Who reviews transferred conversations.
- Who receives an exceptions report.
- How a change is documented.
- What is exported from the system if the engagement ends.
A full contract is not a one-time document. A change in the price list, a new form, or a new appointment process requires reviewing the relevant sections.
What it costs and how long it takes — a realistic timeline for an Israeli business
The cost of a chatbot is made up of setup, integrations, content, maintenance, and conversations with model or channel providers. A quote without a breakdown of responsibility and updates therefore does not allow a real comparison.
A business with a fixed menu can start with a short requirements document, building flows, and tests. A question-and-answer bot requires cleaning sources, approving answers, and an update process. An AI agent also requires connections to systems, permissions, exception testing, and monitoring after launch.
A cleaning company that receives inquiries through WhatsApp needs to ask who updates service areas, who checks unusual requests, and who handles a conversation the bot did not close. These are not side details. They are part of the cost and the time.
Ask to break the quote down into:
- Requirements document and planning.
- Building scripts and knowledge sources.
- System integrations.
- Acceptance tests.
- Controlled launch.
- Knowledge maintenance.
- Conversation monitoring and exception fixes.
- Channel and model costs, if any.
A promise of low cost sometimes refers only to the software subscription. It does not include the time of the employee who fixes answers, or the price of a wrong action. Compare the entire operating period, not just launch day.
How to check a provider without falling for a pretty demo
A good provider will also show you a conversation that failed, not just a satisfied customer who received a perfect answer. Ask to test the bot's contract against scenarios from your own work.
Ask:
- From which sources does the system actually answer?
- Who updates the sources and what is the process?
- What does the bot do when there is no answer?
- What triggers a transfer of the conversation to a representative?
- What context does the representative receive?
- Which actions require approval?
- How are permissions and secure access tested?
- Is there a full activity log: who, what, when, and from which address?
- How do you export the customer's data if the engagement ends?
- Who is responsible for reviewing conversations after launch?
Ask the provider to show an answer to a question outside the knowledge, an attempt at a failed action, and a transfer in the middle of a conversation. If they send you back to the perfect demo, ask to see the control mechanism.
In a system that touches personal data, ask to understand how it supports your obligations under the Privacy Protection Law, Amendment 13, and the GDPR. This is not legal advice. Technical support does not replace a legal review of your process.
The right step is not to choose the bot that sounds the smartest. It is to choose a system you can set boundaries for, test them, and maintain them.
We at alcyone14 build and operate tailored business systems, including CRM, WhatsApp agents, automations, and dashboards, around your bot contract and process. If you want to test one process before a broad decision, automation and AI within one system is a practical starting point for a short conversation about boundaries, transfer, and metrics.
Frequently Asked Questions
How do you create a chatbot?
You start by defining the bot's contract: the purpose of the conversation, the knowledge sources, the rules for handing off to a representative, and the permitted actions. Only then do you choose a channel, connect systems, and test scenarios of a missing answer, failure, and a sensitive action.
How do you create a chat with an existing provider's bot?
If you are trying a specific provider's bot, follow the entry options it offers. If you are evaluating a solution for a business, do not settle for a single conversation; check what happens when the question is not in the database and when it is possible to reach a representative.
How can I talk to artificial intelligence?
You can use an AI-based chat service through a website or an app, and write a question in natural language. For business use, you need to add information boundaries, permissions, and handoff rules, because a general conversation is not equivalent to a chatbot connected to a process.
Do AI bots for WhatsApp exist?
Yes, AI-based bots for WhatsApp exist, but their capability depends on the knowledge sources, the connection to systems, and the handoff rules. A WhatsApp chatbot also needs to handle conversations that get cut off, short messages, and continuing a conversation after a delay.
How much does a chatbot cost for a small business?
The cost depends on the bot's tier, the number of channels, the system connections, and who maintains the knowledge. Ask for a separation between setup, channel or model costs, testing, maintenance, and human handling; otherwise the quote does not reflect the cost of operation.
