Why Notaray confirms a booking after the readback, not before

Notaray is being built to answer a small business’s inbound calls and book callers on the business’s real calendar. This entry explains one rule in that design: Notaray is designed to tell a caller “booked” after the readback, not before. It is a design rule, written as principle I of the Notaray constitution (rule R1). It is not a result. The product is still being built, so nothing here has been measured.

Why does Notaray confirm a booking after the readback, not before?

Writing a booking to a calendar and having a booking are different things. A write can fail, time out, land on a slot someone else just took, or be accepted and never show up. If the caller hears “you are booked” while the write is still in flight, the phone call has promised something the calendar may not hold. The caller then turns up for an appointment that does not exist, and the business finds out at the door.

So the rule reads, in plain words: no confirmation until the calendar returns a durable id for the event and a readback matches the time, the person and the status. Until both are true, the caller hears “requested”, not “booked”. The constitution calls a confirmation given before that point a sev-1 defect, which means it blocks every release.

What is a readback?

A readback is checking the calendar after writing to it, to see that the booking is there. Notaray is designed to look the event up by the id the calendar returned, then compare three things with what the caller asked for:

• The time: the date, the start and the end, in the right time zone.
• The party: who the booking is for.
• The status: confirmed, not tentative or cancelled.

If all three match, the booking is confirmed. If any one differs, it is not, and Notaray is designed to treat that as a problem to hand to a person rather than a detail to smooth over.

What does the caller hear while this happens?

The words on the call are meant to follow the state of the booking. While the write and the readback are in progress, and if either one does not finish, the caller hears that the request was received and that a named person will follow up. The word “booked” is kept for the moment the readback matches. This costs a few seconds of careful wording. It is meant to buy a confirmation that the business can check against its own calendar.

What happens if the calendar does not answer?

An unknown result is not treated as a success. In the design, a timeout or an unclear answer becomes a pending callback with a named owner and a deadline, and it stays pending until a readback matches or a person completes it. The check is also designed to keep running if the web request that started it ends, so a dropped connection does not turn into a silent guess.

What is not built yet?

Notaray is in development at Agnotiq. No business is using it yet, and there are no results to report. The readback, the pending callback and a record of each booking attempt are things Notaray is being built to do. We plan to write about each of them here as they are built, including the parts that turn out harder than expected.