How to Add an AI Chat Widget With Real Booking Using n8n and Groq

Most website chat widgets either answer nothing useful or hand a lead straight to a generic contact form that gets checked once a day. A visitor who wants to book a call has to leave the conversation, dig up a scheduling link, and hope a slot is still open. I built a real site-wide chat widget that answers visitor questions grounded in this site's own real content, then checks Google Calendar for actual open slots and books a real event on the spot, without the visitor ever leaving the chat panel.

1. 1

   Build the Site-Wide Chat Widget First

   • Add a fixed launcher button and a slide-up panel via a small plugin's own footer hook, stacked above any existing WhatsApp button on the page.
   • Keep conversation history in the browser's own sessionStorage, capped to the last 8 turns, instead of a server-side session.
   • Route every message through a single WordPress AJAX action that blocks on the reply, since the visitor is waiting for it in the chat panel.
   • Add a nonce and a per-IP rate limit on that AJAX handler before wiring anything to n8n.
2. 2

   Normalize Whatever Hit the Webhook First

   • One Webhook node receives two different real payload shapes on the same URL: a normal chat turn, and a booking-form submission.
   • A Code node reads which shape arrived, caps and sanitizes the message and history, and computes the real current date and time in the business's own timezone.
   • Branch on an IF node checking which shape this is before anything else runs, so a booking submission never accidentally goes through the chat-drafting path.
3. 3

   Draft the Reply With Groq, Grounded in Real Facts

   • Build one prompt containing the business's real offer, process, and capabilities as a literal JSON block, so the model cannot invent anything beyond it.
   • Ask for a single JSON response: a reply, an intent (qa or wants_booking), and a short topic summary drawn from the whole conversation, not just the message that triggered a booking.
   • Call Groq's chat completions endpoint with response_format set to json_object, not a raw text completion.
   • Groq replaced Gemini here for one real reason: repeated timed tests showed Gemini's reply latency swinging from 5 seconds to over a minute with no request parameter that reliably bounded it, while Groq stayed consistently fast across every real test since.
4. 4

   Query Real Calendar Availability Before Offering a Time

   • When intent comes back as wants_booking, call Google Calendar's freeBusy endpoint once, across the next 10 days, on the business's real booking calendar.
   • Generate candidate 30-minute slots inside real business hours, filter out anything overlapping the calendar's actual busy ranges, and cap the list to a handful of options.
   • Return the reply together with those real slots. The widget renders them as an inline form (name, email, a picker) instead of the model asking the visitor to type out a preferred time itself.
5. 5

   Verify Again and Create the Real Event on Submit

   • A booking-form submission hits the same webhook with its own shape: name, email, and the exact slot the visitor picked.
   • Re-run a real freeBusy check on that exact slot before booking anything, closing the race condition where two visitors pick the same open time in the same window.
   • Only then create the real Calendar event with sendUpdates set to all, so the visitor gets a genuine email invite.
   • A slot that was just taken gets an honest "that time was just booked" reply instead of a silent double-booking.
6. 6

   QA-Lint Every Reply Before It Reaches the Visitor

   • Run the same banned-word and em-dash checks this site uses on every other AI-drafted reply against the final text before it goes out.
   • Fall back to a short, honest static reply if the check fails, rather than showing a broken or robotic-sounding draft.
   • Converge every branch (booked, slot taken, plain answer, error) back into one shared shape before this check runs, so it covers all of them the same way.
7. 7

   Log Every Turn and Alert on a Real Booking

   • Append every turn to a Google Sheet: the message, the intent, the reply, whether it booked, and the visitor's email if there was one.
   • Fan an admin alert email out in parallel from the booking-confirmation step, not chained after it, so a slow or failed email send can never affect what the visitor actually sees.
   • Set the email node's error handling to continue on its own output, so a flaky SMTP send never fails the whole run.
8. 8

   Add an Admin On/Off Switch, With a Real Reason When Booking Is Off

   • Add two checkboxes to a plain WP Settings API page: one to hide the widget entirely, one to turn off booking specifically.
   • Send that booking flag to n8n on every request, and force the model's intent back to qa server-side if it ever ignores the instruction, a real safety net rather than just a prompt.
   • When booking is off, have the model explain why in its own words instead of a fixed script, pointing the visitor at email or WhatsApp instead.
9. 9

   Split Into Its Own Plugin, With a Contact-Form Fallback When Booking Is Off

   • Moved the widget out of the theme entirely into its own small plugin, its own settings page, its own asset enqueue, its own AJAX handler, so it survives a future theme change and can be activated or deactivated on its own.
   • When booking is off and a visitor actually asks to book, show a real inline name, email, and message form instead of only explaining why, logged to the same Google Sheet a real booking uses, with a real confirmation email sent to the visitor, not just a chat bubble that claims one is coming.
   • Kept the model's own intent classification honest even with booking off, instead of forcing it to always say "qa" in its own output, a real prompt bug found by testing rather than guessed, that was silently swallowing the exact signal the contact form now depends on.