The smallest bot worth launching, and what to defer

Bots rarely fail because the technology did not work. They fail because somebody tried to build the finished thing before finding out what customers actually send, and ended up maintaining forty branches of which four are ever used.

The useful skill here is subtraction. What is the smallest version that does something real, what can wait until you have a fortnight of transcripts, and what should never be added at all. This page is about that, and about the order that avoids building things twice.

What we'll cover

• Why ambitious first versions fail
• The smallest useful version
• Writing the answers, which is most of the work
• The order that avoids rework
• Building it with CodeWords
• Launching to twenty people
• The first fortnight
• What to add in week three
• What to never add
• Signs you have scoped it wrongly
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Why ambitious first versions fail

Three mechanisms, and they compound.

You are guessing what customers ask. Every business is wrong about this in at least one significant way, and you only find out by reading real conversations.

Surface area is maintenance. Every branch is something that can be wrong when a price changes, and a large bot goes stale faster than a small one.

Nobody can tell what went wrong. When a complicated first version disappoints, there is no way to know which part failed, so the whole thing gets abandoned rather than fixed.

A small first version inverts all three. It tells you what people ask, it is cheap to keep current, and when something is wrong you can see what.

The smallest useful version

Four things. Everything else is week three or later.

An immediate acknowledgement that says who you are, that it is automated, and when a person will respond. This alone changes how the business feels to contact and requires almost nothing.

Answers to your five most-asked questions. Where, when, what you do, roughly what it costs, what to bring.

One collection flow for the enquiry you get most, gathering the three or four things you need before you can respond usefully.

A route to a person that actually works during the hours you promised.

That is a genuinely useful bot. It handles the evening enquiries, it stops the same five questions interrupting people, and it collects enough to triage in the morning. Plenty of businesses never need more.

Writing the answers, which is most of the work

The unglamorous truth: the hard part is not the tool, it is deciding what your business actually says.

Write your five answers as if to a customer, plainly, in full sentences. Where you cannot write one, you have found something worth resolving regardless: a price you have never set, a policy that varies by who is asked, a question you have been fudging.

Two rules. Say what is true rather than what is impressive, since a customer who arrives on the basis of an optimistic answer is a complaint in waiting. And write the "no" answers as carefully as the "yes" ones, because turning somebody away well is most of the value of the first version.

This step is useful even if you never build anything, which is the argument for doing it first.

The order that avoids rework

Five stages, and doing them out of order causes most of the wasted effort.

One: the escalation route. Who picks up what the bot cannot handle, in what time, during which hours. Build this before anything automated, because everything else depends on it existing.

Two: the answers, written as above.

Three: the acknowledgement message, live on its own for a few days. It is useful immediately and it tells you what people send when nothing is guiding them, which is the best information you will get.

Four: the answers, wired to the questions people actually asked in stage three rather than the ones you predicted.

Five: one collection flow, for the commonest enquiry, built against real examples.

The critical part is stage three. Businesses that skip it design flows for imagined customers, and businesses that do it are consistently surprised by at least one thing.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: the acknowledgement, the five answers, the one collection flow, and what reaches a person.
3. Authorize the connections to whatever holds your bookings or enquiries, and your WhatsApp Business Platform account.
4. Describe the exceptions before the main path: anything urgent, anything you do not handle, anybody asking for a person.
5. Resist adding anything for a fortnight, however obvious it seems, because the transcripts will change your mind about at least one of them.

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.

Launching to twenty people

Not to your whole list. Twenty customers you know, for a fortnight.

It surfaces the wording problems, the missing answers and the broken escalation at a scale where you can simply ring anybody who is confused. It also lets you ask them directly what it felt like, which is information no metric provides.

Tell them what you are doing. People are generous about a business testing something and unforgiving about one that appears to have quietly replaced its staff with software.

Then widen gradually. This is also what the platform expects, since sending limits scale with demonstrated quality and volume rather than starting high.

The first fortnight

Read every conversation. All of them. It is a couple of hours and it is the highest-value work in the whole project.

Keep a list of what it could not answer. That list is your week-three roadmap and it will not match the one you would have guessed.

Watch where people drop out, which points at a question that is badly worded or asked too early.

Check the escalations arrived at somebody who was actually available.

Note anything that felt wrong to you, since you are the person who knows how the business ought to sound.

Do not change anything for the first week. Early changes are made on two examples and frequently get reversed.

What to add in week three

Driven by the list, in rough order of how often each item appeared.

More answers, for the questions that actually came up.

A second collection flow, if a distinct second enquiry type showed itself.

Availability or booking, if the collection flow is clearly producing bookings by hand.

Reminders and confirmations, which are usually the highest-value addition and are not conversational at all.

Proactive messages, last, because they need templates, approval and more care about who receives them.

One addition at a time, with a fortnight between, so you can tell what each one did.

What to never add

Anything that gives clinical, legal or financial advice.

Anything that judges whether a situation is safe.

Automated responses to complaints. Acknowledge and escalate; nothing more.

Personality for its own sake. Jokes age badly and read terribly when somebody is annoyed.

Anything you cannot maintain. A branch that goes stale is worse than a branch that never existed, because customers act on it.

Signs you have scoped it wrongly

Four symptoms, each pointing at the same underlying problem.

Nobody can say what it does in one sentence. A bot whose description needs three clauses has usually been built from a wish list rather than from a decision.

Most branches are never reached. Look at the distribution after a month. If four paths carry ninety per cent of the traffic, the rest are maintenance you are paying for and nobody is receiving.

Changing a price means editing six places. Duplication is a scoping symptom: the same fact has been written into several flows because no one decided where it lives.

The escalation rate is not falling. A month in, if the same proportion of conversations still need a person, the bot is handling volume rather than work, and the additions so far have missed what customers actually ask.

The remedy for all four is subtraction. Removing an unused branch is free, immediate, and makes the next change easier, which is the opposite of how most teams treat their own bots.

Making it survive

Give it an owner with time allocated.

Re-read a sample of conversations monthly after the first fortnight.

Update it when the business changes, especially prices and hours.

Keep the escalation route tested, not assumed.

Remove what nobody uses, since surface area is a cost.

Limits worth knowing about

You cannot predict what customers will ask, which is why stage three exists.

More branches is not more capability, it is more maintenance.

A small bot done well beats a large one done vaguely, by a wide margin.

Some enquiries will always need a person, and the aim is to identify them quickly.

Sending limits scale gradually, so a large launch is not available even if you wanted one.

What to build first

The acknowledgement message, on its own, for a few days. Who you are, that it is automated, when a person will reply. It is one message, it improves the business immediately, and the conversations it produces tell you what to build next better than any amount of planning.

Two habits make the difference. Write your answers as plain sentences before touching any tool, because that is the real work and it is useful whatever you decide. And read every conversation for the first fortnight, since the list of things it could not answer is the only roadmap worth following.

Frequently asked questions

Why do first versions fail?

Because they are built against guesses about what customers ask, they carry more surface area than anybody maintains, and when they disappoint nobody can tell which part was wrong.

What belongs in the smallest useful version?

An immediate acknowledgement, answers to your five most-asked questions, one collection flow for the commonest enquiry, and a working route to a person.

What is the hardest part?

Writing down what your business actually says. Where you cannot write an answer plainly, you have usually found a price you never set or a policy that varies by who is asked.

What order should things be done in?

The escalation route, the answers, the acknowledgement live on its own, then the answers wired to real questions, then one collection flow. Skipping the third stage is the common mistake.

How many people should see it first?

About twenty, for a fortnight, told plainly that you are testing something. It also matches the platform, since sending limits scale with demonstrated quality rather than starting high.

What should be done in the first fortnight?

Read every conversation, keep a list of what it could not answer, watch where people drop out, check escalations arrived, and change nothing for the first week.

What gets added in week three?

Whatever the list says, most frequent first: more answers, a second flow if one showed itself, booking if it is being done by hand, then reminders, then proactive messages last.

What should never be added?

Clinical, legal or financial advice, any judgement about whether a situation is safe, automated responses to complaints, personality for its own sake, and anything you cannot maintain.

Why not build everything at once?

Because every branch is maintenance, most of the branches you would build are not the ones customers need, and a complicated failure cannot be diagnosed.

When is a bot finished?

It is not. It needs an owner, a monthly read of a sample of conversations, and updating whenever prices or hours change. A stale bot is worse than none because customers act on it.

Related reading

• Whether to build one at all
• How a bot should sound
• Buttons, lists and free text