Automated booking: the availability problem nobody warns you about

The demo version of automated booking is straightforward. Somebody asks for a slot, the system looks at a calendar, offers three times, and writes the chosen one back. It works perfectly on a calendar with nothing in it.

Real diaries are harder, and the difficulty is not the messaging. It is that "is Thursday at ten available?" is a question about several resources at once, about work that takes a variable length of time, and about commitments that exist in somebody's head rather than in the calendar. Getting that model right is most of the job.

What we'll cover

• What a slot actually requires
• Duration is not a constant
• Buffers, and the work around the work
• The double-booking window
• Building it with CodeWords
• What the calendar does not know
• When nothing fits
• Cancellations and the short-notice list
• What must never be booked automatically
• Making it survive
• Limits worth knowing about
• What to model first
• Frequently asked questions

What a slot actually requires

Availability is usually treated as one dimension, time, and it rarely is.

A person, and often a specific one. Not anybody, but somebody qualified for this particular work, or the one this customer always sees.

A place. A bay, a chair, a room, a table. Two staff free with one room between them is one slot.

Equipment. The lift, the machine, the scanner. Shared, and frequently invisible in any calendar.

Something to work on. A part that has to arrive, a material in stock, a result back from somewhere else.

A slot exists where all of these coincide. A system modelling only the person will confidently offer times that cannot happen, and the resulting phone call to unbook somebody is worse than never having offered.

Start by writing down, for your two most common jobs, everything that must be free simultaneously. It is usually a shorter list than people fear and a longer one than any calendar holds.

Duration is not a constant

The second thing that breaks naive booking is treating every job as a fixed block.

Most service work varies by what it is, who is doing it, and who it is for. The same task takes longer for a first-time customer than a regular. Some jobs are genuinely unknown until somebody looks.

Three workable approaches, in increasing order of effort.

Book by category with honest durations. Use your actual average, not your optimistic one. Most diaries run late because the durations were set by somebody remembering the best case.

Book an assessment rather than the job, where the work is genuinely unknown. A short diagnostic slot that produces a real quote is better than a long speculative booking that is wrong in both directions.

Vary by known factors the system can see, such as new versus returning, or the specific service requested.

The failure to avoid is a single default duration applied to everything, which makes the morning run early and the afternoon run late every single day.

Buffers, and the work around the work

Diaries fall apart because the calendar records the appointment and not the work surrounding it.

Cleaning down, writing notes, moving a vehicle, setting up, the conversation at the end that always happens. None of it is in the calendar and all of it takes time, which is why a fully booked day in the system is an overbooked day in reality.

Put the buffer in the model rather than hoping. A short gap after each appointment, longer after the ones that always overrun, and a genuine break that cannot be booked over. An automation that can see the buffer will protect it. One that cannot will fill it, every time, because it looks like free space.

The double-booking window

A subtle failure worth designing for explicitly.

Between offering a slot and the customer accepting, the slot is not booked. Two people offered the same time will both accept it, and somebody has to be told they cannot have it. At low volume this happens occasionally. As volume grows it becomes routine.

The fix is a hold. When a slot is offered, mark it provisionally taken for a short period, release it if nothing comes back, and confirm properly on acceptance. Minutes rather than hours, since a hold that lasts too long makes the diary look fuller than it is.

Then handle the case where it still happens, because it will. Acknowledge quickly, apologise plainly, and offer the nearest alternatives in the same message.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: what each job type needs, how long it really takes, the buffers, and what should never be booked without a person.
3. Authorize the connections to your diary or management system and your WhatsApp Business Platform account.
4. Describe the exceptions: a held slot that expires, a job nobody can price, a customer asking for somebody specific, a request outside opening hours.
5. Run it read-only for a fortnight first, proposing bookings a person confirms, and count how often it would have offered something impossible.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

What the calendar does not know

Every business runs on constraints that were never written down, and an automation will violate all of them on day one.

The Tuesday morning nobody books because of a standing delivery. The fact that two particular jobs cannot run at once. The customer who must not be given the last slot of the day. The staff member who leaves early on Fridays. The work that cannot start after three because it will not finish.

Collect these before going live by asking the people who run the diary what they would never do. You will get a list in ten minutes that no amount of calendar reading would have produced.

Then encode them as rules and expect to add more for several months, because these surface only when something violates them.

When nothing fits

The most common real outcome, and the one most implementations handle worst.

A good response does three things. It says plainly that the requested time is not available. It offers the nearest genuine alternatives, with enough of them to be useful. And it offers a route for somebody who cannot take any of them, which means a person rather than a loop.

What to avoid is an endless negotiation where the system asks for another preference each time. After two unsuccessful rounds, hand it to a human, who can see the whole diary and make the judgement an automation should not.

Record these. A pattern of requests you cannot satisfy is the most useful capacity information you will get, and it is invisible unless you log it.

Cancellations and the short-notice list

A cancellation is the one moment where automation clearly beats a person, because it requires acting immediately and the person is busy.

When a slot frees, there is usually somebody who wanted an earlier appointment. Offering it to them straight away converts a loss into a filled slot. Maintaining that list by hand does not happen on a busy morning, and that is exactly when cancellations occur.

Keep it simple: who wanted earlier, what for, and in what window they can come. Offer to the best match first with a short window to accept, then move on.

What must never be booked automatically

Anything where the customer has described a problem needing assessment. Book the assessment rather than the job.

Anything with a pricing question attached. A customer who agrees to a slot believing a price they were not quoted arrives expecting it.

Anything at the edge of capability. Work only one person can do, or that needs equipment currently uncertain.

Anything following a complaint. That conversation starts with a person.

Anything where the record is unclear. A returning customer whose history does not match what they are describing needs somebody to look.

Making it survive

Re-time your job durations annually against what actually happened.

Keep the unwritten rules written down, and add to the list as they surface.

Hold offered slots and expire them quickly.

Log the requests you could not fill, which is your capacity data.

Check the diary the automation sees matches the one your staff see, since two views drifting apart produces failures nobody can reproduce.

Limits worth knowing about

A booking system cannot create capacity. Filling the diary better is worth a great deal; adding hours is not on offer.

Some jobs genuinely cannot be scheduled sight unseen, and pretending otherwise produces a bad morning.

Calendar integration is the easy half. The resource model is the work.

Held slots hide capacity if the hold is too long.

Customers will book the wrong thing when the options are described in your language rather than theirs.

What to model first

For your two most common jobs, everything that must be free at the same time: the person, the place, the equipment, the materials. Write it down before touching any integration. Almost every automated booking failure traces back to a resource that was not in the model.

Two habits make the difference. Use your real durations rather than your optimistic ones, since a day built on best cases runs late from ten in the morning onwards. And ask whoever runs the diary what they would never do, because that ten-minute conversation contains rules no calendar will ever tell you.

Frequently asked questions

Why do automated booking systems offer impossible slots?

Because they model time and one person, while a real slot needs a qualified person, a place, any shared equipment and the materials, all free at once. Anything missing from the model gets offered anyway.

How should job duration be handled?

Use honest averages by category rather than optimistic ones, book an assessment where the work is genuinely unknown, and vary by factors the system can see such as new versus returning customers.

What are buffers and why do they matter?

The work around the work: cleaning down, notes, setup, the conversation at the end. It is not in the calendar and it takes time, so an automation that cannot see it will book over it every time.

What is the double-booking window?

The gap between offering a slot and the customer accepting, during which somebody else can take it. Hold offered slots for a short period and release them if nothing comes back.

How should the system respond when nothing fits?

Say so plainly, offer the nearest genuine alternatives, and hand to a person after two unsuccessful rounds rather than looping. Log the request, because unfillable requests are your best capacity data.

What about the rules that are not in the calendar?

Ask whoever runs the diary what they would never do. You will get a list in ten minutes that no amount of calendar reading would produce, and you will keep adding to it for months.

Can cancellations be handled automatically?

This is where automation clearly wins, because filling a freed slot needs immediate action at exactly the moment staff are busy. Keep a short list of who wanted earlier and offer with a brief window to accept.

What should never be booked without a person?

Work needing assessment first, anything with an unresolved pricing question, work at the edge of your capability, anything following a complaint, and anything where the customer's account does not match the record.

How do I test this before going live?

Run it read-only for a fortnight, proposing bookings a person confirms, and count how often it would have offered something impossible. That number tells you what is missing from the model.

Does automated booking add capacity?

No. It fills the diary better, responds at hours when nobody is there, and recovers cancellations. The number of hours available is unchanged.

Related reading

• The conversation design of booking
• The edge cases that actually matter
• Testing it before customers do