Booking Against Real Availability, Not a Form

This guide covers the four checks, what breaks without each, the integration each requires, how to handle unavailable information, and what to measure.

The four checks

The first two are the ones that cause visible damage. The third causes damage that looks like bad luck. The fourth is rarely checked at all and quietly produces no-shows that get attributed to the customer.

1. Vehicle still in stock

The most damaging gap in the list, because the failure happens in person.

A customer who drove 40 minutes to see a specific unit that sold two days ago has had an experience no apology recovers. And it is entirely preventable: the inventory feed exists, the system simply has to read it at the moment of offering rather than at the moment of reminding.

Two refinements matter in practice:

• Check again at confirmation. Inventory moves between booking and arrival. A unit that sells in between needs a proactive message, not a surprise.
• Have the alternative ready. If the vehicle is gone, the message that works names two comparable units rather than apologising and stopping.

2. A person is actually free

An appointment assigned to "sales" is assigned to nobody, and the customer discovers this on arrival.

The system needs the sales schedule — who is working, when, and who is already committed. Most stores have this in some form; the gap is usually that it does not reach the booking system because nobody scoped the integration.

3. The slot is not already taken

Double-booking is the quiet one. It does not look like a system failure; it looks like a busy Saturday. But the second customer waits, and waiting at arrival is the strongest predictor of a short visit.

This requires write access to whatever holds appointments, which is where the integration conversation stops being trivial — the distinction between read and write covered in what integration services contain.

4. They can realistically arrive

Rarely checked, cheaply fixed. If a customer is an hour away and it is 5:15pm, offering 6pm sets up a failure that will be recorded as a no-show.

The honest version is to say it: "That is about an hour from you — would 6:30 be easier, or would tomorrow morning work better?" Customers respond well to being treated as people with commutes.

What if the information is not available?

Most stores cannot supply all four immediately. The sequence that works:

Start with what you have. Inventory is usually the easiest feed to obtain and the highest-value check. Begin there.

Degrade honestly. If the system cannot see the sales schedule, it should not pretend to. "I'll get this confirmed with the team and come back to you within the hour" is a workable interim and it is honest. What is not workable is offering a confident time that nobody verified.

Never guess at inventory. The other three can be approximated for a while. This one cannot, because the failure is in person.

The order to build them

Illustrative sequencing, by damage prevented per unit of integration effort.

Order	Check	Effort	Damage prevented
1	Inventory	Low — read-only feed	Highest, and it happens in person
2	Sales schedule	Medium — read access	High
3	Double-booking	Higher — write access	Moderate, invisible until it compounds
4	Travel time	Very low — a question	Moderate, and misattributed to the customer

Note that check 4 costs almost nothing and is usually last to be implemented, because it is a conversational habit rather than an integration.

Where does availability-aware setting go wrong?

1. Checking at reminder time instead of at offer time. The booking was already wrong; the reminder just discovers it.

2. A nightly inventory sync. A unit that sold this morning is still bookable all day. Batch integration cannot support this, which is the same disqualifier that defeats 24/7 response claims.

3. Treating the sales calendar as optional. The most common scope cut, and it produces appointments nobody is expecting.

4. Offering a time outside store hours. It happens more than it should, and it is purely a configuration failure — as is the related habit of initiating contact at the wrong hour.

5. Not reconfirming inventory before arrival. Covered above and worth repeating, because it is the version customers remember.

6. Over-checking and offering nothing. A system so constrained it can only offer Tuesday at 2pm has optimised itself out of the job. Two options, always, even if the second is less ideal.

What should you measure?

Row five is the diagnostic nobody runs. If no-show rate rises sharply with distance and with late-in-day appointments, the system is booking people who were never going to make it, and that is a conversational fix rather than a technical one.

Frequently asked questions

What should an appointment-setting system check before offering a time?

Four things: that the vehicle is still in stock, that a specific person is working and free, that the slot is not already taken, and that the customer can realistically reach the store at that time. A system that verifies none of these is effectively a form with a confident tone.

What happens if the system books a vehicle that has sold?

The customer discovers it in person, after travelling, which is the most damaging failure in the category and the least recoverable. Inventory should be checked at the moment a time is offered and again before the appointment, with two comparable alternatives ready if the unit has gone.

Why does the sales schedule matter to an appointment system?

Because an appointment assigned to the team as a whole is assigned to nobody, and the customer finds that out on arrival. Reading the sales schedule is usually a modest integration, and it is the most commonly cut item in scope.

Can a nightly inventory sync support appointment setting?

No. A unit sold this morning remains bookable for the rest of the day under a batch sync, which guarantees the in-person failure the check exists to prevent. Inventory availability needs to be live, and the latency should be stated as a number in the scope.

How should travel time affect the appointment offered?

It should be raised conversationally. Offering 6pm to a customer an hour away at 5:15 sets up a failure that will later be recorded as a no-show. Saying so plainly and offering an alternative costs nothing and customers respond well to it.

What should the system do if it cannot see the sales schedule?

Say so and confirm separately — offering to come back within the hour with a confirmed time is honest and workable. What does not work is offering a confident time nobody verified, because the cost of that lands on the customer at arrival.

Is double-booking a serious problem?

It is a quiet one. It looks like a busy day rather than a system failure, but the second customer waits, and waiting at arrival is strongly associated with a shorter visit and a worse outcome. It only becomes visible once overlapping appointments per person are measured.

Can a system be too restrictive about availability?

Yes. One so constrained that it can only ever offer a single time has optimised itself out of usefulness. The target is two genuine options at every stage, even when the second is less ideal, because a choice between two is what customers actually answer.

Conclusion

• Four checks before offering: the car, the person, the slot, the journey.
• Inventory is first and non-negotiable, because that failure happens in person.
• A nightly sync cannot support this, regardless of how good the conversation is.
• Travel time costs nothing to check and its absence is misattributed to the customer.
• Always offer two options. A system that can only offer one has over-constrained itself.