There is a small, endlessly repeated wrongness in most scheduling software: it picks one noun and gives it to everybody.
A physiotherapist is told they have bookings. A restaurant is told it has appointments. A consultancy is told it has reservations. Each of them shrugs, because it is only a word, and then that word goes out in every confirmation, reminder and cancellation their customers receive, in a vocabulary the business itself would never use.
What is on the calendar is an event
The underlying thing is the same everywhere: a period of time, a person, sometimes a place. That is an event.
What differs is the word, and the word follows the industry:
| Business | What it is called | What it implies |
|---|---|---|
| Clinic, salon, workshop | Appointment | A time reserved for one person |
| Restaurant, hotel, venue | Reservation | Capacity held, often for a group |
| Agency, consultancy, B2B | Meeting | Two parties, a shared agenda |
| Software company | Demo | A meeting whose purpose is to show something |
So the software should hold events and be told which noun this business uses, rather than deciding on everybody's behalf. Once that is a field rather than a hardcoded string, the whole customer-facing surface can speak the right language: the booking page, the reminders, the cancellation flow, the reply an AI agent writes.
The trap is doing half of it. Translating the interface and leaving the automated messages alone means the business sees its own vocabulary while its customers get the software's.
A request is not a confirmation
The second distinction is more consequential than the vocabulary, because getting it wrong makes people turn up to nothing.
Some businesses publish exact slots and let customers take one: the customer picks, the time is held, it is confirmed. Others cannot work that way. A workshop does not know how long a job takes until it sees the car; a consultancy wants to know what the meeting is about before committing a partner. Those businesses want to receive a request and answer it.
Those are different states and the copy must never blur them:
- A confirmation says a time is held. It can say so plainly.
- A request says a preference has been recorded and the business will come back with a time. Nothing in it may sound like a confirmation.
This is the single easiest thing to get wrong, because the confirmation wording already exists and reusing it is one line of code. The result is a customer with a screenshot that says their appointment is booked, arriving at a business that never confirmed anything.
One live event at a time
A third rule that only shows up under real use: a customer should have one live event with a business at any moment.
Without it, somebody who books, then books again because they were not sure the first one worked, now has two slots. The business has lost an hour of capacity and will discover it when nobody arrives for the second.
So a new request from a customer who already has one live is a conflict, and it has to be shown as a choice: keep the existing one, or replace it. What it must never do is quietly cancel the first, because a cancellation the customer did not ask for is a cancellation they will not expect.
Summary
- The calendar holds events. The noun belongs to the business.
- Push the vocabulary all the way to the automated messages, or only the business sees it.
- Requests and confirmations are separate states with no shared sentences.
- One live event per customer, and cancelling is always something someone chose.
