How to Plan a Business Chatbot Before Anyone Writes Code

01 · The scoping call where nobody had answers

A law firm partner booked a chatbot consult last month. He wanted AI on the homepage by Friday. When I asked what the bot should do first, he said "everything visitors need." When I asked for the ten questions prospects ask most, he forwarded a paralegal who said "it depends." When I asked when a chat should route to intake staff, he said "we will figure that out after launch." The firm had strong attorneys and a weak front door. They were about to automate confusion at scale.

That call is the split I see on every scoping conversation. My capabilities piece on business-trained chatbots covers what a well-built bot can handle after launch: FAQ coverage, qualification, after-hours capture, booking handoffs, and refusal rules. This post covers what has to exist before anyone writes code. Planning is the work owners skip because vendors sell the widget first. Skipping it is how you get a modern chat window that quotes retired pricing and routes gas leaks to a FAQ link.

Your chatbot should help a visitor get the next useful answer or action faster. It should not pretend to replace judgment, promise outcomes your counsel has not approved, or handle sensitive situations without a human path. The AI Chatbot Planning Worksheet on our resources page turns that sentence into tables you can fill in with your team. Use it before you buy Concierge, before you paste a generic embed, and before you assume your homepage is enough training data.

02 · Name one primary job and write the exclusions

Most failed chatbot projects start with a feature wish list. Answer questions, qualify leads, book calls, collect intake, route support, recommend resources, and "be available 24/7." That list is not a plan. It is seven jobs competing for one conversation thread.

Pick a primary job and make it narrow enough that a stranger could repeat it back. Examples that work in practice: answer common pre-sale questions for one core service line, qualify new leads before a human opens the thread, collect intake details before a consultation call, or route support requests to the right inbox. Pick one. If a secondary job exists, it should support the primary job without splitting the flow. A bot that qualifies and books can work. A bot that qualifies, diagnoses, and negotiates contract terms cannot.

Write what the chatbot should not do in the same session. That list is your liability shield. No custom contract negotiation. No medical or legal outcome statements. No billing disputes without verification. No pretending to be human when asked directly. No answering from stale offers or internal notes that were never meant for the public. Exclusions feel negative on paper. On a live site they prevent the angry emails that follow a confident wrong answer.

I scope Concierge builds around this single-job frame. Knowledge base planning, the question set, lead capture, and escalation logic all hang off the primary job. When an owner cannot name it in one sentence, we pause on build until they can. Clarity here saves rework later and keeps Pro and Agent tier scope honest when qualification paths branch or CRM handoffs multiply.

03 · Map visitor scenarios before you map features

Features are what vendors demo. Scenarios are what your visitors actually do at 9 PM on a Tuesday. Open the worksheet section on visitor scenarios and list the main reasons someone would open the chatbot. For each row, capture what they ask, what they mean, and the ideal next step.

A home services operator might list: wants pricing ("how much for a water heater?"), wants same-day service ("can you come today?"), has an emergency ("I smell gas"), wants to know service area ("do you cover Aurora?"), and wants to compare options ("tank vs tankless"). The ideal next steps differ. Pricing gets a starting range and a consultation invite. Same-day gets availability language from approved copy. Emergency gets an immediate human handoff or safety instruction from counsel, not a booking link. Service area gets a clear yes or no from current territory notes.

A B2B SaaS team might list: trial user stuck on integration limits, enterprise buyer asking about security review, existing customer with a billing question, and competitor comparison requests. Each scenario needs a different answer source and a different escalation threshold. Planning scenarios in a table forces your sales lead and your support lead into the same document. That alignment is worth more than another round of homepage rewrites.

Do not invent scenarios from marketing personas. Pull from call logs, form submissions, Instagram DMs, and the three paragraphs your coordinator pastes into email every Monday. Real phrasing matters because visitors type "how much" and "ballpark" and "is this gonna cost a fortune" as different doors to the same question. Your question set should recognize all three without inventing a fourth answer.

04 · Approved answers carry more weight than the model name

Vendors want you to ask which AI model powers the widget. Operators should ask which answers are approved to repeat in your name. The worksheet section on approved answers is where planning becomes concrete. Document short, signed-off responses for the questions you hear most often: what you do, who you work with, what it costs to start, how long delivery takes, how to get started, what tools you use, and whether you can help with a specific situation.

Each row needs a human needed? column. Some questions get a clean approved answer from the knowledge base. Some get a partial answer plus handoff. Some get an immediate stop and route. Pricing on a core package might be answerable with a starting range. Custom enterprise scope might be answerable only with qualification questions before a human joins. Medical candidacy, legal case merit, and investment suitability belong in the human column every time.

This is knowledge base planning in practice. Concierge at $1,497 starts here: service descriptions, pricing signals, fit and exclusion criteria, process steps, and FAQ blocks pulled from material your team already uses on calls. The model layer sits on top of that packet. Without approved answers, the model fills gaps with confidence. With approved answers, wrong responses become launch blockers you catch in QA instead of reputation events you catch in Gmail.

Keep answers short enough to read on a phone. Long policy paste reads like a bot even when the facts are right. Match the tone your best rep uses on a good day: plain, direct, no jargon unless your buyer speaks that jargon. One example answer that sounds right in the brand voice section of the worksheet becomes the reference for every other row.

05 · Lead fields and qualification rules stay paired

Lead capture is where good bots die from friction. Owners want twelve fields because the CRM has twelve fields. Visitors want one answer before they give you their email. The worksheet asks you to decide what the chatbot collects before sending a lead to your team: name, email, phone, company, website, service interest, budget range, timeline, main challenge. Mark each as required or optional and write why it matters.

Keep required fields limited. The chatbot should reduce friction, not turn a first conversation into a job application. For many service businesses, name and email plus service interest are enough to route. Phone matters when your team calls back within an hour. Budget band and timeline matter when they change which calendar link or which rep gets the alert. Company and website matter for B2B qualification. Main challenge matters when it replaces a fifteen-minute discovery preamble.

Qualification rules sit beside lead fields. Define what makes a lead a good fit, what needs review, and what is a poor fit across signals like service need, budget, timeline, industry, location, and urgency. Write a best-fit lead description and a poor-fit lead description in plain language. "Funded SaaS team on HubSpot, needs integration help, timeline under 90 days" is a good-fit sentence. "Student asking for free custom dev" is a poor-fit sentence your bot can decline gracefully with a resource link or a polite no.

Capture logic and escalation logic are one design problem. If you push every visitor into a form before they get a single answer, they close the widget. The best flows answer one real question, then ask one real question back. If the visitor matches poor-fit criteria, the bot should say so without wasting your calendar. If they match high-intent criteria, the bot should offer human handoff or booking with context attached.

06 · Write handoff triggers like you train front desk staff

Escalation is the section owners skim and operators live by. Decide when the chatbot stops and routes the conversation. Standard triggers belong on every plan: pricing or contract negotiation, complaints or urgent support issues, legal, medical, financial, or safety-sensitive questions, requests outside your services, a visitor asking for a person, and any moment the bot is not confident.

The worksheet asks for a table: trigger, where it routes, message to visitor. Fill it completely. "Route to human" is not a destination. Name the inbox, Slack channel, SMS number, or CRM task owner. Write the exact visitor-facing sentence: "I am connecting you with our intake team now. They typically respond within one business hour." or "This sounds urgent. Please call this number." Generic "someone will reach out" language trains distrust.

I map handoffs around intent and risk the same way on every Concierge build. High intent plus high risk gets immediate human path. Medium intent gets knowledge base answer plus optional capture. Low intent gets link plus optional email. Regulated environments add hard stops before the bot states an outcome. SEC-facing firms, clinics, and law offices need human review on the knowledge base and logging that lets a manager audit what the bot said when a complaint arrives.

Test handoff timing in planning, not after launch. If your team only checks the chat inbox twice a day, real-time SMS alert to the on-call owner matters more than another CRM field. If nobody owns after-hours response, the bot should set expectations honestly instead of promising instant callback. Broken handoff promises hurt more than no bot at all.

07 · Source material and brand voice need a current stamp

The worksheet section on source material lists what the chatbot can safely use: website pages, service descriptions, FAQ, pricing or package notes, intake form, brand voice guide, policies or disclaimers. Mark each source current and approved. Do not feed the bot outdated offers, private customer information, or internal Slack jokes that should never appear on a customer-facing thread.

Stale source material is a silent failure mode. You change pricing, shrink service area, or retire a package. The homepage lags by six months. A lazy import bot reads the old page and answers faster and wrong. Planning includes an update path: who owns revisions, how often you review conversation logs, and what triggers an emergency knowledge base patch. Project builds without a maintenance habit solve none of this. Retainers that keep the trained chatbot current as the offer changes solve part of it.

Brand voice is a deliberate choice. Pick a tone from the worksheet options: plain and professional, warm and conversational, direct and concise, premium and consultative, friendly and local. List words or phrases to use and words to avoid. Sales-heavy superlatives, competitor bashing, and fake urgency belong on the avoid list for most professional services firms. One example answer that sounds right becomes the calibration sample for launch QA.

Run a pre-build checklist before anyone writes code. Confirm the chatbot has one clear primary job. Confirm approved answers exist for common questions. Confirm handoff rules are documented. Confirm lead fields are limited and useful. Confirm source material is current. Confirm the team knows who reviews chatbot performance at 30 days. Confirm sensitive questions route to a person. Confirm the first version can be tested before going live. That checklist is ten minutes on paper and weeks of saved cleanup.

08 · Success measures force accountability after launch

Planning without measurement is a document that dies in a Google Drive folder. Pick three ways you will judge whether the chatbot is working. Options that matter on small business sites: more qualified inquiries, fewer repeated FAQ emails, faster lead response time, more booked calls, better intake details before calls, cleaner routing between sales and support.

Write the three measures in the worksheet before build. At 30 days, review them with real logs, not feelings. Did after-hours chats produce leads your team would have lost? Did FAQ volume in email drop? Did booked calls arrive with budget and timeline filled in? Did support chats stop landing in the sales inbox? If nobody owns that review, the bot becomes set-and-forget liability.

Launch QA belongs in the same accountability frame. Test wrong answers, edge cases, and handoff timing before the widget goes live. A post-launch fix window catches phrasing real visitors use that planning missed. Concierge includes that window because the first week of live traffic always surfaces one question nobody wrote down. Planning reduces the surprise count. It does not eliminate it.

Bring four items to a scoping call if you want speed: your top ten customer questions, your current intake form, your service descriptions, your preferred handoff destination, and one chatbot experience you liked or disliked. Half-finished worksheet beats a blank page. Completed worksheet beats three weeks of circular email.

09 · Planning is the work vendors hide inside "custom"

The public story says implementation starts when you pick a platform. The private reality says implementation starts when your team agrees on what the machine is allowed to say. Code without that agreement is a liability dispenser with a typing animation.

You can plan this yourself with the worksheet on our resources page. You can pressure-test the packet on a 15-minute fit call if you want a straight read on Concierge scope. Either way, the sequence stays the same: primary job, scenarios, approved answers, lead fields, qualification rules, handoffs, current source material, brand voice, success measures, pre-build checklist. Then build. Then QA. Then review at 30 days.

Concierge from $1,497 is built for owners who did the planning work or want help finishing it: knowledge base planning, question set, lead capture, escalation logic, launch QA, and a post-launch fix window. Pro and Agent tiers step up when paths branch and integrations multiply. The price is flat because the planning deliverables are named.

Your site already tells prospects what you sell, or it does not. A chatbot amplifies whichever is true. Have you written the approved answers your team would stake their name on before you let a machine say them at midnight?