Capabilities The Library Case studies Free audit About Contact Get a free audit →
Hospitality / lodge

Three booking systems, one source of truth, zero double-bookings since launch.

The lodge had a beautiful Base44-built guest portal, a GHL CRM full of guest history, and a Google Calendar that ops actually looked at. None of them talked. Bookings fell through cracks weekly. We made the three systems agree — and freed nine minutes of ops time per booking.

0
Double-bookings since launch
9 min
Avg ops time saved per booking
3 systems
Now sync in real time
17 days
Audit to live sync

The problem

The lodge had been growing fast. The guest-facing booking portal was on Base44 (clean, branded, exactly what they wanted). The CRM was GoHighLevel (everyone knows it, everyone uses it). The internal calendar was Google Calendar (because that's what ops actually opens in the morning). All three were sources of truth depending on who you asked. Twice in one summer, two different couples got booked into the same cabin. Once, a wedding party showed up with no record on the staff side.

Off-the-shelf integrations didn't fit. The Base44 build was custom, the GHL pipeline was custom, and the Google Calendar logic ("which staff member sees which property") was custom. Standard Zapier connectors couldn't hold the model.

The system we built

We made GoHighLevel the canonical source of truth, with Base44 as the guest write surface and Google Calendar as a render-only mirror for ops. Bookings created in any system propagate to the other two within seconds. Conflicts are caught at write time — not after the guest's already paid.

The sync architecture

Base44 portalGuest writes
Conflict checkONB-10
GHL canonicalONB-02 sync
Google CalOps mirror
Welcome chainONB-03 cadence

What was harder than it looked

The conflict-resolution logic. When two writes hit at nearly the same moment from different surfaces, who wins? We built an ordered-arrival lock with a HITL fallback for the rare cases the automation can't decide. Three months in, that fallback has fired exactly twice — both times correctly handed off to a human who could call one of the guests.

Time zones were the second trap. The lodge serves guests from three continents. We standardized everything to UTC at the storage layer and rendered locale-aware in every guest-facing surface. The GHL pipeline now stores the canonical UTC, and the Base44 portal and confirmation emails render in the guest's locale.

"We stopped having that 6am conversation where someone realizes we sold a cabin twice. That alone paid for the whole project. The ops time savings is just the bonus."
— General manager (name withheld)

What we measured

  • 0 double-bookings since launch. Across about 1,400 bookings to date.
  • 9 minutes saved per booking for ops — no more manual confirmation between calendars and CRM.
  • 17 days from audit to live sync, including a 5-day shadow period where we ran the new system in parallel with the old before flipping cutover.
  • 1,400+ bookings processed cleanly through the new sync since cutover.

What's running today

The sync is live and we still own the runbook. We added a calendar-conflict resolver atom (ONB-10) during the 90-day tuning window, which became one of the most-reused atoms in the library. The lodge is now expanding to a second property; the same sync drops in unchanged.

Have a multi-system mess?
Free 48-hour audit. We'll map the sync architecture, free.
Get the audit