Introduction

A dental practice bot that told a patient their appointment was Thursday at ten past three when it was Tuesday — an invented time, stated with complete confidence, one of eleven similar inventions over three weeks that nobody caught because nobody was reading; and a plumbing company bot at eleven on a Sunday night cycling a customer with water coming through a ceiling through FAQ options with no route to a human anywhere in it.

The appointment that did not exist

A dental practice wanted a website assistant. Opening hours, what treatments cost, where to park, whether they were taking new patients — the same eight questions the reception team answered forty times a day.

Rafi built it in a fortnight. It worked. Enquiries out of hours started being captured instead of lost, and the practice manager said the phone was noticeably quieter on Monday mornings.

Three weeks after launch she read a transcript, out of curiosity, on a slow afternoon.

A patient had asked the bot when their next appointment was. The bot had told them: Thursday at ten past three. Warmly, in the practice's tone, with a note about arriving five minutes early.

The bot had no access to the appointment system. It had never had any. It had generated that answer from a page on the website about typical appointment times, and it had produced a day and a time because the question asked for a day and a time.

The patient did not come on Tuesday, which is when their appointment actually was.

She kept reading. It had done something similar eleven times in three weeks — invented an availability, guessed at a price for a treatment the practice does not offer, and told somebody a dentist worked there who had left in 2023.

Nothing had failed. No error appeared anywhere. The bot was working exactly as it had been built, and what it had been built to do was answer questions — including the ones it had no way of answering.

That is the defining fact of this trade. A search box that does not know something returns nothing. A contact form does not reply at all. A language-model-backed assistant generates a plausible answer from adjacent material, in the business's own voice, at two in the morning, to a real person who has no reason to doubt it. The failure mode is invention, not silence — and the more fluent the bot is, the more convincing the wrong answer.

Eleven o'clock on a Sunday

The second story is simpler and more common.

A plumbing company. A bot on the website, handling the usual enquiries. A customer, at eleven o'clock on a Sunday night, with water coming through a ceiling.

They typed that. The bot offered them a menu: general enquiry, request a quote, book a service. They typed it again, more urgently. The bot suggested they might find the answer in the frequently asked questions. They asked to speak to somebody. The bot said the team would be happy to help and asked whether they would like to leave their details.

There was no route to a human, because the handoff had been configured for business hours and nobody had specified what should happen outside them. There had been no conversation about it at all. It had not come up.

The customer went to a competitor, and then wrote a review about the experience — not about the plumbing, about the bot.

A bot with no working handoff is worse than no bot, because without it that customer would have found the emergency number on the contact page. The bot did not fail to help. It absorbed a person who needed help and returned them to the street.

What this book is about

This is a manual for installing website assistants, customer-service bots, FAQ systems and lead-capture chatbots for small organisations, alongside a job.

It covers conversation design, knowledge bases, lead qualification, human handoff, analytics, testing, integrations and ongoing improvement. But the reason those two stories open it is that platform skill is not what decides whether this works. Four structural facts do, and most chatbot advice mentions none of them.

The four rules

Rule one — the bot speaks in the client's name, unsupervised.

Every message it sends is the business speaking. There is no draft stage, no approval, and no witness. It answers at three in the morning to somebody who will never speak to anybody else at that company. And it does so consistently, which is worse rather than better — a human who gives a wrong answer gives it once, and a bot gives it to everybody who asks that question until somebody notices.

Rule two — it will confidently answer what it does not know.

The dental practice's bot did not malfunction. Asked a question it had no source for, it produced a plausible answer from adjacent material, in the right tone, with appropriate detail. Fluency is what makes it dangerous: a hesitant wrong answer gets questioned, and a confident one gets acted on. Which means the knowledge base is not a convenience — it is the containment — and the refusal behaviour is not an afterthought but a designed feature.

Rule three — the handoff is the product, and nobody scopes it.

Everybody buys the bot. What determines whether it works is what happens when it cannot help: whether there is a route to a human, to whom, during what hours, carrying what context, and at eleven o'clock on a Sunday. That question is not in any brief. It is not in most quotes. And it is the difference between a bot that helps and a bot that traps.

Rule four — only the failures are visible.

Nobody screenshots a conversation that went well. Nobody forwards a transcript where the bot answered the opening-hours question correctly for the four hundredth time. What gets forwarded is the stupid one, the rude one, the one where it invented an appointment — and that transcript becomes the client's view of the entire system. The successes are invisible and the failures are shareable, which makes the arithmetic of your reputation permanently asymmetric.

And the interaction is the whole risk. Rule two produces the wrong answers. Rule one means they are said in the client's name, to the public, at scale. Rule three means the people it fails have nowhere to go. And rule four means the one that gets seen is the worst one. That is why transcript review, rather than configuration, is the actual work of this trade.

The numbers this book is built on

The economic unit is revenue per bot under support — what an installation returns across a year of transcript review, knowledge base corrections, new questions, integrations and improvement work.

The leading indicator is hours per bot-month, tracked as a curve. It should fall after the first months as the knowledge base fills the gaps that real conversations expose, then flatten.

The master variable is the grounded answer rate — the share of answered questions where the answer came from an approved source rather than being generated from adjacent material. It is rule two expressed as a number. It decides whether the client can trust the thing, whether the transcript that gets forwarded is a good one, and whether you are exposed. And it is almost entirely within your control, through the knowledge base and the designed refusal.

And the risk indicator is the count of supported bots with no transcript review in the last week. Target zero. Because rule two means the failure is invisible unless somebody reads them, rule four means the client will eventually read one, and the dental practice's eleven invented answers sat there for three weeks with nobody looking.

How to use this book

Read Part One in order. Chapters 5 to 8 are the four rules in full, and everything afterwards depends on them.

Everything else can be read as needed. Part Two sets the business up. Part Three is the work — conversation design, knowledge bases, qualification, handoff, integrations, testing and improvement. Part Four is the money and the records. Part Five is the year, the procedures, the numbers and the plans.

There are sixty-eight resources at the back and one hundred and forty-eight AI prompts, four per chapter. The ⚠ symbol marks a risk, a load-bearing constraint, or a clause in a prompt you should not delete when you adapt it.

Two things to do before anything else. Read your own employment contract, including any IP and conflict clauses. And take Chapter 15 and Resource 18 to somebody qualified where you are — liability for what the bot says, customer conversations as personal data, whether customers must be told they are talking to a bot, and accessibility — before you accept a client rather than during your first year.

And one thing to establish on every engagement, before anything is built: who answers when the bot cannot, and what happens at eleven o'clock on a Sunday. If there is no answer, there is no launch.

©2026 James Henderson / https://localhandyman.work

Chapter 1 — What AI Chatbot Installation Actually Is

Putting the widget on the page takes an afternoon; the trade is everything that decides whether what it says is true.

1.1 The job is not installing the chatbot

Installing is perhaps a sixth of it, and it is the sixth people picture.

The rest is finding out what customers actually ask, assembling answers that are true and approved, deciding what the bot must never attempt, arranging what happens when it cannot help, testing it by trying to make it lie, and then reading transcripts every week for as long as it exists.

The distinguishing feature of this trade is that the work continues after launch and looks nothing like the work before it. Building is configuration. Supporting is reading — and the reading is where the failures are found.

⚠ If you will not read transcripts, you cannot do this safely. There is no monitoring that substitutes, because the failures do not produce errors. Chapter 8.1.

1.2 What you are actually selling

Not a chatbot.

You are selling correct answers, in the client's name, with a route to a human when there is not one — and somebody watching. Four things: that the answers are true, that they are approved, that failure has an exit, and that somebody is reading.

Clients buy the first two implicitly and assume they come with the software. They have not thought about the third at all. And they do not know the fourth exists. Chapter 4.4.

⚠ Sell the four, priced separately, from the first conversation. A bot sold as an installation is a bot nobody reads, which is the dental practice's eleven invented answers. Chapter 7.7.

1.3 Why "add a chatbot" is the wrong unit

The phrase hides an enormous amount.

"Add a chatbot" can mean eight questions, a page of answers everybody agrees on, and a contact form at the end — which is an evening or two. It can mean the same thing where the answers depend on stock, prices change weekly, the questions include ones with financial consequences, half the knowledge is in one person's head, and there is nobody available at weekends — which is a month, most of it not building.

The unit that predicts effort is not the bot. It is how much of the answer set exists in writing, how many questions carry consequences, and whether there is anybody to hand off to. Chapter 11.3.

⚠ When somebody says "just a simple FAQ bot", the question to ask is where the answers currently live. The response tells you the price. Chapter 11.4.

1.4 The four rules, in brief

Rule one — the bot speaks in the client's name, unsupervised. Every message is the business speaking, with no draft stage, no approval and no witness. Chapter 5.

Rule two — it will confidently answer what it does not know. The failure mode is invention rather than silence, and fluency makes it worse. Chapter 8.

Rule three — the handoff is the product, and nobody scopes it. What happens when the bot cannot help is not in any brief. Chapter 6.

Rule four — only the failures are visible. Nobody forwards a good transcript. Chapter 7.

And the interaction is the risk. Two produces the wrong answers, one puts them in the client's name at scale, three leaves the people it fails with nowhere to go, and four means the one that gets seen is the worst one.

1.5 What makes this different from other web work

Worth stating plainly.

In most web work, a failure produces an error. Here it produces a fluent sentence, and nothing anywhere records that anything went wrong. Chapter 8.1.

In most web work, the thing you built is used by the client. Here it is used by the client's customers, who did not choose it and cannot complain to you.

And in most web work, launch is the end of the intensive phase. Here it is the start, because until real people ask real questions you do not know what the bot will be asked or what it will say. Chapter 25.5.

⚠ Budget the first fortnight after launch as build time, because that is when the work actually happens. Chapter 19.8.

1.6 Who is realistically good at this

Not the fastest builder.

Somebody who will read two hundred transcripts and not skim. The failures are in the boring ones. Chapter 7.7.

Somebody who thinks about the worst reader — the frustrated one, the one in a hurry, the one who will take a sentence literally. Chapter 5.8.

Somebody who will tell a client that the bot said something untrue on Tuesday, in the first message, before being asked.

And somebody who will refuse to launch without a working handoff, when the client is impatient and the date is Friday. Chapter 9.5.

⚠ Temperamentally, the trait that matters most is discomfort with a plausible answer. If a fluent sentence satisfies you, this trade will punish you. Chapter 8.2.

1.7 What it costs you in a normal week

Build blocks. Evenings and weekend mornings — conversation design, knowledge base work, configuration.

Review windows. Reading transcripts, weekly, per bot. Short, but they cannot be skipped and they cannot be batched into one session a month without the point being lost. Chapter 33.2.

And obligation load — the standing awareness that every supported bot is talking to the public right now, and that nobody but you is checking what it says. Chapter 33.1.

⚠ The third is unusually heavy in this trade, because the thing you are responsible for is active and unsupervised twenty-four hours a day. Chapter 5.4.

1.8 The skill that actually decides your margin

Not platform fluency.

It is knowing what the bot must not attempt, and building the refusal deliberately — because every question it declines correctly is a question that cannot become an invented answer. Chapter 8.6.

And that compounds into the grounded answer rate, which is this book's master variable, because a bot that answers only from approved sources is one you can support cheaply and one whose worst transcript is survivable. Chapter 35.4.

⚠ A narrow bot that refuses well is worth more than a broad bot that guesses, and it is also far cheaper to support. That is the whole commercial argument of this trade. Chapter 21.1.

1.9 What this book assumes

That you have a job and a few evenings. That you can learn one platform properly. That you have very little to spend beyond a subscription and a domain.

That you have not yet had a client read a transcript where the bot said something untrue, which is where everything changes.

And that nothing here names a platform, a vendor, a model, a plan or a price — because all of them change, and a specific quoted from memory is exactly what this trade punishes.

1.10 Chapter summary

Installing is a sixth of it; the rest is finding the real questions, assembling true and approved answers, deciding what the bot must never attempt, arranging the handoff, testing adversarially and reading transcripts forever. You are selling correct answers in the client's name with a route to a human and somebody watching, and clients buy the first two implicitly. "Add a chatbot" ranges from an evening to a month, and the predictor is where the answers currently live. It differs from other web work because a failure produces a fluent sentence rather than an error, and because launch is the start of the intensive phase. The people who do well read the boring transcripts and are uncomfortable with plausible answers. And margin comes from knowing what the bot must not attempt.

AI prompts for this chapter

Prompt 1 — Separating the four things being bought

Here is a client enquiry about adding a chatbot: [PASTE]. Separate what they are asking for into four things — answers that are true, answers that are approved by them, a working route to a human when the bot cannot help, and somebody reading transcripts afterwards. ⚠ Do not estimate hours or cost. ⚠ Do not name any chatbot platform, vendor or model. ⚠ Identify which of the four the enquiry does not mention at all, and turn each into a question for me to ask.

Prompt 2 — Unpacking "just a simple FAQ bot"

Here is how a client described what they want: [PASTE]. List every ambiguity that could change the effort by more than double — where the answers currently live, how many questions carry financial or contractual consequences, whether prices or availability change, whether anything must be read from a live system, who is available to take a handoff and during what hours, and what happens outside those hours. ⚠ Do not resolve any ambiguity by assuming the common case. ⚠ Do not produce a conversation design. ⚠ Output questions only, ordered by how much the answer changes the work.

Prompt 3 — Self-assessment against the four rules

Here is my background and available time: [PASTE]. Ask me the questions that would establish whether I am suited to a trade where the thing I build speaks in a client's name to the public unsupervised, invents plausible answers when it lacks a source, fails people who then have nowhere to go, and is judged on its worst transcript. ⚠ Do not reassure me. ⚠ Do not treat platform fluency as the main variable. ⚠ Include willingness to read two hundred transcripts without skimming as an explicit question.

Prompt 4 — Counting my three kinds of time

Here is my week: [PASTE]. Separate it into build blocks, weekly transcript review windows per supported bot, and background obligation load. ⚠ Treat transcript review as weekly per bot and not batchable into one monthly session, and say why. ⚠ Count obligation load as consumed capacity even in quiet weeks, on the basis that every supported bot is talking to the public continuously. ⚠ State how many supported bots this week could realistically carry.

⚠ AI checkpoint for this chapter

One — did it name a platform, vendor, model or price? All of those change, and a stale specific is what this trade punishes. Chapter 37.4.

Two — did it estimate effort from a description? The predictor is where the answers currently live and whether there is anybody to hand off to — neither appears in a first email.

Three — did it treat transcript review as optional or monthly? The failures do not produce errors, so reading is the only detection that exists, and it is weekly. Chapter 7.7.

Four — did it treat launch as the end of the work? Until real people ask real questions you do not know what the bot will say. Chapter 25.5.

Do This Now

1. Write down, in one sentence, what you are selling — and check it includes the handoff and the reading.

2. Count your three kinds of time, with transcript review as a weekly per-bot commitment.

3. Read your employment contract, including the IP and conflict clauses, this week.

4. Decide now that you will not launch a bot without a working handoff.

5. Complete Resource 1, the ten-question self-assessment, and Resource 3, the four-rules reference.

©2026 James Henderson / https://localhandyman.work