CUSTOMERSees
- One service to pick, real times to choose
- Their confirmation + a link that manages it
- A reminder wave they can act on
Guest checkout is the default; no account wall.
PLATFORM · BOOKING ENGINE
A booking engine that understands the work around the booking.
"Tuesday at 3" looks like a one-line request. Behind it sit availability, buffers, staff, rooms, deposits, reminders and sync — and most tools let all of that leak. QUE's engine computes the whole chain, so the slot your customer books is a slot your operation can actually keep.
02 — THE FLOW
From “Can I book?” to “You're all set.”
A booking on QUE is a pipeline, not a form submission. Each stage is a step the engine walks — visibly, in order.
REQUESTCustomer picks a serviceThey choose the consult — the engine knows its length, buffer, lead time.
COMPUTEAvailability is computed, not listedWindows, blackouts, buffers, capacity and notice are intersected per staff member.
DECIDESlot reserved with a real lockDatabase-level reservation: two clicks on the same slot yield one confirmation.
NOTIFYThe right people are toldCustomer, staff and calendar sync update in one fan-out, each attempt logged.
03 — THE CUSTOMER'S SIDE
Make booking feel effortless. Keep it smart everywhere else.
The customer should never see the eight decisions from section 01. They see a service, real availability, and a confirmation they can manage on their own.
Guest checkout is the default — no account wall before a booking can happen. When a customer books, their confirmation arrives with a private link that lets them reschedule or cancel themselves, within the cancellation window you configured. If they later create an account with the same email, their history attaches automatically.
The booking flow itself is built to accessibility standards — keyboard navigable, screen-reader tested, with reduced-motion and large-text variants — because a booking tool that excludes people is not a booking tool.
For the customer, the whole engine collapses into one honest screen: pick a service, pick a time that is actually real, confirm. No waiting for a human to say yes, no discovery later that the room was never available. The confirmation email carries the details and the private management link, so the booking is theirs to manage — not the front desk's to babysit.
Simple for the person booking. Smart about everything behind the scenes.
04 — AVAILABILITY
Only show availability you can actually honor.
Most tools list availability — someone free, somewhere open, and hope the two agree. QUE computes it: every rule is intersected before a slot is ever offered.
A naive tool says
- Staff free at 2:30 → slot shows open
- No idea the 1:30 needs a 15-min turnover
- No idea room three is the only room the service fits
- Result: the impossible slot is bookable
QUE computes
- 2:30 is tested against every rule at once
- 1:30's buffer and turnover are blocking intervals
- Resource capacity rejects the overlap
- Result: the impossible slot is impossible by construction
Concretely, the engine reads the service's duration, the buffers before and after, the staff member's working windows, holidays and time off, the resource capacity of the room or equipment, the party size of the request, and the lead-time and notice windows — then walks candidate slots and accepts only the ones where the whole interval fits inside everything at once. What it returns is not a probability. It is an answer.
And because availability is computed rather than cached from someone's assumptions, the schedule you see on the wall and the schedule a customer can actually book are the same schedule. No one has to remember to reconcile the two — there is nothing to reconcile. External calendars stay honest for the same reason: they pull from the same record, so a meeting booked in Google cannot quietly collide with a slot the engine just promised.
Fewer promises your team has to fix later. That is the entire philosophy of the availability engine.
05 — BOOKING RULES
Turn the way your business works into booking rules.
Every policy your front desk already enforces by hand can live in the engine as a rule — and the engine applies it to every slot, every time, without remembering.
Service: Consultation — 60 min
Duration becomes the slot length; every candidate slot is 60 minutes.
Buffer: 15 min before · 10 min after
Each booking blocks 85 minutes of the calendar — including your turnover.
Lead time: 24h ahead · Cancel: 12h ahead
Today's 3:00 is closed to new bookings; the cancellation window is enforced.
Location: Room 2 — capacity 1
Nothing else can be placed in Room 2 while this booking stands.
Team: assigned practitioners only
Only practitioners tied to this service receive the slot.
These are not marketing examples — buffer_before_min, buffer_after_min, capacity, min_notice_minutes, booking_window_days, cancellation windows and assignment modes are real properties on QUE services. Set them once; every candidate slot is measured against them.
06 — THE FULL PICTURE
A good booking engine understands more than a clock.
A bookable moment is the product of seven inputs agreeing at the same time. Drop any one of them and the moment stops existing — that is not a limitation, that is the point.
The customerWho books, for how many
The serviceLength, buffer, price, questions
The timeWindows, blackouts, lead time
The peopleStaff eligibility and eligibility rules
The resourcesRooms, devices, capacity
The locationWhere it must happen
The rulesCancellations, deposits, notices
A bookable moment — only when every dimension agrees.If any dimension says no, the slot never exists. The denial lives in the computation, so no one ever has to deny it by hand.
07 — FOUR VIEWS, ONE RECORD
One booking. Everyone sees the part that matters to them.
Because every perspective reads the same booking record, no one has to ask what changed — the change is already where it belongs.
TEAMSees
- Their own bookings and the day ahead
- The change, where it happened
- A notification they don't have to chase
Assigned staff get the staff_notify event.
RESOURCEOccupies
- Room 2 for 85 minutes (60 + buffers)
- The laser device for the session window
- Capacity that excludes competing slots
Resources are blocking intervals, not labels.
OPERATORSees
- Every booking in one record
- The sync status, the dispatch log, the audit
- What changed and why — not a story to reconstruct
The database is the source of truth, always.
08 — WHEN REAL LIFE HAPPENS
Because real life changes the schedule.
A reschedule should not become someone's manual cleanup project. On QUE, changing a booking is one atomic operation that re-runs the whole pipeline.
The new time is re-validated against every rule — windows, buffers, capacity, notice — before the change is allowed. When it goes through, the customer's confirmation updates, the staff notification fires, the resource releases its old window and claims the new one, and the external calendar is rewritten through sync. The old slot never sits in a half-updated state: it is free or it is not, and the engine is never guessing.
Cancellation runs its own path: the cancellation window is enforced, any no-show or late-cancel policy applies, the calendar entry is removed, and the cancellation event notifies everyone it should. A waitlisted customer can then be offered the slot the moment it opens.
Every one of these transitions is a real state change on the booking record — confirmed, rescheduled, cancelled — with the full history readable afterward. When a week's worth of shuffling is done, you can see exactly what moved, when, and what the operation did about it.
The change is one operation. The cleanup is not a project.
Tuesday · 3:00 PMThe customer moves it to Wednesday 4:00
New slot testedWindows, buffers, capacity, notice — all re-checked
Wednesday · 4:00 PMCustomer, staff, resource and calendar all update
Cancellation runs its own path — the cancellation window, any no-show policy, the calendar removal and the cancellation notification are all enforced and logged. A change is one atomic operation; the cleanup is not a project.
09 — WHERE BOOKING LIVES
Put booking where your customers already are.
The same engine serves four surfaces. The flow never changes — only the door to it does.
/api/public/embed/{slug}.jsA script tag on any siteOne line of JavaScript drops the full booking flow into a page. The iframe resizes itself with postMessage — no fixed heights, no layout wrestling.
window.QueBooking.open()A button that opens the flowAny element becomes the book-now trigger. The booking opens in a modal the moment your customer wants it — not on another page.
fixed positionA persistent book buttonA floating action button lives at the edge of the page with your chosen label and color, ready the whole visit.
/u/{slug}/bookYour own booking URLEvery business gets a dedicated booking surface under its slug — the place management links, SMS and emails point to.
10 — STILL YOUR BUSINESS
Your booking experience should still feel like your business.
The engine carries the infrastructure. The surface carries your name.
Every business gets its own booking URL and its own widget — served from its slug, customizable with your label and your color, accepting your fonts through the host page. The popup, the floating button and the inline embed all inherit the frame you put them in. Customers experience your brand; QUE owns the machinery underneath.
This is the same division of labor as the product itself: the operational record stays authoritative and consistent, while the presentation layer stays yours.
Your team books through the same record your customers do — so branding never fractures the schedule. A booking taken through the website embed and a booking taken from the dashboard are the same object, with the same rules applied and the same history kept.
QUE infrastructure underneath, your customer-facing surface on top.
11 — AFTER THE CONFIRMATION
The booking doesn't disappear after confirmation.
Confirmation is the middle of the story, not the end. QUE keeps the booking alive as an operational record until it is closed — and the history is readable.
CreatedSerialized admission · lock issued
ConfirmedWaves planned · calendar pushed
UpdatedReschedule · cancellation · deposit
CompletedRecorded · follow-up prepared
Every notification attempt is logged — sent, failed, suppressed and why. Every state transition leaves an audit record. When a front-desk person asks “did the reminder go out?”, the answer is a line in the booking's record, not a log-file hunt.
That continuity is what makes the booking useful after the customer leaves. The same record drives the team calendar, staff assignments, resource windows, the reminder waves and the month-end review — so by the time the booking closes, nobody has had to ask “where did that booking go?”
12 — PERFORMANCE & RELIABILITY
Fast when it's easy. Correct when it's not.
The two things a booking engine must never trade against each other.
Serialized admission
Slot reservations are issued through a database function that holds a transaction-scoped lock and re-checks availability, capacity and quotas before writing. Two customers clicking the same slot at the same instant get one confirmation and one honest "just gone" response.
Idempotent planning
Reminder waves are planned, not fired — scheduled rows with unique idempotency keys per booking, role, channel and wave. The planner can run a hundred times; each wave still sends exactly once.
Honest dispatch
Notification sends carry retry attempts with backoff and a per-company rate cap, and every attempt — success, failure, suppression and its reason — is written to a log the console can query.
Sync resilience
When an external calendar provider is unreachable, QUE keeps booking against its own database as the source of truth. External events stop pulling, but nothing confirmed is un-confirmed — and reconciliation appears when the provider returns.
The full operational picture — queue behavior, retries, observability and failure handling — is documented in the QUE documentation.
13 — UNDER THE HOOD
A better booking experience needs a solid system underneath it.
Three layers, one direction of truth: the surface asks, the engine decides, the operations respond.
LAYER 1 — SURFACEBooking surface
Widget, popup, floating button or hosted URL — the same flow, delivered four ways.
LAYER 2 — THE ENGINEBooking engine
Availability computation, booking rules, resources, customers, reminders and state transitions — validated, serialized and idempotent.
AvailabilityRulesResourcesCustomersRemindersStates
LAYER 3 — OPERATIONSOperational system
Calendar sync, notification fan-out, webhooks, the audit trail. The engine feeds them; it never depends on them to be honest.
The surface never knows how the answer was computed. The operations never get to argue with it. The engine is the only place a booking becomes real — which is why it is also the only place a double-booking can be prevented.
14 — WHY IT MATTERS
What a disciplined engine does for the business.
No invented ROI here — these are the four things the engine removes or adds by construction.
Fewer booking mistakes
The impossible slot is impossible by construction. Buffers, capacity, rooms and blackouts are enforced before the offer is made — not discovered at the front desk.
Less manual coordination
Reschedules, cancellations and notifications are one atomic operation each. The work that used to live in chat threads now lives in the pipeline.
A better customer experience
Real availability, guest checkout, self-service change links and reminders that land. Customers trust a business that keeps what it promises.
More predictable operations
One authoritative record feeds the calendar, the notifications and the audit trail. Planning starts from facts instead of reconstruction.
15 — WHERE THIS IS GOING
The best booking experience is the one your team barely has to think about.
Every section on this page is a step toward the same destination: a booking that moves from request to done as a single, coherent event.
Customer request
Context assembled
Decision computed
Action executed
Done — no cleanup
Today the engine already does the computation, the rules, the state and the notifications. What remains is the same direction, walked further: deeper context, smarter routing, more of the routine decided before it reaches a human. The pipeline is built to carry that weight — the work is in adding decisions the engine already knows how to make.
The direction is not more screens or more toggles. It is fewer moments where the operation has to remember something. Every decision the engine takes on today — the buffer, the room, the notice window, the notification — is a decision a person previously had to make by hand. The roadmap keeps walking that line until the team's attention is reserved for the cases that genuinely need a human.
16 — HONEST ANSWERS
Questions evaluators ask.
How do you prevent double bookings under load?
Slot reservations are issued with a lock at the database level. Two people clicking the same slot at the same time gets one confirmation and one honest "that slot just went" message — the denial is built into the admission, not patched over it.
Can buffers differ by service?
Yes. Buffer, capacity, lead time and notice windows are per-service properties, applied alongside staff windows and location rules when availability is computed.
Does the booker work on our existing website?
Yes. One script tag delivers the booking flow inline, as a popup or as a floating button. The iframe resizes itself with postMessage and accepts your label and color.
What happens if a customer reschedules inside the cancellation window?
The new time is re-validated against all rules before the change applies. When it does, the customer's confirmation, the staff notification, the resource window and the calendar sync all update in one operation.
Do you support deposits and no-show policies?
Deposit amounts and percentages are real service properties, and cancellation windows with their policies are enforced when a booking is changed or cancelled through the private management link.
What happens during a calendar provider outage?
External events stop pulling, but QUE keeps booking against its own database — the source of truth. When the provider recovers, conflicts surface for reconciliation instead of silently corrupting the schedule.
Is the booking flow accessible?
Yes — WCAG 2.2 AA, keyboard navigable and screen-reader tested, with large-text and reduced-motion variants. Accessibility is part of the product's CI, not a side project.
What does the reminder system actually do?
Reminder waves are scheduled at booking time — confirmation, day-before and two-hours-before — for the customer, any appointee and the assigned staff. Each dispatch attempt is logged, retried with backoff, and rate-limited so your sender reputation stays intact.
THE NEXT STEP
Make every booking easier to keep.
The engine does the eight decisions no one should have to make by hand — so the slot you offer is the slot you can keep, and the promise you make is a promise you keep.