Should you build a WhatsApp chatbot at all? The prior question
Before the setup guide: what problem it solves, what volume justifies it, what happens when it fails, and the cases where a bot is the wrong answer.
On this page
- What we'll cover
- What a bot is genuinely good at
- What it does not solve
- The volume question
- The costs that are not the subscription
- Building it with CodeWords
- What has to be true for it to work
- When the answer is no
- The cheaper thing to try first
- How you will know it worked
- Who has to be involved
- Making it survive
- Limits worth knowing about
- What to do first
- Frequently asked questions
- Related reading
Every guide to building a WhatsApp chatbot starts at the setup screen. That is the second question. The first is whether a bot is the right response to the problem you have, and a meaningful share of the projects that get abandoned six weeks in failed at that point rather than at any technical one.
This page is the decision before the build. What a bot actually solves, what it costs beyond the subscription, the conditions that make one work, and the situations where the honest recommendation is to do something else.
What we'll cover
- What a bot is genuinely good at
- What it does not solve
- The volume question
- The costs that are not the subscription
- Building it with CodeWords
- What has to be true for it to work
- When the answer is no
- The cheaper thing to try first
- How you will know it worked
- Who has to be involved
- Making it survive
- Limits worth knowing about
- What to do first
- Frequently asked questions
What a bot is genuinely good at
Four things, and they are narrower than the marketing suggests.
Answering the same question. Where you are, when you open, what you charge for a standard job, what to bring. A fixed set of answers delivered consistently.
Collecting structured information. The six things you need before you can quote, gathered without a phone call, at whatever hour the customer is free.
Being available when you are not. Evenings, weekends, and the hours your hands are full. This is frequently the largest single benefit and it has nothing to do with intelligence.
Firing messages off a trigger. Reminders, confirmations, status changes. Strictly speaking not a bot at all, and often the part that pays for the project.
Notice what those have in common: the answer is knowable in advance, or the task is collection rather than judgement. That is the boundary.
What it does not solve
A product or service problem. Customers who are unhappy with the work will be unhappy faster.
Not enough demand. A bot organises enquiries. It does not create them.
Not enough capacity. If you cannot serve the customers you have, capturing more produces more people to disappoint.
A pricing problem. Faster quoting reveals underpricing sooner; it does not fix it.
Bad processes. Automating a confused process produces confusion at higher speed, and it makes the confusion harder to see because it is now machine-generated.
That last one is the most common. A great many bot projects are an attempt to paper over something upstream, and they fail because the bot inherits whatever the process was.
The volume question
There is a floor below which this is not worth doing, and it is about repetition rather than size.
Count how many times a week the same question is asked. Count how many enquiries arrive outside the hours somebody answers. Count how many messages it takes to book a typical job.
If the same six questions arrive twenty times a week, a bot pays for itself quickly. If you get four enquiries a month, each one different, the honest answer is that answering them yourself is both better and cheaper.
The other threshold is consistency. A business where every enquiry genuinely differs has little for an automated flow to grip. One where eight in ten follow a pattern has a great deal.
The costs that are not the subscription
Worth counting properly before deciding.
Deciding what it should say. Usually the largest cost, and it is your time rather than anybody's software. Writing down what your business actually does, plainly, takes longer than people expect and is useful regardless.
Message costs. Priced per message on the platform, varying by category and market, which matters at volume.
Maintenance. Prices change, hours change, an integration breaks. Something has to notice.
The failure cases. Somebody has to handle what the bot cannot, and that route has to actually exist.
The reputational cost of doing it badly. A bot that mishandles a distressed or angry customer costs more than it saved that month.
None of these are arguments against. They are the reason the decision should be made deliberately rather than by switching something on.
Building it with CodeWords
CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.
- Open CodeWords and start a new automation.
- Describe what should happen in plain language to Cody, the automation builder: the questions you want answered automatically, what you need collected, and what has to reach a person.
- Authorize the connections to whatever you already use for bookings or records, and your WhatsApp Business Platform account.
- Describe the exceptions before the happy path, since those are what determine whether the thing survives a real week.
- Start with the narrowest useful version and run it for a fortnight before adding anything.
You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
What has to be true for it to work
Five conditions. Missing one is survivable; missing three means waiting.
Your customers already message you. A channel nobody uses does not become used because you automated it.
Somebody owns it. A bot with no owner degrades within a couple of months and nobody notices until a customer complains.
A person can take over. Quickly, during the hours you promised, in the language the conversation is in.
The information it needs exists somewhere. Prices, availability, hours. If those live in one person's head, that is the project.
You are willing to read the transcripts. For the first month at least. Everything useful about improving a bot is in what customers actually said, and businesses that skip this build the same bot worse for a year.
When the answer is no
Cases where the recommendation is genuinely not to build one.
Very low volume with high variation. Four bespoke enquiries a month is a phone call.
Anything where the first response carries risk. Clinical advice, safeguarding, regulated financial guidance. Automation has a role at the edges and should not be the first responder.
Where your customers do not use the channel. Some customer bases genuinely do not, and a channel with no traffic is a cost with no benefit.
Where nobody can pick up escalations. Offering a channel you cannot staff is worse than not offering it, because you have created an expectation.
Where the underlying process is unresolved. Fix the process, then automate it. In that order, always.
The cheaper thing to try first
Frequently the right move, and it costs an evening.
Write the answers to your ten most common questions as ordinary text. Set up an automatic reply on the business app saying when you respond and what you need to know. Put your hours and location where people look. Send a reminder the day before appointments, even by hand.
Quite often that captures most of the available benefit. And where it does not, you now have the written answers, which are the expensive input to building the real thing. Nothing about this step is wasted.
How you will know it worked
Decide the measure before building, because afterwards everyone finds a number that flatters the project.
Enquiries answered outside working hours, which is usually the honest headline.
Time from enquiry to booking.
Number of repeated questions reaching a person.
Conversations that needed a human takeover, which should fall and never reach zero.
Complaints about the bot, which is the number nobody tracks and the one that matters.
Messages sent, open rates and response times describe the tool rather than the business. Avoid them.
Who has to be involved
Projects of this kind fail on people more often than on scope, and three roles have to exist even in a business of four.
Somebody who decides what it says. Usually whoever knows the prices, the policies and the awkward answers. Without them, the bot gets built on guesses and then contradicts the business.
Somebody who answers what it cannot. Named, with hours, and aware that this is part of their job rather than an interruption to it.
Somebody who owns whether it is working. Reads the transcripts, notices when an integration breaks, and has the authority to turn it off.
In a small business these can be the same person, provided it is acknowledged as a real call on their time. What does not work is the arrangement where a bot is set up by whoever was keenest and then belongs to nobody, which is how a business ends up with an automated assistant quoting a price it stopped charging eight months ago.
Making it survive
Give it an owner and time to spend on it.
Read transcripts weekly at first, monthly thereafter.
Keep the escalation route real, and test it.
Review prices and hours whenever they change in the business.
Be willing to turn it off if the measures say it is not working.
Limits worth knowing about
A bot inherits your process, including the confused parts.
It cannot create demand or capacity.
It will handle the unusual cases badly unless somebody is watching for them.
Platform rules and pricing change, so this is a thing you maintain rather than finish.
Doing it badly is worse than not doing it, particularly for distressed or angry customers.
What to do first
Spend an hour counting. How many times a week the same questions arrive, how many enquiries land outside your hours, how many messages a typical booking takes. Those three numbers decide whether to build anything, and almost nobody collects them before starting.
Two habits make the difference. Write the answers down before building anything, since that is the expensive part and it is useful even if you never automate. And decide the measure in advance, because a project with no agreed measure gets judged on whether it feels impressive, which is how businesses end up maintaining something that never helped.
Frequently asked questions
What is a WhatsApp bot actually good at?
Answering questions with fixed answers, collecting structured information, being available outside your hours, and firing messages off a trigger. All four depend on the answer being knowable in advance.
What will a bot not fix?
A product problem, insufficient demand, insufficient capacity, underpricing, or a confused process. Automating the last one produces confusion faster and makes it harder to see.
How much volume justifies building one?
It is about repetition rather than size. The same six questions twenty times a week pays quickly; four bespoke enquiries a month does not.
What does it cost beyond the subscription?
Your time deciding what it should say, per-message platform costs, maintenance when prices or integrations change, staffing the failure cases, and the reputational cost of handling a difficult customer badly.
What has to be true before building?
Your customers already message you, somebody owns it, a person can take over quickly, the information it needs exists outside one person's head, and you will read the transcripts.
When should I not build one?
Low volume with high variation, anything where the first response carries real risk, a customer base that does not use the channel, no staffed escalation, or an unresolved underlying process.
Is there a cheaper thing to try first?
Yes. Write your ten most common answers as text, set an automatic reply stating your hours and what you need, and send reminders by hand. It often captures most of the benefit and produces the expensive input for later.
What should I measure?
Enquiries answered outside working hours, time from enquiry to booking, repeated questions still reaching a person, human takeovers, and complaints about the bot. Not messages sent or open rates.
Why do bot projects get abandoned?
Usually because the decision was never made properly: no owner, no measure, an unresolved process underneath, or an escalation route that did not exist when it was needed.
Should the escalation route be built first?
Yes. A channel you cannot staff creates an expectation you will fail, and that is worse than never offering it.