Case study
Industry
Home Services / Field Operations
Location
Ontario, Canada
Company size
Small fleet, 1–5 technicians
A regional HVAC provider replaced manual, geography-blind scheduling with a booking engine that only offers time slots its fleet can physically reach, turning route efficiency into a constraint enforced at the moment of booking, not patched up afterward.
The hard part was never showing open time. It was knowing which open time was actually drivable. A naive overlap check would treat two jobs forty minutes apart in opposite directions as a perfectly valid pair of bookings, then leave the technician to absorb the cost on the road. On top of that, the data needed to make that call was scattered: calendar events, blocked slots, and service bookings all lived across different GoHighLevel endpoints in different shapes, and zone detection threatened a fresh geocoding call on every appointment read. The system had to model the day as a real routing constraint (AM/PM blocks, fixed slots, travel buffers, HQ departure, per-agent weekly load), unify those fragmented CRM reads into one normalised internal format, embed hub IDs in booking titles so appointments could be zone-tagged without re-geocoding, and stay resilient in production through fire-and-forget error logging that never blocks the customer in front of the form.
Codoro designed and built a full-stack booking system that connects a branded, customer-facing experience to a custom scheduling engine that reasons about geography before it ever shows a time. The customer moves through a clean multi-step flow — service selection, contact details, a smart calendar, confirmation — with Google Places autocomplete parsing the address as they type. Behind it sits a FastAPI engine that geocodes that address, assigns it to the nearest of 30+ geographic hub zones, pulls live availability and blocked slots straight from GoHighLevel across every technician, and returns only the slots that are genuinely feasible for the fleet. The core of it is zonal locking — the anti-zigzag rule. Once a technician picks up a job in a given zone for the AM or PM block, they are locked to that zone for the rest of that block, so new customers are only shown slots that keep the route tight. Every candidate slot is validated against existing appointments, blocked time, HQ departure, travel buffers, and each agent's weekly load, all on top of a fixed AM/PM block structure (60-minute jobs, 15-minute travel buffers, a 30-day rolling availability map precomputed the moment an address is entered, and a minimum four-hour booking buffer). To avoid re-geocoding every appointment on every read, the system encodes the hub ID directly into each booking's title, so fetched jobs can be zone-tagged with zero extra API calls — fragmented CRM reads from calendar events, blocked slots, and service bookings all normalised into one internal format the availability logic can trust. On confirmation, contact fields are updated and the service booking is written back into GoHighLevel, keeping everything in one system. Reschedule links prefill from the CRM, a cancellation flow logs the reason as a contact note, and an internal portal lets staff search contacts and book on a customer's behalf. The whole thing runs on roughly 1,600 lines of scheduling logic, with fire-and-forget Supabase error logging that surfaces failures without ever blocking the customer in front of the form.
Every slot a customer sees is now a slot the fleet can actually drive — zone locks, travel buffers, and per-technician load are checked before a time is ever offered, not discovered after it is booked. The 30+ hub zones turn a wide, messy service area into clean geographic blocks, and zonal locking removes the cross-region zigzag that quietly bleeds a one-to-five-technician fleet dry. Bookings, reschedules, and cancellations all live inside GoHighLevel, so there is no duplicate data entry and no second calendar to reconcile. The internal portal replaces phone-tag scheduling for routine estimates, and centralised error logging surfaces API failures before a customer ever has to escalate.
Scheduling is not a calendar problem. It is a constraint problem. An empty slot on a calendar is not the same thing as a feasible job, and for a small field-service fleet the gap between the two is paid in windshield time, late arrivals, and the callbacks that follow a booking nobody could actually keep. Generic tools optimise for showing availability; they have no concept of whether that availability is reachable. This system moves the constraint to where it belongs — the moment of booking — and simply refuses to sell a slot that breaks the route. The fleet's day stays drivable because the booking never let it become otherwise.
Tell us where your home services / field operations business loses hours or leads. We'll walk you through how a system like this one would work for you.
30 minutes · Free · No commitment