Skip to content

Customer Operations

Scheduling: every appointment has one true state

“We got your request” is not a booking. A booking is not the technician arriving, and arriving is not the job done. Scheduling keeps those apart: customers are offered times your dispatch board can actually keep, a slot is promised only when it's confirmed, and every change reaches the customer before it reaches their door. We build it on your dispatch board, so every time offered is one you can keep.
Talk through your schedulingSee what happens when plans change ↓
ThuFriAMPMfreefreefreefreerequestedheldJ-561offeredofferedJ-544 · T3requestedThu AM, by the customerheldThu AM, 15 minhold lostJ-561 took the slotofferedThu PM or Fri AMconfirmedFri 08:00–10:00 · T3reminderThu 18:00, by texton the wayFri 08:20arrivedFri 08:44completedFri 10:05

One appointment, four different promises

Most scheduling trouble comes from one word doing four jobs. “Booked” can mean the customer asked for a time, the office wrote it down, dispatch assigned a technician, or the work is done. When a single flag stands for all of them, customers get confirmed for times nobody can keep, and the office can't tell which jobs are actually happening.

A scheduling system gives each of those its own state, its own owner and its own message. Times are offered from the dispatch board's real capacity, held briefly while the customer decides, and only confirmed by the person or system entitled to confirm them.

Every state has an owner

RequestedThe customer wants a timeThe customer, or intake on their behalf
HeldA slot is reserved briefly while they decideScheduling, with an expiry
ConfirmedThe time is promisedDispatch, from real capacity
On the wayThe technician has leftThe technician's app
ArrivedThe technician is on siteThe technician's app
CompletedThe visit's outcome is recorded, including “needs another visit”The technician, checked by the office

When the plan changes

The normal booking is easy. Here are the ones that usually go wrong.

J-544 · 9 Willow Ct

  1. Times offered

    Thu AM, Thu PM, Fri AM

    done

  2. Thu AM held

    15 min

    done

  3. Dispatch confirms

    T3, Thu 08:00–10:00

    done

  4. Confirmation sent

    text and email

    done

Requested, held and confirmed in one conversation, from the times dispatch actually has.

What it books on its own, and what it doesn't

On its own

  • Offers times from the dispatch board's capacity
  • Holds a slot briefly while the customer decides
  • Confirms routine jobs your rules allow
  • Sends confirmations, reminders and changes

Asks dispatch

  • Emergencies and safety calls
  • Jobs needing two technicians or a special skill
  • Requests for a particular technician
  • Multi-visit and commercial jobs

Never

  • ✕ Confirms a time capacity doesn't have
  • ✕ Double-books a technician
  • ✕ Moves a confirmed job without telling the customer
  • ✕ Treats a request as a booking

What changes from one business to the next

Capacity sourceYour dispatch board or calendar, read live
Job types and durationsHow long each kind of visit takes, and who can do it
Booking rulesWhat customers can book themselves, and how far ahead
Holds and windowsHow long a hold lasts; arrival windows you promise
RemindersWhen they go, on which channel, and what cancels them

A common starting point is the scheduling or dispatch software you already use as the source of capacity, with Cal.com where there isn't one, n8n or Trigger.dev for the workflows, and PostgreSQL for appointment state your tools can't hold. These are starting candidates, not requirements.

Is a scheduling system the right fit?

Good fit

  • Appointments are booked by phone, online and by the office, and they collide.
  • Customers are told times before dispatch has agreed them.
  • Changes reach customers late, or not at all.

Avoid when

  • One person books everything from one calendar and it works.
  • Work is planned in long projects rather than visits.

How we'd approach it

Most of the early work is mapping your capacity, job types and durations, and the rules for holds and windows.

  1. 01

    Understand

    As much as the problem needs

    We map how the work runs today: who does what, which systems hold the records, and where it breaks.

  2. 02

    Design

    Decided before it's built

    Ownership, rules, integrations and exceptions, agreed with you and written down with acceptance criteria.

  3. 03

    Build

    Connected to what you use

    We build the scoped system, connect it to the tools you already run, and test it on the cases that matter.

Related systems

The capabilities underneath

Questions about scheduling systems

Does it replace our dispatch software?

No. Your dispatch board stays the source of capacity. The scheduling system offers times from it, holds and confirms through it, and keeps the customer in step with it.

Can customers book online?

For the job types you choose, inside your area and hours. Everything else becomes a request the office books.

How does it avoid double-booking?

Holds expire, and only dispatch, or a rule you've agreed for routine jobs, can confirm a time, always against live capacity.

What about emergencies?

They skip online booking entirely and go to the on-call line, by the same rules as intake.

Promise only the times you can keep

Tell us how appointments are booked and changed today. We'll show you where promises and the schedule drift apart.

Start a project