AI Chatbot for Customer Service: Setup Checklist

An AI chatbot for customer service is a set of decisions you write down, then a widget. The decisions are the sources it may use, the tone of a reply, the topics it will answer, the topics it will refuse, whether it can see an order, who takes over, what gets logged, and what you review every week. Skip one of those and the bot will fill the gap with a fluent guess.

This is the setup checklist. The buying test, including what the bot must not invent, is in best AI chatbot for a small business. If you want the build done with you, start at the AI chatbot service. Connecting the bot to the order tool, the inbox, or the help desk is AI integration, and that connection is a separate decision from the greeting.

The source list

Write the sources before anyone turns the widget on. A source is a page or a document you are willing to have quoted to a customer this week.

Include the pages a customer already uses: services, hours, location, service area, menu or fee schedule if you publish one, shipping or visit policy, and the contact path. Each source needs an owner. If nobody owns the hours page, the bot will be the last one to hear about the holiday closure.

Exclude anything you would not hand to a stranger at the counter. That means internal notes, old menus, a quote you sent to one customer, staff scheduling, and any file with card numbers or full customer records. "Helpful" is not a reason to upload the whole shared drive.

Decide what happens when two sources disagree. The practical rule is: the page with the later update wins, and someone fixes the older page the same day. If you do not pick a rule, the bot will pick a paragraph and sound sure.

Decide how fast a change shows up. If you edit hours at 4 p.m., can the bot say the new hours by the evening rush? If the refresh is "overnight" or "when someone remembers to press sync," write that down and do not promise customers a live answer you do not have.

Keep the list short at the start. Ten accurate pages beat a crawl of the whole site, including the blog post from 2019 that mentions a service you dropped. You can add sources after the weekly review shows a question you should have been able to answer.

Tone, written as lines the bot can follow

"Friendly and professional" is not a tone. It is a wish. Write lines.

Use the business name. Use the same names for services that the website uses. If the site says "drain clearing" and the bot says "hydro jetting package," you have invented a product. Keep replies short enough to read on a phone. One fact, then the next step: a link, a phone number, or a handoff.

Say when you do not know. "I do not have that on our pages" is a complete sentence. Follow it with the form or the phone. Do not pad it with a guess so the chat feels complete.

Do not joke about the problem. A closed shop, a late order, a leak, and a billing error are not material for a quip. Do not pretend to be a named employee. If you want the chat to say it is an assistant, say that in the first reply so the handoff does not feel like a trick.

Match the seriousness of the business. A restaurant can sound like a host stand. A clinic should sound like the front desk, which means calm and brief, with no extra medical color. Read five sample replies out loud. If you would not say them at the counter, do not ship them.

Sample lines worth writing down

• "Our hours today are on the hours page. If you are looking at an older post, use that page."
• "I cannot quote a price that is not on the site. Use the contact form and a person will follow up."
• "I cannot see order status from here. I can take the order number and an email, and a person will check."
• "I can get a person. During open hours they have the thread. After close, they will read it when the office opens."

Put your real page names and hours into those lines. The point is that a new employee and the bot share them.

Topics in scope

List the questions you want the bot to finish without a person. For most local businesses the list is short and valuable.

Hours, holiday hours, and whether you are open right now if the hours page is reliable. Address, parking, and which door to use. Service area, including a clear no for towns you do not serve. The services you offer, described the way the service pages describe them. How to book, order, or ask for a quote, using the real tool. Policies you have published: cancellation, deposits, delivery radius, what is included in a standard visit. Pointing someone at a menu, a fee page, or a PDF you still stand behind.

If a question is in scope, you should be able to point at the source. "Everyone here knows that" is not a source. The bot was not in the room when everyone knew it.

A restaurant, as a worked example

A restaurant chatbot lives or dies on the menu and the clock. It may describe dishes, prices, and hours that are on the current menu page. It may share the reservation link. It may answer "do you take walk-ins" only if the site says so.

It may not invent a table at 7. If a reservation system is connected and can see covers, booking can be in scope. If it is not connected, the bot gives the link or the phone and stops. Allergen and ingredient questions are in scope only when the menu states them. Otherwise the bot says it cannot confirm from the menu and offers the restaurant directly. Guessing about a sauce is how someone gets hurt.

The pages that feed this have to be the real ones. A website that still shows last season's brunch, or a city you do not operate in, will be quoted with a straight face. The site work for that kind of business is covered under restaurant website design. Fix the menu page and the hours before you ask a bot to host.

A shop that takes orders

In scope: product questions answered from the product page, shipping windows you have published, and how to start a return if the policy page describes it. Out of scope until a system is connected: "where is my box," "change the address on the order I placed an hour ago," and "refund me now." Those need a record, not a paragraph.

Topics out of scope

Write the out of scope list as carefully as the in scope list. Out of scope does not mean the customer is wrong to ask. It means the bot is the wrong one to finish the answer.

Medical, legal, and financial advice stay out, even when your business sits beside those fields. Repeat a published service description. Do not diagnose, dose, interpret a contract, or predict a case. Complaints and refunds go to a person once the customer is asking for money back or for someone to admit a mistake. Questions about another customer's order, appointment, or bill stay out. The bot should not confirm that a person is a customer of yours.

Prices and discounts you have not published stay out. Timing promises you have not written stay out. "We can be there this afternoon" is a dispatch decision. Hiring stays out unless the jobs page is the whole answer, in which case the bot links the page and does not negotiate pay.

Safety sits out of improvisation. If the customer describes gas, flooding, a fire, a medical emergency, or a threat, the bot uses the short script you approved and notifies a person. It does not troubleshoot past that script.

Put a one line reply on each out of scope topic so the bot does not invent its own softer version. The reply names the next step. A refusal with no next step invites the customer to rephrase until they get a yes.

Order status, only with a real read

Order status is the question that tempts a bad setup. Customers ask it constantly, and a model can produce a soothing sentence with no lookup behind it. "Your order is on the way" is easy to say and expensive when it is false.

Allow order status only if the chatbot can read that order in the system you already use, and only if you check that the person asking is allowed to hear it. The check should match what your staff already do: order number plus email, order number plus phone, or a logged in account. Do not accept a name alone. Do not read the full record back. Status, the carrier step you trust, and the next action is enough.

If the system cannot be read, the bot is honest. It collects the order number and the contact, hands the thread to a person, and does not estimate. "Most orders arrive in three days" is still an estimate, and it will be wrong on the day the customer needed a fact.

The same rule covers appointments, reservations, and job status. "Your technician is 20 minutes away" requires a live board. Without the board, offer the phone number the dispatcher actually answers.

Connecting that read is integration work. It includes permissions, a test order, and a plan for when the system is down. When the system is down, the bot says it cannot see status right now and takes a message. It does not fall back to guessing because the connection failed.

Also tell the bot to refuse card numbers, full social security numbers, and passwords typed into the chat. Customers will paste them. The reply is: do not send that here, and here is the safe way to pay or to verify. Your log should not become a box of card numbers because a widget had a text field.

Human handoff with a named owner

Pick the owner by name and by hours, not by "the team." If you are still deciding whether that owner should be the only voice, or whether software should answer the repeated questions first, read AI chatbot versus live chat. During open hours, one person watches the queue and a second person covers lunch and days off. The bot's reply should match that reality. If the owner is in a job and cannot see the screen, you do not have a handoff. You have a transcript pile.

The person who receives the thread should see the messages, the page URL, the time, and any order number the customer already gave. They should not have to ask the customer to repeat the story from the first line. That repeat is why people say the bot wasted their time, even when the answer was reasonable.

Triggers to hand off, at minimum:

• The customer asked for a person.
• The topic is out of scope.
• The bot has no source.
• The customer is repeating themselves. Two tries without a resolution is enough.
• The customer is angry, or is asking for a refund, a complaint, or a manager.
• The lookup failed, or the customer failed the identity check and is pushing for details anyway.

After hours, name the next time a person reads messages. If the phone is covered and the chat is not, say that. Do not leave a chat window implying a live person at midnight if the owner starts at 8.

Measure the handoff. A thread that waited past the promise is a missed customer, the same as a ringing phone. If you cannot staff the handoff, narrow the bot's hours or narrow the topics until you can.

Logging

Log enough to review the bot, and no more than you are willing to protect.

For each thread, keep the time, the page, the customer messages, the bot replies, whether a source was used, whether a handoff happened, and whether a person later marked the reply wrong. That last flag is how the weekly review finds work. Without it, you are rereading a stream and hoping you notice.

Decide who on staff can open the log. Front desk staff who handle the handoff need it. The whole company usually does not. Decide how long you keep chats. A retention period you chose is better than a default you never read. If your trade handles health information, treat the log with the same care as other records and get the agreements your counsel says you need. This page is not legal advice.

Do not log secrets the bot should have refused. If a customer pastes a card number, the staff procedure is to remove it and to tell the customer to watch the card. The bot's refusal line exists so this is rare.

Export matters. You should be able to take the log with you if you change tools. A customer service history that lives only inside a vendor you cannot leave will shape the next contract more than the monthly price will.

The weekly review

Put 30 to 45 minutes on the calendar. The owner of the handoff can do it, or the owner of the business, but it has to be a person who can change a page or a refusal the same week.

Read every chat the bot marked unsure, and every chat a person marked wrong. Then read a sample of the confident chats. Confident and wrong is the set that hurts you, because nobody was alerted. Look for a repeated question. A repeated question is either a missing page or a missing refusal.

Sort what you find into four piles:

1. The page was wrong or stale. Fix the page. Do not "correct" the bot with a hidden note that contradicts the site. The next channel, including the phone, will still quote the page.
2. The bot answered a topic you do not want. Add the refusal and the next step.
3. The handoff fired and nobody answered in the time you promised. Fix the staffing or change the promise.
4. The bot refused something you could have answered from a page. Add the source, or write the page.

Keep a short note of what you changed. The note is how you tell, a month later, whether the same mistake came back. If it came back, the source is still wrong or the setting that lets the bot wander is still on.

Once a month, ask a harder question. Are people using the chat for something a clearer page would solve? If half the chats are "what time do you close," the hours are hard to find. Fix the page. The bot can stay, and the page will help the people who never open chat.

Launch order

Do the work in this order so you do not discover the gaps in front of customers.

1. Freeze the source list and remove anything stale.
2. Write the tone lines, the in scope list, and the out of scope list with a reply for each refusal.
3. Name the handoff owner, the backup, and the after hours promise.
4. Turn logging on, and confirm you can export a thread.
5. Collect about twenty real questions from recent calls, emails, and the front desk. Include the rude ones and the odd ones. Staff run them against the bot before customers do.
6. Fix the pages and the refusals those tests expose.
7. If order status is in the plan, test with a real order and a wrong order number. Confirm the bot does not reveal someone else's status.
8. Soft launch. One page, or after hours, or both. Read daily for the first week, then move to the weekly review.
9. Widen the sources only after the soft launch is dull.

Announce the chat when the soft launch has survived real questions, not when the widget is merely installed. A button on the homepage is easy. A correct answer on a Saturday is the launch.

If the tests in step 5 produce more wrong answers than you want to fix, stop and use the buying checks in the companion article before you add more pages. A checklist cannot rescue a bot that is allowed to invent, or a site that does not yet say what the business does.