Case study · Auto detailing

Two shops.
Two Google accounts.
One booking system.

A ceramic coating and paint protection business running two locations in different states, whose calendars lived under two separate Google accounts that no scheduling tool wanted to join up.

See it in the shop Run a free check
8 booking flows 2 destination calendars Live, plus a follow-on build
Industry
Auto detailing and ceramic coating
Scope
Booking, notifications, tracking, local search
Built with
Cal.com, HighLevel, Google Calendar
Status
Live, plus a follow-on pricing page
8

The number

booking flows across two locations, and every appointment lands on the right calendar without anyone sorting it.

01
The problem

Two locations that could
not share a calendar.

The business runs out of two shops several hours apart, in two different states. Each shop keeps its bookings in its own Google Calendar, and those calendars sit under two entirely separate free Google accounts.

That single detail broke every obvious solution. Bookings were being taken by hand, which meant the wrong location regularly ended up with jobs it could not do, and there was no reliable way to stop the same slot being sold twice.

The constraint was never the calendar. It was that the two calendars belonged to two different accounts, and almost nothing handles that on a free plan.
× Google appointment scheduling One booking page per account, with no way to span two accounts in a single flow.
× Square Appointments Handles multi-location properly, but only once you are on a paid tier.
× Booking it by hand Jobs landing at the shop that could not do them, and slots quietly sold twice.

The build

How a booking picks
its own calendar.

Four settings, and after that the routing is structural rather than something a workflow has to check.

1 Two accounts, one toolCal.com connects multiple Google accounts on its free plan, which was the only real requirement. Constraint
2 One event type per service, per locationFour services across two shops gives eight booking flows, each one its own object. Setup
3 Destination set per event typeNot per account. That single setting is what lets one system write into two separate calendars. Routing
4 Real capacity, hours and holidaysTwo vehicles an hour, closed Wednesday and Sunday, and a year of holidays already blocked. Rules
Two separate Google accountsFree plan
Shop oneAccount A
Shop twoAccount B
Google scheduling spans one account onlyNo
Square multi-location sits behind a paid tierNo
Taken by hand, sorted by hand, sold twiceNo
Eight booking flowsOne per service, per shop
Shop one
Shop two
Ceramic coatingCeramic coating Paint protectionPaint protection Window tintWindow tint Full detailFull detail
Four services, two locations8 flows
Drop-off jobs modelled as blocks, not fifteen minute slotsDuration
Destination calendarSet per event type
Ceramic coating, shop oneCalendar A
Ceramic coating, shop twoCalendar B
Window tint, shop oneCalendar A
Full detail, shop twoCalendar B
A shop one booking cannot reach shop two's calendarStructural
What the calendar knowsEnforced, not assumed
Open days and blocksClosed Wed and Sun
Two vehicles per hour, per locationCapacity
Open Mon, Tue, Thu, Fri and SatHours
Six holidays blocked twelve months aheadHolidays
02
The detail

The settings that decide
whether it actually works.

Cal.com solved the account problem, but a booking tool is only as good as what you tell it about the business. Most of the build was replacing assumptions with the real thing.

  • Real capacity, not a guess. The shops handle two vehicles per hour, so that is what the system enforces, replacing the placeholder daily cap that was there while we confirmed the bay count.
  • Real opening hours. Both shops run Monday, Tuesday, Thursday, Friday and Saturday. Closed Wednesday and Sunday, which the previous setup did not know.
  • A year of holidays blocked in advance, including the ones that fall on a day they would normally be open.
  • Booking questions that actually matter, including vehicle make, model and year, and service specific options, so the shop knows what is arriving before it arrives.
  • Two branded booking pages embedded on the site, each with a four service grid and click to open scheduling, matched to the brand rather than looking like a third party tool.
03
The result

Pick a location, a service
and a time. That is it.

A customer chooses in one flow and the booking lands on the correct shop's calendar with the capacity already accounted for and the holidays already closed. Nobody sorts anything by hand and nobody double sells a slot.

The booking system shipped as part of a fixed price package that also covered lead notification routing to the owner and his marketing contact, conversion tracking installed per page, and search visibility work for the newer of the two locations, which ranked well in one state and barely existed in the other.

The client came back afterwards for a full pricing page covering all four service categories, with the correct sales tax handled per location and every category linking straight into its own booking flow.

What shipped

The whole build,
in six lines.

Booking flows
8

Four services in each of two locations

Destination calendars
2

On separate free Google accounts

Capacity model
2 / hour

Vehicles per hour, per location

Holidays blocked
6

Twelve months ahead, before go live

Booking pages
2

Branded and embedded on the site

Follow-on work
Pricing page

Per location sales tax, linked to each flow

Same problem

Booking that
routes itself.

This system is packaged in the shop. Take the template and set it up yourself, or have it installed and tested in your account with your calendars connected.

See it in the shop Run a free check
Back toAll six builds