Skip to main content
Menu

How it works

From a missed call to a booking you can check

Every request runs through four steps: understand it, check the real calendar, write the booking and read it back. The caller hears “confirmed” once your calendar shows the booking. Anything uncertain goes to a named person with a deadline. It’s almost here, and design partners get in early.

Request early access
  1. Request understoodTime, service and details captured
  2. Calendar checkedThe real calendar, not a guess
  3. One booking writtenA single bounded attempt
  4. Read backCompared with the request
Confirmed

When the calendar shows it.

Needs follow-up

A named person, with a deadline.

Illustrative workflow

Four steps, no guessing

  1. Understand the request

    Capture the requested time, the service and the details needed to act, under the business’s own rules.

  2. Check the calendar

    Look at the real destination calendar before promising anything. A suggested slot is not a reservation.

  3. Write one booking

    One bounded attempt with a stable key, so a repeated request finds the original result instead of booking twice.

  4. Read it back

    Ask the calendar what it now holds and compare it with the request. That comparison alone decides the outcome.

One outcome, four views

The same request as the caller, the calendar, the receipt and the owner would see it.

  1. What the caller heard

    “I’ve asked for Tuesday at 2:30 PM. I’ll confirm as soon as the calendar shows it.”

    Requested

  2. What the calendar shows

    Tuesday

    • 1:00 PM
    • 2:30 PMService visit
    • 4:00 PM

    Verified in calendar

  3. The receipt

    Requested
    Service visit, Tuesday 2:30 PM
    Calendar checked
    The slot was free
    Written
    Event ID returned by the calendar
    Read back
    Matches the request

    Confirmed

  4. Owner, if pending

    Shown when the calendar does not confirm the booking.

    Owner
    Front desk
    Deadline
    Today, 4:00 PM
    Original request
    Service visit, Tuesday 2:30 PM

    Needs follow-up

Illustrative workflow

Two outcomes. No in-between.

Confirmed: the calendar returned an identifier and the read-back matched the request. That’s the moment the caller hears “confirmed”, not a second earlier.

Pending: the result couldn’t be verified. The request goes to a named person with a deadline and the original context, and the caller hears that it was requested.

The rules behind the steps

  • Notaray is built to confirm a booking after the calendar shows it, not before.

  • Notaray is built so that a proposed booking is not treated as booked until the calendar confirms it.

  • Notaray is built so that a retried request returns the original outcome instead of booking twice.

  • Notaray is built so that every finished booking attempt leaves a receipt.

  • Notaray is built so that a booking it cannot confirm becomes a callback with an owner and a deadline.

One rulebook for every channel

An API call, browser voice and phone will all run on the same booking rules. There’s no path from audio straight to a calendar write.

Phone and voice are on the way. Their page shows exactly where they stand.

Tell us where your bookings need to land.

Design partners tell us how requests arrive and which calendar holds the truth. Spots are limited.

Request early access