Guide 03
The technical part of putting a chatbot on a website is adding one short piece of code (a script tag) to your pages, which takes ten minutes. Everything that decides whether it works happens before and after that step: deciding what the chatbot is for, writing how it talks, giving it accurate information, and fixing it once real people start using it. This guide covers that whole sequence in the order it usually happens.
The most common sign of a bad chatbot is that nobody ever wrote down what it was for. It gets built to "help visitors", which is not a clear goal, and ends up trying to answer support questions, capture leads (collect contact details from likely customers), take bookings and recommend products all at once. Each job needs a different kind of conversation, tone and measure of success, so the result does each of the four roughly forty percent as well as it could.
Choose one job to start with. You can add others later. Three questions will help you decide:
Whichever you choose, there is a full guide to it: AI customer support if the job is answering, and lead capture and qualification if the job is turning visitors into leads.
Write your answer as a single sentence and keep it in front of you while you build. For example: "This chatbot answers questions about our hours, services and pricing, and takes a phone number from anyone who wants a quote." Check every later addition against that sentence, and most of the ones that would make the bot worse can be ruled out in five seconds.
To see the whole subject from start to finish before choosing, the overview of what a website chatbot is and does gives the wider view, and the small business version assumes nobody on your team is dedicated to this work.
People building their first chatbot often spend most of their time on settings and very little on the writing, which is the wrong way around. Visitors do not leave a site because the widget (the small chat window that appears on the page) is the wrong color. They leave because the chatbot talks like a form with a forced personality added on top.
A few things matter far more than the rest.
Before you write anything, record yourself or a member of staff answering the ten most common questions out loud, then type up the recording. That written version is a better first draft of your chatbot's voice than anything you will produce by typing into a settings screen, because it already uses the phrasing your customers are used to hearing.
Voice is worth more attention than it usually gets, and writing a chatbot that sounds like your business covers how to get it from your own material rather than from a personality setting.
A chatbot is only as good as the information you give it. This is the step people most often rush, usually by copying in the text of their website and stopping there.
Your website text is a reasonable place to start, but it is marketing copy. It is written to persuade, it is often vague about the exact details customers ask about, and it is often out of date in places nobody thinks to check. A bot that answers from marketing copy sounds like marketing copy, which is not what a visitor asking a direct question wants.
What actually makes a chatbot good is plain, practical material:
Choosing and organizing this material is a subject of its own, and the knowledge and measurement guide covers it in much more detail than this guide can.
Choose carefully rather than adding everything. Pasting in everything you have written produces confident answers based on a retired policy and a 2019 price list. A smaller amount of material that is all current works better than a larger amount that is half out of date. Outdated information does not make the bot go quiet; it makes the bot give a wrong answer that sounds convincing.
Two habits keep this information current. First, whenever a price, a policy or a service changes, update the chatbot at the same time instead of adding it to a list for later. Second, once a quarter, read what the bot has been telling people about the five questions that matter most to your sales. That check takes fifteen minutes and catches almost everything.
Almost every chatbot is tested by the person who built it, using the questions it was built to answer. That only proves the bot works when everything goes as planned. Proper testing takes an hour and looks different.
One rule is worth adopting: do not launch until the bot answers all of your top ten questions correctly, not just most of them. Those ten are the majority of what it will ever be asked, and getting them right decides whether people use the tool or learn to ignore it in the first week.
There is no reason to turn a chatbot on for every visitor at once. A soft launch, meaning a limited first release, costs nothing and catches problems that testing missed.
Start on a few pages rather than the whole site. Pick the ones where you most want the outcome you chose at the beginning: services and pricing for a lead bot, support and contact pages for a support bot. Leave it there for a week, read every conversation, and fix what you find. In the first week there are few enough conversations to read all of them, and that reading is worth more than any report you will look at later.
Before you add it to more pages, make sure three practical matters are settled, because these most often ruin an otherwise good chatbot. First, a named person is responsible for the leads and escalations, meaning the conversations passed to a person. Second, there is a stated response time. Third, visitors have a way to reach a person that does not depend on the bot recognizing that they want one.
The technical steps for adding the chatbot to your pages are brief: adding a chatbot to an existing site covers the general case, and the Alma quick start covers Alma specifically.
Connecting a chatbot to other tools, often called integration, is where projects tend to grow larger than necessary. The list of things you could connect is long, and almost none of it changes the result. Two connections provide most of the value, and both serve the same purpose: to put the result somewhere a person already looks.
The first is wherever you keep leads. For a small business that is often an email inbox, sometimes a spreadsheet, and occasionally a CRM (customer relationship management software that stores contact records). The right choice is whichever one somebody opens every morning without being reminded. A brand new dashboard built only for chat leads is the wrong choice even when it looks the best, because people check it eagerly for two weeks and then stop.
The second is your calendar, if booking is part of the job. Letting somebody choose a time inside the conversation removes the point where the most people give up during booking, which is being sent to a separate booking page. If you connect one thing beyond email, connect the calendar.
Everything else can wait, and most of it should. Analytics tools, support ticket systems, stock lookups and payment systems can each be useful, but each can also fail without warning between you and a customer. Add them when there is a specific problem they solve, not as part of the first build, and add them one at a time so you know which one caused a problem.
Run one test before any connection goes live. Send a real lead through it from start to finish and confirm that a person received it. Do not rely on sample data. Have an actual conversation yourself, on the public site, with your own phone number in it. This test catches the failures that matter, and almost everyone skips it.
For the CRM side in particular, connecting a chatbot to a CRM without creating a second inbox explains what to copy into the CRM and what to leave out on purpose.
Chatbot projects usually get attention while they are being built and very little afterward. The build gets two weeks of effort, and then the chatbot runs unattended for a year, slowly falling out of step with the business it represents.
These are the things that most often go wrong over time:
Thirty minutes a month prevents nearly all of this. Read twenty conversations chosen at random, not only the good ones. List every question that got a poor answer, and fix the three most important. Confirm that the handoff still reaches someone who checks it. That is the entire maintenance routine. Businesses that follow it end up with a chatbot that is better in month six than it was at launch, which is unusual.
If other people will manage the chatbot after you set it up, getting a team onto a chatbot they did not build covers the part of month two that concerns people rather than software.
Almost nothing about the four steps above is unique to your business. A dental practice and a plumbing company ask different third questions and have different escalation rules, but the structure of a good support flow or qualification flow, meaning the series of questions, answers and choices the bot follows, is much the same everywhere. It has already been worked out many times.
That is the reason to start from a prebuilt flow rather than a blank screen. Beyond saving an hour of setup, a template has already made decisions you might otherwise get wrong on a first attempt: where the contact question goes, when to stop asking, what the bot says when it cannot answer, and which cases go to a person. You can then spend your effort on the parts that are truly yours, which are the knowledge and the voice.
One caution: visitors can tell when a template has never been edited. Change the opening message, replace the example answers with your real ones, and remove the questions that do not apply to you. A template is a starting point, and the businesses that get the most from one treat it as a first draft.
A first working version takes an afternoon, if you already know what job the chatbot will do and have your top questions written down. Making it reliably good takes a few weeks of reading real transcripts. Most of the time in these projects goes into deciding what the chatbot is for.
No. The hard parts are deciding the chatbot's job, writing the conversation and choosing what it knows, and none of these involve programming. Code is only needed when an internal system requires a custom connection.
It can go on every page, but it should behave differently by page: sooner and more directly on pricing and service pages, and quietly or not at all on blog posts. Opening messages written for each page work better than one site-wide greeting or a bot limited to a single page.
Run fifty real messages from your inbox through it and grade each answer as correct, wrong or missing. Then ask somebody who did not build it to try to break it. Bots tested only on the questions they were designed for often launch giving wrong answers with confidence.
The most common mistake is giving the bot too many jobs. A bot that handles support, lead capture, booking and recommendations at once does all four poorly. Choose the job that matters most this quarter, do it properly, and add a second job later.
Templates
The templates cover the most common kinds of chatbot for each industry. Your time is best spent on the knowledge and the voice.