Web Chat to Booked Appointment

Most websites treat a visitor with a question as someone else's problem. The page offers a contact form, which asks for a name, an email, a phone number and a message, and promises nothing in return except that somebody will be in touch. A person who was two minutes from booking is handed a chore and an unspecified wait. A good share of them close the tab and open a competitor's.

Where live chat does exist, it usually makes the problem more expensive rather than less. A human chat widget is only as good as the hours it is staffed, and almost nobody staffs it properly: the bubble sits there inviting conversation during the exact evenings and weekends when people actually browse, and the conversations that start then get answered the following Tuesday. Worse, the widget collects the visitor's question and then does nothing structural with it. No contact record, no source, no follow-up, just a transcript in a tool the sales team does not open.

The leak is specific and measurable. Traffic arrives, intent is expressed, and nothing is captured. The visitor who typed "do you do this for commercial properties too?" at 21:40 was a qualified lead with a real question, and the honest answer would have taken nine words. Instead that question is a dead end, the ad spend that bought the click is wasted, and the business concludes from flat form-fill numbers that the traffic is poor quality. The build below replaces the dead end with a conversation that ends on a calendar.

Pipeline and stages

A Chat Inquiries pipeline, deliberately short. The whole point of this build is that most cards reach a booking without human intervention, so a long pipeline just creates stages nobody uses.

• Chat Started: created when a visitor sends their first message.
• Qualifying: BO is mid-conversation, working the qualifying questions.
• Booked by BO: appointment created inside the chat, no human touched it. This is the stage you want most cards in.
• Contact Captured - No Booking: name and a contact method captured, conversation ended without a slot taken.
• Needs Human: BO escalated, or the visitor asked for a person.
• Out of Scope: wrong service, wrong area, job seeker, supplier. Terminal.
• Abandoned - Anonymous: conversation started, no contact details given. Terminal but counted, because the volume here tells you whether the opening question is wrong.

Calendars

• Chat Booking Calendar: the only calendar BO is permitted to write to. Round-robin across whoever handles new inquiries, 30-minute slots, 10-minute buffer, a minimum notice of 2 hours so nobody gets a booking for right now, and a maximum booking horizon of 21 days so the calendar does not fill with appointments people forget about.
• Overflow Calendar: wider availability including early mornings, offered only when the Chat Booking Calendar has nothing inside the next 48 hours. Keeping it separate stops BO from defaulting to the awkward slots.
• Human Callback Calendar: 15-minute slots used by the escalation path when the visitor wants a person rather than an appointment.

Custom fields

• Chat Entry Page: the URL the visitor was on when they opened the widget. This is the single most useful field in the build.
• Chat First Message: their opening line, verbatim, untouched.
• Chat Transcript: the full conversation, written on completion.
• Service Interest: the service BO identified, from the client's actual list.
• Service Area Check: In Area, Out of Area, Unknown.
• ZIP code or Zip: collected when the service is location-dependent.
• Timeframe: This Week, This Month, Next Few Months, Just Researching.
• Budget Signal: a plain qualitative marker, not a figure: Has Budget, Price Sensitive, Unknown. BO never discusses amounts.
• Qualification Score: a number field, 0 to 4, incremented as BO captures service, area, timeframe, and contact method.
• Booking Offered At: the timestamp BO first presented slots.
• Booking Outcome: Booked, Declined Slots, No Slots Suitable, Escalated, Abandoned.
• Escalation Reason: Pricing Question, Complaint, Existing Customer Issue, Asked For Human, Out Of Scope, Unclear.
• Preferred Contact Method: Text, Email, Call.
• Chat Device: Mobile or Desktop. Mobile chats are shorter and need fewer questions; you will tune the script differently for each.
• Quiet Hours Zone: the visitor time zone, so follow-up texts land at a civilised hour.

Tags

• source-webchat on every contact the widget creates, which is what makes chat attributable.
• chat-booked, chat-captured-no-booking, chat-escalated, chat-abandoned.
• chat-out-of-area, chat-out-of-scope: both suppress sales follow-up entirely.
• chat-after-hours: set when the conversation starts outside opening hours, used to measure how much of the value this build creates comes from the hours nobody was working.
• chat-returning-visitor: applied when the contact already exists.
• sms-opted-out, email-unsubscribed, do-not-contact: hard suppressions.
• needs-human-urgent: the only tag that pages a person outside hours.

Forms

• Inline Capture Form: not a traditional form. BO collects name, then one contact method, as two separate conversational turns written straight to the contact record. Asking for both at once is the single biggest cause of drop-off in this build.
• Booking Confirmation Form: presented in-chat after a slot is chosen: confirm the contact method, add the one piece of detail the appointment actually needs (address, vehicle, case type, whatever applies), and accept the reminder consent language.
• Escalation Handoff Form: internal, auto-populated from the transcript so the human picking it up reads a summary rather than scrolling a conversation.
• Fallback Inquiry Form: a short page-embedded form offered only when the visitor refuses chat or the widget fails to load. Two fields: contact method and what they need.

BO's role and guardrails

• BO opens with a question tied to the page, not a greeting. On a service page: "Looking at {{page_service}}? Tell me what you need and I'll see what's free this week." Generic greetings get ignored; page-specific questions get answers.
• BO's qualifying sequence is fixed and short: what you need, where you are (if location matters), when you need it, and then the booking offer. Four questions maximum before slots are shown. Every additional question costs conversions.
• BO answers from a defined knowledge base: services offered, areas covered, opening hours, what happens at the appointment, how long things take, what to bring, parking and access. Nothing else.
• BO asks for the name after the visitor's second message, not the first. The visitor has to feel the conversation is going somewhere before they identify themselves.
• BO offers no more than three slots at a time, nearest first, and says what the appointment is for so the slot has meaning.
• Hard guardrails: never quote or estimate a price, never give advice of a clinical, legal, or financial nature, never promise an outcome, never invent availability outside the real calendar, never claim to be human when asked directly, and never continue a conversation that has turned into a complaint.
• BO escalates immediately on: a direct request for a person, any complaint language, any mention of an urgent or emergency situation, a pricing question asked twice, or three consecutive turns where BO has not understood. Escalation applies needs-human-urgent only in the first three of these.
• BO always offers an exit: "Happy to just take your number and have someone call you instead, which would you prefer?" A visitor who does not want to book should still become a contact.

Numbers and channels

• The chat widget on every page of the site, with the opening question varied by page group. Service pages, pricing or quote pages, the contact page, and blog content each get their own opener.
• A single SMS-capable number for confirmations, reminders, and the follow-up ladder. Chat conversations that captured a mobile continue by text once the browser closes, which is the whole trick: the conversation survives the tab.
• Email as the fallback channel wherever no mobile was captured.
• Optional: the same BO configuration connected to the client's social inbox so a Facebook or Instagram message lands in the identical qualifying flow and the same pipeline. Build it on the website first, then extend.

1. At 21:14 on a Wednesday a visitor lands on a service page from an organic search. The chat bubble is already open at a small size, showing a single line: "Looking at {{page_service}}? Tell me what you need and I'll see what's free this week."
2. She types "do you cover commercial as well as residential?" The conversation is created, a card appears in Chat Inquiries at Chat Started, Chat Entry Page and Chat First Message are written, Chat Device is set to Mobile, and chat-after-hours plus source-webchat are applied. No contact record exists yet, because she has given no identifying detail.
3. BO answers the actual question in one sentence from the knowledge base, then asks the first qualifying question: "Yes: commercial is about half of what we do. What's the property and roughly what's the job?"
4. She describes the job. BO writes Service Interest, increments Qualification Score to 1, moves the card to Qualifying, and asks for the name: "Got it. Who am I speaking with?"
5. She gives a first name. A contact is created from it, and from here every field BO captures lands on a real record. Qualification Score goes to 2.
6. BO asks for the ZIP code, checks it against the service area list, writes ZIP code or Zip and Service Area Check as In Area, and increments the score to 3.
7. BO asks about timing: "When were you hoping to get this done?" She says within the next couple of weeks. Timeframe is set to This Month, score reaches 4.
8. BO offers slots: "I can get someone out to look at it. I've got Thursday 10:00, Thursday 14:30, or Friday 09:00: any of those work?" Booking Offered At is stamped. Three slots, nearest first, from the Chat Booking Calendar only.
9. She picks Friday 09:00. BO presents the Booking Confirmation Form in-chat: confirm cell number, add the site address, accept reminder messages. She completes it.
10. The appointment is created on the Chat Booking Calendar. The card moves to Booked by BO, chat-booked is applied, Booking Outcome is set to Booked, and the full Chat Transcript is written to the contact.
11. Within thirty seconds she receives a confirmation text with the date, time, address, what to expect, and a reschedule link, plus the same detail by email. Nobody at the business has done anything; it is 21:21 and the office has been closed for six hours.
12. At 08:35 the next morning the assigned team member gets a single notification: new booking from web chat, with the transcript, the service interest, and the entry page. They read the whole context in twenty seconds.
13. The appointment reminder ladder takes over, running a reminder at 24 hours and a short confirmation request at 2 hours before.
14. On Friday she attends. Because Chat Entry Page and source-webchat are on the record, the eventual sale is attributable all the way back to the organic page that produced a question at 21:14, which is the number that decides next quarter's content budget.

1. Chat Session Capture and Enrichment

Trigger: visitor sends a first message in the web chat widget.

Conditions and branches: branch on whether the browser carries a known contact identifier. Branch on page group. Branch on business hours.

• Known visitor: attach the conversation to the existing contact, apply chat-returning-visitor, and load prior Service Interest into the conversation context so BO does not ask what it already knows.
• Unknown visitor: create the conversation without a contact. Hold Chat First Message, Chat Entry Page, and Chat Device against the session, and write them to a contact the moment a name is given. Creating a nameless contact per session fills the database with junk, so do not.
• All paths: create a card in Chat Inquiries at Chat Started. Apply source-webchat.
• Page group branch: load the opener for that group. Service pages ask what the visitor needs, quote pages ask what they want priced, the contact page asks whether they would rather book or be called, blog pages ask whether they are researching or ready.
• Outside hours: apply chat-after-hours and swap one line into BO's opener: "The team's offline until {{opening_time}}, but I can book you in right now." Never hide the widget out of hours. That is where a third of this build's bookings come from.
• Wait 90 seconds. If the visitor has sent nothing further, BO sends one nudge: "Still there? Even a rough idea of what you need and I can check the calendar." One nudge only.

Exit: on escalation, on booking, or after 20 minutes of silence, at which point the abandonment workflow takes over.

2. Qualify and Book

Trigger: conversation reaches Qualifying, meaning the visitor has answered the opening question.

Conditions and branches: the sequence is gated at each step on whether the answer was understood. Three consecutive misunderstandings route to escalation rather than asking a fourth time.

• Step 1: service. BO matches the described need to the client's service list and writes Service Interest, incrementing Qualification Score. If the need matches nothing on the list, apply chat-out-of-scope, move the card to Out of Scope, and reply honestly: "That's not something we handle, so I won't waste your time, but {{alternative_suggestion}} is the usual route for it."
• Step 2: name. Asked only after the service answer. Creates or attaches the contact. If refused, BO continues qualifying and tries once more immediately before the booking offer, never a third time.
• Step 3: area, skipped entirely when the service is not location-dependent. Writes ZIP code or Zip and Service Area Check. On Out of Area: apply chat-out-of-area, move to Out of Scope, and say so plainly rather than booking a visit that will be canceled.
• Step 4: timeframe. Writes Timeframe. Just Researching does not block the booking offer; it changes the wording of it to "no commitment, it's just a conversation".
• Step 5: booking offer. Pull the next three available slots from the Chat Booking Calendar, respecting the 2-hour minimum notice. Stamp Booking Offered At. Offer exactly three.
• If no slot inside 48 hours: pull from the Overflow Calendar and flag it: "the next normal slot is {{date}}, but I can squeeze you in at {{overflow_slot}} if that's better."
• If all three declined: ask once for a preferred window, set Booking Outcome to No Slots Suitable, and hand to the no-booking follow-up below.
• On slot selection: present the Booking Confirmation Form, create the appointment, move to Booked by BO, apply chat-booked, write Booking Outcome as Booked and the full Chat Transcript.

Stop conditions: escalation triggered, visitor closes the tab (abandonment workflow), booking created, or Out of Scope reached. BO never loops back to a question already answered.

3. Booking Confirmation and Handoff

Trigger: appointment created from a chat conversation.

Conditions and branches: branch on whether a cell number was captured, and on whether the booking was made inside or outside business hours.

• Immediately, send SMS: "Booked, {{contact.first_name}}, {{appointment.day}} {{appointment.time}} at {{appointment.location}}. {{what_to_expect_line}} Need to move it? {{reschedule_link}}"
• Immediately, send the confirmation email carrying the same detail plus the calendar attachment, the address with access notes, and what to bring.
• No mobile captured: email only, and add a line asking for a mobile so reminders can be sent. Set Preferred Contact Method to Email.
• Booked inside hours: notify the assigned user immediately with the transcript summary, the entry page, and the service interest.
• Booked outside hours: hold the internal notification until 08:30 the next working day, then send it. Paging the team at 22:00 for a routine booking is how teams learn to mute notifications.
• Wait 10 minutes, then verify the appointment exists on the connected external calendar. If it does not, notify the admin immediately. A silent sync failure is the worst outcome in this build, because the visitor has a confirmation for a slot nobody can see.
• Hand the appointment to the reminder ladder.

Exit: on successful notification and sync verification.

4. Abandoned Chat Recovery

Trigger: chat conversation inactive for 20 minutes without a booking.

Conditions and branches: the whole workflow forks on whether any contact detail was captured. This is the difference between a recoverable lead and a statistic.

• No contact detail at all: move the card to Abandoned - Anonymous, write the transcript against the session, and exit. Count it. A high volume here means the opening question or the name-ask timing is wrong, and that is a build fix, not a follow-up problem.
• Name and mobile captured, no booking: move to Contact Captured - No Booking, apply chat-captured-no-booking, set Booking Outcome to Abandoned.
• Wait 30 minutes (held to 08:00 if that lands inside quiet hours for the Quiet Hours Zone). Send SMS: "{{contact.first_name}}, we got cut off. You were asking about {{custom_values.service_interest}}. Want me to grab you a slot? {{calendar_link}}"
• Wait 1 day. If no reply and no booking, send email with the subject "Picking up where we left off" quoting their own first message back to them verbatim, which is far more effective than a generic nudge, plus the booking link.
• Wait 3 days. Final SMS: "Last one from me. If you still want {{custom_values.service_interest}} sorted, the calendar's here: {{calendar_link}}. Otherwise I'll leave you be."
• Wait 1 day, then create a single task for the assigned user: "Chat lead, no booking after 3 touches: worth one call?" with the transcript attached. One human attempt, then stop.
• Email only, no mobile: run the same ladder with the SMS steps replaced by email, and stretch the waits to 2 hours, 2 days, and 5 days.

Stop conditions: any booking, any reply, chat-out-of-area or chat-out-of-scope applied, sms-opted-out or do-not-contact applied, or the contact entering a different active sales sequence. Nobody should be in two ladders at once.

5. Escalation to Human

Trigger: BO escalates, or the visitor types any variant of asking for a person.

Conditions and branches: branch on Escalation Reason, then on business hours.

• Write Escalation Reason, move the card to Needs Human, apply chat-escalated, and populate the Escalation Handoff Form from the transcript.
• Inside hours, routine reason (Pricing Question, Unclear): BO says "Let me get a colleague. One moment" and notifies the on-duty team member, who has the live conversation. BO stops writing until the human either replies or 5 minutes pass.
• Inside hours, after 5 minutes with no human reply: BO returns with "Everyone's tied up right now. Can I take your number and have them call you back within the hour?" Capture the number, set Preferred Contact Method to Call, and create a task due in 60 minutes.
• Complaint or urgent reason: apply needs-human-urgent, notify the owner by SMS immediately regardless of hours, and suppress the contact from every marketing sequence until the tag is cleared. BO's reply: "I'm going to get a person onto this rather than keep you talking to me. What's the best number for you?"
• Outside hours: BO offers a slot on the Human Callback Calendar for the next working morning rather than pretending someone is available: "The team's back at {{opening_time}}. I can put you first in the queue. What number should they use?"
• Wait 2 hours after any escalation. If the handoff task is still untouched and the reason was not routine, escalate again to the manager, once.

Stop conditions: human replies in the conversation, callback task completed, or needs-human-urgent cleared.

6. Chat Reminder Ladder

Trigger: appointment created with source web chat.

Conditions and branches: gated on appointment status at every step. Any cancellation or reschedule exits immediately and re-enters at the new time.

• Wait until 24 hours before the appointment. Send SMS: "Reminder: {{appointment.day}} at {{appointment.time}} for {{custom_values.service_interest}}. Reply C to confirm or R to move it."
• Branch on reply. C applies a confirmed marker and exits the ladder early at the 2-hour step. R sends the reschedule link and returns the card to Qualifying with a note.
• Wait until 2 hours before. If unconfirmed, send: "See you at {{appointment.time}}, we're at {{appointment.location}}. {{access_note}}"
• Wait until 15 minutes after the scheduled start. If the appointment is not marked attended, notify the assigned user: "{{contact.first_name}} hasn't shown: chat booking from {{custom_values.chat_entry_page}}."
• Wait 2 hours after the scheduled end. Branch on attendance. Attended goes to the post-appointment sequence. No-show sends one recovery message: "Sorry we missed you, {{contact.first_name}}. Want to pick another time? {{calendar_link}}" and nothing after it.

Stop conditions: cancellation, reschedule, sms-opted-out, or attendance marked.

7. Weekly Chat Performance and Script Tuning Digest

Trigger: scheduled, every Monday at 08:00 for the previous seven days.

Conditions and branches: send only if at least five conversations occurred, below which the numbers are noise.

• Compile conversations started, conversations reaching Qualifying, bookings by BO, contacts captured without booking, escalations by reason, anonymous abandonments, and the split between in-hours and after-hours conversations.
• Compile the top ten Chat Entry Page values by conversation volume and by booking rate. A page with high volume and low booking rate usually has a content problem, not a chat problem.
• Compile the twenty most recent Chat First Message values verbatim. Reading these is the single highest-value five minutes of the week: questions BO could not answer become knowledge base entries, and recurring questions become page content.
• Compile the average number of BO turns before a booking. If this climbs above six, a question has crept into the script that should not be there.
• Email the owner and whoever maintains the site, subject: "Web chat: {{booking_count}} booked, {{escalation_count}} escalated, {{anonymous_count}} walked away".
• Wait 10 minutes, then create one task: "Review unanswered chat questions and update BO's knowledge base", due Wednesday. This is the maintenance loop that keeps the build from decaying.

Exit: on send and task creation. Reports only measured platform data, with no inferred conclusions.

The website stops losing the people who were almost ready. A question typed at 21:40 gets an answer at 21:40, and if the answer is satisfactory the visitor leaves with an appointment rather than a hope. The team wakes up to bookings that were made and confirmed while the building was empty, with the full conversation attached, so the first contact with the customer starts from knowledge rather than from a cold call.

Form fills stop being the only measure of website performance, which usually reveals that the traffic was never the problem. Because every conversation carries its entry page, the pages that actually produce inquiries become visible, and so do the pages that produce questions the site should have answered already. The verbatim first-message list is the most honest content brief most businesses will ever receive.

There is also a quieter operational change: the team stops being interrupted. BO absorbs the opening-hours questions, the do-you-cover-this questions, and the what-should-I-bring questions that previously consumed reception's attention one at a time, and escalates only the conversations that genuinely need a person.

Metrics to watch

• Chat engagement rate: conversations started divided by sessions where the widget loaded.
• Qualification rate: share of conversations reaching Qualifying. A low number points at the opening question.
• Chat-to-booking rate: bookings by BO divided by conversations started. This is the headline number for the build.
• Contact capture rate: conversations that produced a name and a contact method, booked or not. Always higher than the booking rate, and the gap is what the recovery ladder works on.
• Anonymous abandonment rate: conversations ending with no detail at all. Treat this as a script defect, not a visitor defect.
• Escalation rate by reason: and specifically how much of it is Pricing Question, which tells you whether the site needs clearer pricing guidance.
• After-hours share of bookings: the clearest single justification for the build.
• Average turns to booking: watch it drift upward over time as questions get added to the script.
• Booking-to-attendance rate for chat bookings specifically, compared with phone bookings. A gap means the qualifying is too light and the reminders need tightening.
• Booking rate by entry page: the number that should drive content investment.

Prerequisites

• A written, finite service list. BO cannot qualify against a list that does not exist, and "we do all sorts of things" produces a widget that books the wrong appointments.
• A defined service area, stated in whatever unit the business actually uses: ZIP codes, zips, counties, radius. Half-defined areas produce canceled site visits.
• Real availability on the Chat Booking Calendar, from people who have agreed to be on it. The most common failure in this build is a calendar nobody has claimed, which produces bookings with no owner.
• Answers to the twenty questions the business is actually asked, written out. Pull them from existing email, the phone, and whatever the receptionist can recall in ten minutes. This is BO's knowledge base and the build is only as good as it.
• A decision on what to do about pricing questions, which will be the most common escalation. Either BO points at a pricing page, or it captures the question and promises a human, but it never guesses.
• Website access to install the widget, and someone who can edit page content when the first-message review turns up gaps.

Integrations

• Google Calendar or Outlook two-way sync for every person on the Chat Booking and Human Callback calendars. Without it BO will double-book, which costs more trust than the build earns.
• The widget script installed site-wide, with page-group detection working. Verify the opener actually changes between a service page and the blog before launch.
• An SMS-capable number provisioned and registered.
• Email sending domain authenticated with SPF, DKIM, and DMARC. Booking confirmations landing in spam will be blamed on the chat widget.
• Slack or Teams for escalation notifications if that is where the team lives; email alone is too slow for a live conversation.
• Optional: social inbox connection so the same flow handles Facebook and Instagram messages, and Zapier or Make if bookings must also appear in a legacy system.

Number provisioning and messaging compliance

• Provision the SMS number and complete carrier registration before launch. In the US, A2P 10DLC brand and campaign registration is required for confirmations, reminders, and the recovery ladder. Start it on day one. Approval takes days, and unregistered traffic is filtered silently, which looks identical to a broken workflow.
• Register the use case as customer care and conversational messaging, with sample copy matching what BO actually sends.
• Capture messaging consent explicitly in the Booking Confirmation Form, with plain language stating that appointment and follow-up texts will be sent and that message rates may apply. Store the timestamp.
• Implement opt-out handling on every SMS path: STOP, UNSUBSCRIBE, QUIT and variants apply sms-opted-out, suppress every text workflow immediately, and send exactly one confirmation reply.
• Set quiet hours at 08:00-20:00 in the visitor's own time zone, held in Quiet Hours Zone. The chat widget itself runs 24 hours; the outbound messages do not.
• Disclose that the chat is automated. BO must answer truthfully when asked whether it is a person, and the widget should carry a short line saying it is an assistant. This is both a compliance point in a growing number of jurisdictions and the thing that stops the conversation souring when the visitor works it out.

Data protection

• Chat transcripts are personal data and visitors routinely volunteer far more than asked. Agree a retention period for Chat Transcript, restrict who can read it, and make sure deletion requests clear transcripts as well as contact records.
• Keep BO away from any category of information the business would rather not hold. If the service touches health, finance, or legal matters, instruct BO to capture only that an appointment is needed and let the detail be discussed with a human.
• Link the privacy notice from the widget itself, not only from the site footer, and make sure it covers automated processing and the messaging follow-up.
• Where visitors may be in the UK or EU, document the lawful basis for the chat capture and for subsequent marketing messages, and keep the marketing consent separate from the appointment consent.

None of the above is legal advice. Messaging rules, AI disclosure requirements, and data-protection obligations vary by jurisdiction and are changing quickly. Confirm the specifics with the client's own counsel before launch, and get the consent wording and retention period signed off in writing.

Scoping and configuration depth vary per business. Book a call at bookings.appbo.io to work through yours.