A correct error can still be a poor conversation

A customer can ask for a time that the system understands perfectly but cannot accept. Perhaps the callback window ends then, the duration does not fit, or a slot was just booked.

Replying “that is unavailable” is technically correct. It also hands the work back to the customer.

The response I wanted

An unavailable request should answer two questions: why it could not be used, and what is actually available instead. The alternatives must come from the same availability logic used for a final booking.

Depending on the request, that might mean nearby options on the same day, the next chronological slots, or choices that match a requested part of the day. Same-day recovery is particularly useful: if noon is invalid, a last viable morning option and a first afternoon option can keep the intent intact.

understand requested time
→ validate against real availability
→ explain the constraint
→ offer valid alternatives

Keep the conversation in context

An invalid appointment request should not drop the lead back into qualification. The customer is still trying to arrange a time. The next message should therefore be interpreted as a slot selection, another request, a request for more options, or a cancellation or reschedule action.

Maintaining that context is as important as finding alternatives. Without it, a helpful fallback can be overwritten by a different branch of the conversation.

What I learned

Fallback behaviour is product behaviour. A safe fallback does more than prevent failure: it preserves the person's intent and gives them a clear next action.

What should happen next

I want to compare several selection strategies—closest first, same-day first, and balanced morning/afternoon options—against actual conversation outcomes. The best fallback should be helpful without becoming unnecessarily verbose.