Chief Sizzling Grill

// overview

The scope covered two halves of the same problem: a landing page with a reservation form customers would actually use, and an automation that takes that submission and safely turns it into a CRM record — without duplicate contacts, duplicate bookings, or silent failures.

Several non-obvious bugs surfaced across two build days — Day 1 on the core Found/Not Found logic, Day 2 on upgrading that logic further, then on ownership and follow-up accountability, then on the appointment-scheduling layer itself — each one the kind that looks fine in a quick demo and quietly breaks in production. All of them were root-caused and fixed before this was called done. A later session added a review response routing layer on top of the booking system, covered in Part 6. A further session then built and tested the full post-visit review request and retention email sequence, covered in Part 7.

// the full pipeline: booking → review → retention

The booking automation below is one stage of a larger customer-lifecycle system. The full pipeline is scoped as three connected stages. Stage 1 (booking) is fully built and tested. A fourth, adjacent piece — review response routing, covering what happens once a review actually comes in rather than requesting one — has also been built and is documented in Part 6. Stages 2 (outbound review request) and 3 (retention) have since been built and tested in the live GHL workflow canvas, triggered off the same Pipeline Stage Changed event used in Part 3, and are documented in Part 7.

// this case study documents Stage 1 in full, including the Calendar trust-boundary step — originally scoped as a Google Calendar all-day event, later rebuilt as a native GHL Appointment with its own ID-capture workflow (see Part 4 below). Part 6 documents a separate, already-built review response routing layer that reacts to inbound reviews rather than requesting them — distinct from Stage 2. Stages 2 and 3 have since been built and tested end-to-end (see Part 7).

// the landing page

Built entirely inside GHL's Funnel/Site editor as a single-scroll structure, with attention paid to visual cohesion rather than stitching together disconnected template sections.

The design decision that mattered most wasn't visual — it was which fields were marked required. Destroy-testing (below) showed that without Phone, Email, First Name, and Select Date all mandatory, blank submissions could slip through and create incomplete, unusable contact records.

// the automation

On paper, the base structure is simple:

// getting each box to actually do what its label suggested is where the real work happened

// three bugs found by breaking it on purpose

// destroy-testing results

A deliberate "how can I break this" pass, run before trusting the automation with anything real.

// closing the silent-failure gap

Originally the "Found" branch only notified staff — the customer who submitted the form got no response at all, which could look like a silent failure from their side. A second notification was added so the customer isn't left to self-diagnose:

// part 3 — round-robin assignment & escalation ladder

Once the Found/Not Found logic was solid, the automation was extended past "notify staff" into an actual ownership and accountability system — every new reservation lead gets assigned to a person, that person gets reminded, and if nothing happens within 48 hours, it escalates to the business owner directly.

// Both the "Found" (owner-check) and "Not Found" (always assigns) paths converge into this same shared chain

Both branches converge into the same two-round escalation pattern:

// the "stage changed" branch on each check is intentionally left with no further action — a stage change means a human already resolved the lead manually, so the ladder simply stops there

// part 4 — wiring up real appointments, and the bug that shipped wrong dates silently

With ownership and escalation solid, the last piece was turning a confirmed reservation into an actual bookable appointment — not just a CRM card. This is where the automation found its most dangerous bug yet: one that didn't throw an error at all.

// the silent failures were strictly worse than the loud ones — a skipped booking is annoying but visible; a booking on the wrong month reads as a completely normal, confirmed reservation until a customer shows up on the wrong day

// re-tested with a brand-new contact after the fix — Book Appointment executed successfully and the calendar entry matched the submitted date exactly, closing out the bug

// part 5 — calendar type mismatch, and closing the loop on failed bookings

With appointment creation working for the happy path, two more gaps surfaced: what happens when GHL rejects the calendar type itself, and what happens when a real slot conflict occurs — no available time, not just a formatting error.

// this replaces an earlier assumption — that any Book Appointment failure meant a formatting bug (Bug 07) — with a proper distinction between "the workflow is broken" and "the workflow is working correctly and the slot is genuinely full"

// why reservations aren't auto-closed

Once the Calendar step was designed, an obvious next question came up: could the system automatically detect when a visit is over, and close the reservation itself — instead of relying on staff to remember? Worth documenting the reasoning for not building that, rather than leaving it looking like an oversight.

// conclusion: for this specific business, closing a reservation is correctly a human decision, not a gap to be automated away — the existing "Calendar Event ID already exists" safety-net (below) is the honest, proportionate handling for when that human step gets missed, rather than building an auto-close system to chase a signal that isn't there

// part 6 — review response routing & the Reviews AI safeguard

A separate piece, built after the booking system was stable: what happens once a real review actually comes in. Rather than requesting reviews (that's Stage 2, covered in Part 7), this system reacts to inbound reviews — surfacing the ones that need urgent attention, while letting GHL's native Reviews AI handle the drafting work.

The trigger itself, New Review Received, is a native GHL trigger tied to whichever review platforms are connected on the account — in this build, Google (Facebook is also supported natively). It doesn't poll or check anything on a schedule; it fires automatically the moment someone leaves a review directly on the connected Google or Facebook business profile, and GHL pulls that review in as an event. This is a distinct system from the Stage 2 review request in Part 7 — this trigger reacts to a review a customer already posted externally, it doesn't send anything out.

// the workflow only surfaces urgency for negative reviews on purpose — see reasoning below

// part 7 — post-visit review request & retention sequence (built & tested)

With booking (Stage 1) and inbound review routing (Part 6) both built, the remaining piece was Stages 2 and 3: getting a review request out after the visit, then following up afterward regardless of whether that request converts. This section documents the sequence as built, triggered off the same Pipeline Stage Changed event used in Part 3, with the Calendar Event ID field anchoring the Wait 2 timing calculation. Tested end-to-end with a live submission.

// built and tested as a workflow triggered off the same Pipeline Stage Changed event used in Part 3, sharing the existing Calendar Event ID field as the anchor for the Wait 2 timing calculation

// known limitations — documented honestly

Named on purpose, not glossed over, as part of the learning process.

// what this demonstrates

The common thread across all of this: reading past a tool's surface-level label to verify actual configured behavior, stress-testing edge cases instead of just the happy path, and treating a "successful" execution as suspect, not just a failed one — Bug 07's wrong-date bookings never threw an error, so verifying output against input mattered as much as watching for failures. Part 6 adds a second, related thread: knowing where to draw the line between automation and human judgment isn't a limitation to route around — the decision to keep AI reply-sending manual, and to only interrupt the owner for genuinely urgent cases, is itself a deliberate design choice, not a shortfall.

// tools used