Map the messages before choosing timings
Most service businesses need a small, predictable set of booking messages. Write down which ones you actually need:
| Message | Triggered by | Purpose | Usually automated? |
|---|---|---|---|
| Request received | Customer submits a booking request | Receipt; says a person will confirm | Yes |
| Booking confirmed | Staff or tool confirms the slot | Date, time window, address, what to prepare | Yes, after confirmation |
| Reminder | Scheduled time before the appointment | Reduce no-shows; offer a way to reschedule | Yes |
| On the way | Technician starts travel | Arrival estimate | Sometimes; needs reliable status |
| Rescheduled or cancelled | Status change | New details or confirmation of cancellation | Yes |
| Follow-up | Job marked complete | Thank you, invoice link or care instructions | Yes, with review |
The important distinction is between a *request* and a *confirmed booking*. If your process needs a person to check feasibility, the first message must say "requested", not "booked".
What each message should contain
- Date, time and timezone, written out ("Tuesday 14 January, 2–4 p.m."), not only a calendar code.
- Where — the service address for on-site work, or your address for in-shop work.
- What the customer needs to do — clear access, have the model number ready, pets secured.
- How to change it — a link or number, and any rescheduling terms you have actually agreed.
- Who to contact — a monitored number or inbox.
Avoid adding marketing offers to confirmations and reminders. Keeping them about the appointment keeps them clearly transactional; see transactional vs marketing messages.
Email, text or both
Email is cheap and holds detail well. Text messages are more likely to be seen quickly but carry consent and registration requirements in many countries; in the US, business texting typically runs through registered programmes such as A2P 10DLC. Read text message reminders: consent and opt-out basics before switching texts on.
Decisions that should stay with a person
- Whether a requested slot is actually feasible.
- Whether to charge a late-cancellation fee, and whether to waive it.
- Squeezing in urgent jobs or bumping other customers.
- Responding to a customer who replies to a reminder with a complaint or a question.
The automation can flag these situations — for example, notify the office when a customer cancels within 24 hours — but should not act on them alone.
Test checklist
- A request and a confirmed booking produce different messages.
- Times appear correctly for a customer in a different timezone, and across a daylight-saving change.
- Rescheduling cancels the old reminder and schedules a new one.
- Cancelling stops all future reminders.
- Replies reach a person.
- Messages render readably on a phone.
Reschedules and timezone changes are where most reminder systems fail; the next guide covers them in detail: reschedules, cancellations and timezones.
Questions
How many reminders should I send?
Start with one reminder at a time that gives the customer a realistic chance to reschedule, such as the day before, and only add another if your own records show it helps. More messages can feel like pressure.
Can the booking tool confirm jobs automatically?
It can confirm a time slot it controls. Whether a job is feasible — parts, travel, scope — is often a human decision. Be clear in the message about which one the customer is getting.
Sources and further reading
- A2P 10DLC twilio.com
Official documentation changes. Check the current version before you rely on a rule, limit or setting.
Next step
Start with one workflow worth fixing.
Bring the real steps, the tools you already use and the place the handoff gets stuck. We review feasibility, access and approval points before quoting — no instant integration promise.
See Business Automations for what we scope, or prepare a custom quote brief.