Guide 03
The technical part of putting a chatbot on a website is a script tag and ten minutes. Everything that determines whether it works happens before and after that: deciding what it is for, writing how it talks, giving it something true to say, and fixing it once real people start using it. This is that whole sequence, in the order it actually goes.
The most consistent predictor of a bad chatbot is that nobody ever wrote down what it was for. It gets built to "help visitors", which is not a specification, and it ends up attempting support answers, lead capture, booking and product guidance simultaneously. Each of those wants a different conversation shape, a different tone and a different measure of success, so the result is a thing that does four jobs at roughly forty percent each.
Pick one. Not forever, just first. Three questions settle it quickly:
Whichever you pick, there is a full treatment of it: AI customer support if the job is answering, and lead capture and qualification if the job is turning visitors into leads.
Write the answer as a single sentence and keep it visible while you build. "This chatbot answers questions about our hours, services and pricing, and takes a phone number from anyone who wants a quote." Every later decision about what to add gets checked against that sentence, and most of the additions that would have degraded it get rejected in five seconds.
If you would rather see the whole thing laid out end to end before choosing, the overview of what a website chatbot is and does is the wider view, and the small business version assumes nobody has a dedicated person for any of this.
People building their first chatbot spend their time on configuration and almost none on the writing, which is backwards. Nobody has ever left a site because the widget was the wrong shade. They leave because the thing talked like a form with a personality bolted on.
A few things matter far more than the rest.
A useful exercise before you write anything: record yourself, or a member of staff, actually answering the ten most common questions out loud. Transcribe it. That transcript is a better first draft of your chatbot's voice than anything you will produce by typing into a config screen, because it already contains 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 what it knows, and what it knows is whatever you gave it. This is the step most often rushed, usually by pointing the thing at the website and calling it done.
Pointing it at the site is a reasonable start and a poor finish. Your website is marketing copy: it is written to persuade, it is frequently vague on exactly the specifics customers ask about, and it is often out of date in the places nobody thinks to check. A bot trained on marketing copy answers like marketing copy, which is precisely what a visitor asking a direct question does not want.
What actually makes a chatbot good is the unglamorous material:
Curating this properly is a subject of its own, and the knowledge and measurement guide goes considerably further into it than is useful here.
Then curate rather than dump. Feeding a chatbot every document you own produces confident answers built from a decommissioned policy PDF and a 2019 price list. Less material that is all current beats more material that is half stale, and the failure mode of stale knowledge is not silence, it is a wrong answer delivered fluently.
Two ongoing habits keep this from rotting. First, whenever a price, a policy or an offering changes, the knowledge source changes in the same sitting, not on a list for later. Second, once a quarter, read what the bot has been telling people about your five most commercially important questions. That check takes fifteen minutes and catches almost everything.
Almost every chatbot is tested by the person who built it, asking the questions they built it to answer, which proves nothing except that the happy path exists. Real testing takes an hour and looks different.
One rule worth adopting: do not launch until the bot handles your top ten questions correctly. Not most of them. All ten. Those ten are the majority of what it will ever be asked, and getting them right is the difference between a tool people use and one they learn to ignore in the first week.
There is no reason to turn a chatbot on for everybody at once. A soft launch costs nothing and catches the things testing did not.
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 single conversation, and fix what you find. Conversation volume in week one is small enough to read exhaustively, and that reading is worth more than any dashboard you will look at later.
Before you widen it, make sure three operational things are settled, because they are what actually sinks otherwise good deployments. Somebody by name owns the leads or escalations. There is a stated response time. And there is a route for a visitor to reach a person that does not depend on the bot recognizing that they want one.
The mechanical part of getting it onto the page is short: adding a chatbot to an existing site covers the general case, and the Alma quick start is the specific one.
Integration is where chatbot projects acquire scope they did not need. The list of things you could connect is long, and almost none of it changes the outcome. Two connections do most of the work, and both exist for the same reason: to put the result somewhere a person already looks.
The first is wherever leads live. For a small business that is often an inbox, sometimes a spreadsheet, occasionally a CRM. The right answer is whichever one somebody opens every morning without being reminded. A brand new dashboard built specifically for chat leads is the wrong answer even when it is the nicest one, because it gets checked enthusiastically for two weeks and then does not.
The second is the calendar, if booking is part of the job. Letting somebody pick a slot inside the conversation removes the largest single drop-off in any appointment flow, which is the handoff to a separate booking page. If you connect one thing beyond email, connect this.
Everything else can wait, and most of it should. Analytics platforms, ticket systems, inventory lookups and payment flows all have a case, and every one of them is a thing that can break quietly between you and a customer. Add them when there is a specific problem they solve, not as part of the initial build, and add them one at a time so you know which one broke.
One test before any integration goes live: send a real lead through it, end to end, and confirm a human received it. Not a test payload. An actual conversation you have yourself, from the public site, with your own phone number in it. This catches the failures that matter, and it is skipped almost universally.
For the CRM side in particular, connecting a chatbot to a CRM without creating a second inbox goes through what to sync and what to deliberately leave alone.
Chatbot projects are usually resourced as builds and then abandoned as products. The build gets attention for two weeks and then the thing runs unattended for a year, slowly drifting away from the business it represents.
What actually degrades:
Thirty minutes a month prevents nearly all of it. Read twenty conversations chosen at random, not the good ones. List every question that got a poor answer. Fix the top three. Confirm the handoff still lands somewhere a person looks. That is the entire maintenance routine, and businesses that do it end up with a chatbot that is better in month six than it was at launch, which is not the normal trajectory.
If other people will be running this after you set it up, getting a team onto a chatbot they did not build is the part of month two that is about 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 shape of a good support flow or a good qualification flow is close to universal, and it has already been worked out many times.
Which is the argument for starting from a prebuilt flow rather than an empty canvas. Not because it saves the hour of setup, but because it front-loads decisions you would otherwise make badly on your first attempt: where the contact question sits, when to stop asking, what the fallback says, which cases hand off. You then spend your effort on the parts that genuinely are yours, which are the knowledge and the voice.
The one caution is that a template you never edit is obvious to visitors. Change the opener, replace the example answers with your real ones, and cut the questions that do not apply to you. A template is a starting shape, not a finished product, and the businesses that get the most out of one treat it as the first draft it is.
An afternoon for a first working version, if you already know what job it does and have your top questions written down. A few weeks of reading real transcripts to make it genuinely good. Most of the elapsed time in these projects is deciding what the thing is for.
No, and code would be the wrong focus anyway. Scope, conversation writing and knowledge curation are the hard parts, and none of them are programming problems. Code only enters when an internal system needs a custom connection.
Everywhere, behaving differently by page. Prompt sooner on pricing and service pages, quieter or not at all on blog posts. Page-aware openers beat both a single site-wide greeting and a bot confined to one page.
With fifty real messages from your actual inbox, graded correct, wrong or missing. Then somebody who did not build it, trying to break it. Testing only the intended path is how bots ship confidently wrong.
Scope. A bot doing support, lead capture, booking and recommendations at once is mediocre at all four. Pick the job that matters this quarter, do it properly, add the second later.
Skip the blank page
The templates cover the common shapes by industry. The knowledge and the voice are the parts worth your time.