Two customers booked the same Saturday. Here's what actually broke.
Saturday, 9:55 a.m. A family with a toddler and a photographer is at the studio door, and so is a fashion crew with a rail of clothes. Both have confirmations. Walking back through how it happened shows that nobody did anything wrong, which is exactly the problem.
Double bookings on a marketplace rarely come from one bug. They come from treating a supplier's synced calendar as live truth, offering instant confirmation on availability that may be an hour old, sending conflict alerts to nobody in particular, and having no agreed plan for who gets the slot and who makes it right. Match the booking mode to how fresh each supplier's availability really is, hold slots briefly, route conflicts to a named person, and write the remedy down before you need it.
What happened
This is a composite. The studio, the people and the times are invented, but each piece of it is a common way for a booking marketplace to go wrong.
A marketplace lists photo studios for hourly rental. One studio, run by its owner, Arturo, takes bookings in three places: through the marketplace, through his own website, and by phone from regulars. His own calendar is the one he trusts. The marketplace pulls availability from that calendar on a schedule.
On Saturday at 9:55 a.m., two groups arrived for the 10 a.m. slot. One was a family with a toddler and a photographer for a portrait session, booked by phone. The other was a small fashion team with a rail of clothes and a lighting kit, booked through the marketplace. Both had confirmations. Arturo gave the slot to the family, who had booked first. The fashion team left, angry, and wrote a review that named the marketplace, not the studio.
The point of a post-mortem is to understand how the system made this possible, without hunting for someone to blame. So here's the timeline.
How the week unfolded
Tuesday, 7:30 p.m. The marketplace pulls Arturo's calendar. Saturday at 10 a.m. is open.
Tuesday, 7:58 p.m. A regular customer calls Arturo. He books the family's portrait session for Saturday at 10 a.m. and enters it in his calendar.
Tuesday, 8:10 p.m. The fashion team's producer finds the studio on the marketplace. The listing still shows Saturday at 10 a.m. as available. The listing offers instant booking. She books and pays, and gets a confirmation email within seconds.
Tuesday, 8:30 p.m. The next sync runs. The marketplace sees an event on Arturo's calendar overlapping a confirmed marketplace booking. It flags a conflict and sends an alert to a shared operations inbox.
Wednesday to Friday. The alert sits in the shared inbox among hundreds of routine messages. Everyone who reads that inbox assumes someone else handles calendar conflicts. Arturo isn't told. Neither customer is told.
Saturday, 9:55 a.m. Both groups arrive.
Sequence of work
Tuesday evening, as the system saw it
- 7:30 p.m.
Calendar sync runs. Saturday 10 a.m. shows open.
- 7:58 p.m.
Phone booking entered in the studio's own calendar.
- 8:10 p.m.
Marketplace instant-books the same slot on the 7:30 copy.
- 8:30 p.m.
Next sync spots the overlap and alerts a shared inbox.
- Saturday 9:55 a.m.
Both customers arrive. Nobody has been told.
The calendar sync worked exactly as designed. The design just assumed nobody would answer the phone.
What didn't cause it
It's tempting to say Arturo shouldn't have taken a phone booking. But taking bookings from his regulars is his business, and the marketplace knew he did it when it connected his calendar. It's tempting to blame the sync, but the sync did exactly what it was built to do: it found the conflict within half an hour. And the producer did nothing wrong at all. She booked an available slot and paid for it.
Each part behaved sensibly. The failure was in how the parts were put together. The calendar sync worked exactly as designed. The design just assumed nobody would answer the phone.
Why it happened
Looking back, four decisions made Saturday possible.
Availability was treated as a fact rather than a claim with an age. The listing showed the slot as available with the same confidence whether the calendar had been checked one minute or fifty-nine minutes earlier. The marketplace knew how old its information was. It just didn't use that knowledge.
Instant booking was offered on availability that couldn't support it. Instant confirmation is a promise. It's a safe promise when the marketplace's calendar is the master copy, or when it's connected to the supplier's system live. It's a risky one when the supplier takes bookings elsewhere and the marketplace only finds out on a schedule.
The conflict was detected and then handed to nobody. The system did the hard part, spotting the overlap, and then sent it to a place where no one person was responsible. A conflict three days before a booking is easy to fix. On the morning, it's a scene in a doorway.
There was no agreed remedy. When both groups showed up, nobody knew the rules. Who gets the slot? What does the other customer get, and who pays for it, the studio or the marketplace? Arturo made a fair call under pressure, but the fashion team had no idea what would happen next, and neither did support.
What we'd change
None of the fixes is exotic.
Choose a booking mode per supplier, based on how fresh their availability is. If the supplier manages bookings only in the marketplace, or the marketplace is connected to their system live, instant booking is fine. If the supplier also books elsewhere and you only sync periodically, use request-to-book: the customer asks, the supplier confirms within a set time, and the customer is told clearly that it isn't confirmed until then.
Hold, then confirm. Even with instant booking, check availability again at the moment of payment, not only when the page loaded. Where you can, place a short hold on the supplier's side before confirming.
Show freshness when it matters. For suppliers on periodic sync, "availability last checked at 7:30" or a softer "usually confirms within an hour" sets the right expectation.
Route every conflict to a named person with a deadline. Not a shared inbox. A queue with an owner, an alert to the supplier, and a rule that both customers hear from you within a set number of hours.
Write the remedy down. The first confirmed booking keeps the slot. The other customer gets a choice of alternative times or nearby studios, a full refund, and a credit for the trouble, funded according to terms the supplier agreed to when they joined. Support can offer that in one message instead of improvising.
A marketplace is a collection of promises, and availability is one of the first it makes. We wrote about mapping the other exceptions in catalog the exceptions before you automate the marketplace.
Decision guide
Instant booking vs. request-to-book
| Consideration | Instant booking | Request-to-book |
|---|---|---|
| Fits when | The marketplace calendar is the master, or connected live. | The supplier also books elsewhere and you sync on a schedule. |
| Customer is told | Confirmed now. | Requested; the supplier confirms within a set time. |
| Main risk | Promising a slot that's already gone. | Losing customers who won't wait. |
| Safeguard | Re-check at payment and hold the slot. | A short confirmation deadline and alternatives if declined. |
Questions for your own marketplace
If you run a booking marketplace, five questions will tell you how close you are to your own Saturday morning:
- For each supplier, where is the master calendar, and how old can your copy of it be?
- Which suppliers have instant booking switched on, and should they?
- When your system finds a conflict, who exactly is told, and by when must they act?
- What does a customer who loses a double-booked slot receive, and who pays for it?
- When did a conflict last happen, and how long did it take for both customers to hear from you?
If those answers are vague, that's where to start. We build the product and operating side of marketplaces, including the availability connections and the exception handling behind the booking button. If double bookings are costing you reviews, walk us through one and we'll trace it with you.
Related work: Spin:Market.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.