An AI chatbot for a local business should answer verified opening hours and basic service facts itself, collect the details needed for a quote, and guide a customer towards a real booking. It should hand over uncertain prices, live availability it cannot verify, complaints, urgent issues and anything outside its knowledge sheet to a named person.
One bot can cover three jobs, but each needs a different authority. Hours come from a maintained business record. Quote enquiries need questions, not a guessed price. Booking confirmation needs a live diary or a staff member. Put those distinctions in the bot's instructions and test them before customers see it. A friendly tone cannot compensate for a false promise.
Write the one sheet the bot is allowed to know
Make a short knowledge sheet with an owner and a review date. Include regular hours, exceptions and closure dates, service area described by the business's own approved wording, services offered, services not offered, fixed prices if any, quote intake questions, booking rules, cancellation route and the human contact channel. Use a field for “last checked” beside time-sensitive entries. A bot should be able to say “I cannot confirm that from the current sheet” rather than fill a gap with a plausible answer.
For an illustrative four-person plumbing firm, the sheet could say: office enquiries answered 08:00–17:00 on working days; appointments are confirmed by staff; standard leak assessments require a contact number, problem description, access details and preferred window; no fixed price is quoted from chat. The sheet should not contain a copied customer list or private employee information. Keep the approved contact and service wording in one place so staff can correct it when hours change.
Separate stable information from live information. A stable item is “we provide domestic plumbing repairs”. A live item is “a technician can attend at 14:00 today”. If the bot has no current calendar connection, it cannot know the second. Even with a connection, it needs rules for travel time, job duration and holds. The knowledge sheet can define the process; the diary or dispatcher confirms the slot.
A filled-in exception row might read: “Public holiday hours: closed on the next listed date; reviewed by office manager on Monday; publish the updated date before Friday.” If the date field is blank, the bot must avoid saying it is open as usual. A routine weekly review is cheaper than apologising to a customer who travelled because a chatbot repeated last month's hours.
The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy nowJob one: answer hours from a dated record
Hours are usually the safest first job, but “Are you open?” can mean the office, the phone line, emergency cover or appointment availability. The bot should distinguish them. If the sheet says office 08:00–17:00 and emergency calls handled separately, a response can say which service is open and give the correct route. It should not imply that a technician is free now. If a closure or holiday is pending, the response needs a date and a source, not a generic “usually open”.
Illustrative question: “Can someone come on Saturday?” A weak bot says, “Yes, we are open Saturday.” The sheet only says the office is closed and on-call enquiries are taken. The accurate answer is, “The office is closed on Saturday. You can leave the job details through the on-call contact route; a person will confirm whether an appointment is available.” The bot has answered the practical need without inventing a visit.
Test wording that tries to combine hours with a promise: “If I arrive at 16:55, will the work be finished today?” The bot can state the office closing time and offer a contact route, but it cannot guarantee completion. Add a handover flag if the customer has an urgent leak or safety concern. If there is immediate danger, the bot should direct the user to appropriate emergency help under the firm's approved wording and prompt a person, not troubleshoot a risky situation.
Keep an hours change process: the manager edits the sheet, a second person checks the published version and the bot is tested with “today”, “tomorrow” and the exact closure date. Check every public surface that may conflict: website, booking page, business profile and voicemail. The bot must not become the only place where the new hours exist. The chatbot FAQ preparation tutorial covers a wider content inventory.
Job two: collect quote facts without pretending to estimate
For variable work, the bot should act as an intake assistant. Ask for the service needed, a short description, photographs only if the business has an approved upload route, access constraints, preferred contact method and urgency. Do not ask for unrelated sensitive details. Show the customer the summary before submission so they can correct it. Then pass it to an estimator or dispatcher who decides whether a visit or a quote is possible.
The sheet should specify which services have genuinely fixed prices. If a cleaning firm has a standard, published price for a clearly defined service, the bot may repeat it with the conditions and date. If a roof repair depends on access, materials and damage, the bot should say a person will assess the details. “Starting at” prices can mislead when the actual job never meets the minimum conditions. Do not let AI infer scope from a single photograph.
Illustrative intake: a customer says, “Pipe under the sink is leaking and the cupboard is wet.” The bot asks when the leak began, whether water is still flowing, whether the supply can be safely isolated, the property access window and a callback method. It does not advise a repair from the photo or promise a price. An internal summary reads, “Leak under sink; water still flowing; customer reports wet cupboard; callback requested before 11:00; no appointment confirmed.” A person checks urgency and responds.
A separate example shows why summary review matters. A customer writes, “The tap drips only when the washing machine runs.” An unreviewed AI summary says “washing machine leak”. That changes the job type. Show the customer the captured wording or have staff review the original message beside the summary. If details are ambiguous, keep the exact quote and ask one clarifying question. The quote-intake questions tutorial gives a sector-specific example of why the right questions matter more than fluent prose.
Set a handover threshold: any request involving immediate damage, an unusual service, a complaint about previous work or a price dispute goes to a person. The bot can collect contact details and offer the approved urgent route. It should not keep asking a long sequence of questions while water is causing damage. The fastest useful answer may be “I am passing this to the duty person now.”
Job three: guide bookings with a clear status label
Bookings need three states in customer language: requested, held and confirmed. If the bot has no live diary, it can collect a preferred window but must label it requested. If a diary supports temporary holds, define how long a hold lasts and what happens when it expires. Only a confirmed slot should trigger a confirmation message. The status should be visible in the booking system, not only in a chat transcript.
Illustrative flow: the customer asks for Thursday morning. The bot replies, “I can send Thursday morning as your preferred window. A team member will confirm the time.” It records the request ID, contact method and job summary. The dispatcher sees that the requested window is already full and offers Friday afternoon. Because the bot never said Thursday was booked, the correction is ordinary scheduling rather than a broken promise.
If the bot can read live slots, still test duplicate and stale data. Two customers may ask for the same final slot within seconds. The booking system must reserve or reject atomically; an AI message cannot create that guarantee. Ask the vendor or implementer to demonstrate a two-customer collision, a cancelled hold, a reschedule and a payment failure if payment is part of the process. Until those tests pass, keep confirmation with staff.
Another example: a customer says, “Move my visit to tomorrow and keep the same engineer.” The bot may see an open time but cannot promise the same engineer without an approved roster connection and rules. It should submit a reschedule request, cite the existing booking reference and ask a person to confirm. For a wider booking-system decision, see the AI booking system checklist.
The handover rule needs a destination and a deadline
“Talk to a human” is not a handover if no queue receives the conversation. Define the trigger, destination, information passed, expected response window and fallback when the queue is unstaffed. The customer should know what has happened: “I have passed your message to the office; this is a request, not a confirmed booking.” Avoid promising a callback time that the team cannot meet. A named role should own the queue each day.
One workable rule for the illustrative plumbing firm is: if the bot lacks an approved answer after one clarification, if the customer asks for a price outside the published list, or if a message mentions active damage, it creates a human-review ticket. The ticket contains the original text, bot summary, contact route and reason for handover. The dispatcher checks it during staffed hours; urgent cases follow the firm's separate on-call process. The bot stops generating substantive advice after escalation.
In a test, a customer writes, “You charged me for a repair that failed.” The bot should acknowledge the complaint, ask for an invoice or job reference through the approved secure route and hand the case to a person. It should not offer a refund, deny responsibility or repeat a generic troubleshooting script. Give the staff member the full original wording so the complaint is not flattened into “billing question”.
Another test starts with an inaccessible contact channel. The bot tells the customer to phone, but the number in the sheet is outdated. The handover fails even though the AI classified correctly. Test the entire path from customer message to staff receipt and customer reply. Include a case outside office hours and a case where the named owner is absent. The booking error recovery tutorial helps prepare the correction route.
A worked pilot for 100 monthly conversations
Assume the illustrative firm receives 100 website chats a month: 45 hours or service questions, 35 quote enquiries and 20 booking requests. The owner samples 30 past conversations, removes personal details and writes expected answers or handovers. The knowledge sheet contains 18 approved facts, six quote intake fields and three booking statuses. These figures are a planning example, not a benchmark for local firms.
In the first shadow test, the bot answers 12 of 15 hours questions correctly, collects complete details in 8 of 10 quote cases, and labels only 3 of 5 booking requests correctly. It invents a Saturday appointment in one case and fails to hand over an active leak in another. The owner does not launch. She updates the hours wording, adds an urgent-damage trigger, makes “requested” the default booking status and reruns the full sample, including the failures.
After revision, suppose all 30 sample cases have either a verified answer or a correct handover, and no unconfirmed booking is described as confirmed. The firm launches to a small portion of site traffic with staff reviewing every conversation daily. It records bot answer, source field, customer correction, ticket handover and time to staff response. If the bot requires staff to re-read every simple hours chat, the owner may simplify the design rather than add more AI.
The owner compares total work, not just containment. If 40 hours questions are answered but ten need corrections and the team spends an hour updating stale facts, the net effect may be small. The stronger measures are wrong promises, missed urgent handovers, complete quote briefs and confirmed booking accuracy. A single serious miss can outweigh many tidy answers, so keep a stop rule for unsafe advice and false booking confirmations.
Run the bot as a maintained service, not a launch project
Review the knowledge sheet whenever hours, services, price conditions or booking rules change. Put a date beside each edit and retest the questions that rely on it. If the business runs a seasonal schedule, set a calendar reminder before the change. Monitor conversations where the bot says it cannot answer; repeated gaps show which facts belong in the sheet and which requests should always reach staff.
Give customers a clear opening line that says they are using an AI assistant and can reach a person. Keep the contact path visible throughout the conversation. Limit the personal data collected to what is needed for the enquiry, control who on the team can see transcripts and decide how long records are kept. If the bot is linked to other systems, review each connection and the supplier's current terms before launch.
Every month, run a compact regression set: normal hours, closure date, out-of-area quote, active damage, disputed bill, double-booking attempt, cancellation and request for a person. Compare the answers with the current knowledge sheet and inspect whether the handover ticket actually arrived. If the bot cannot be kept current, restrict it to intake and staff handover. That is still useful when it gives staff a complete brief without making claims it cannot verify.
Keep a correction log that changes the source
When the bot gives a wrong answer, record the customer question, source field it used, answer sent, correct answer, customer impact and owner of the fix. Distinguish three causes. The sheet may be wrong; the bot may have ignored a correct field; or the customer may have asked for something the sheet never covered. These require different repairs. Editing the bot's tone will not fix an outdated opening time, and adding a new FAQ will not repair a broken calendar connection.
For example, a cleaning company changes its minimum booking from two hours to three. The bot continues to say two because an old pricing paragraph remains in the sheet. The owner removes that paragraph, updates the approved rule, and tests “Can I book two hours?”, “What is the minimum?” and “I saw two hours on your website.” The last test should acknowledge the conflicting public information and hand over if necessary. The website and booking form must also be corrected; otherwise the bot is being asked to reconcile an inconsistency it does not own.
In a second example, the correct sheet says that roof inspections are requested through staff, but the bot reads “book an inspection” as permission to confirm a slot. The fix is a booking-status rule and a test for the exact phrase “book me in”. In a third, the sheet has no rule for a customer who needs step-free access for an appointment. The bot should record the request and hand it to a person without making assumptions. Add the intake route to the sheet, but avoid storing more detail than the team needs.
Review a sample of successful conversations too. A bot may give a technically correct opening time while failing to mention that the showroom and service desk have different schedules. A customer may abandon a quote form because it asks eight questions before explaining what happens next. Look for these usability failures in transcripts and customer replies. A good bot lets the user correct its summary, skip a non-essential question and reach a person without starting over.
Frequently asked questions
Should the bot give an exact price?
Only when the business has a fixed, current price for a clearly defined service and the customer meets every stated condition. For site-dependent work, it should collect the facts needed for a person to quote and avoid estimates that look like a commitment.
Can the bot book an appointment without staff review?
It can offer or confirm a slot only if it reads live availability and the booking rules are clear. If availability is a static sheet or the job needs assessment, collect a preferred window and tell the customer that a person will confirm it. Test cancellations and double bookings before enabling automatic confirmation.
How does a customer reach a person?
Show a visible contact or callback route in the first message and after every uncertain answer. The bot should pass the conversation summary, the customer's chosen contact method and the unresolved question to a named queue, then stop pretending the answer is complete.
Further reads
- Chatbot Guardrails: Stop AI Promising What You Don't Offer — Block claims that the service cannot fulfil.
- How to Test a Customer Chatbot Before It Goes Live — Run realistic launch tests across all three jobs.
- How to Protect a Customer-Facing Chatbot From Misuse — Set boundaries against malicious or irrelevant inputs.
- AI Chatbot Disclosure: What to Tell Customers at the Start of a Chat — Write a clear opening disclosure and contact route.
- AI Receptionist or Answering Service for a Booking-Based Business? — Compare chat with a person-led enquiry route.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: no vendor features, prices or laws are cited. All business figures, answers and test cases are illustrative.