There is a version of appointment messaging where the customer gets seven texts about a haircut. It comes from a good instinct — nobody wants a no-show — and it produces the opposite result. People stop reading, and the one message that mattered goes past unopened with the rest.
Four messages cover it. Before the four, the test that decides everything else: a message either leaves a record the customer will go back and look for, or it asks them to do something. Anything that does neither is noise you pay for — in attention when it is email, in money when it is a text. Two of the four are records, two are asks, and getting that backwards is how a business ends up sending its address by text, 160 characters at a time, and its reminder to an inbox nobody opens on the way to work.
1. The confirmation, immediately
Sent the second the booking is made, while the customer is still looking at the screen. Its job is not to say thank you. Its job is to be the thing they search their inbox for at 8am on the day.
What it has to contain, in the first two lines rather than under a banner:
- the date and start time, written out rather than abbreviated
- what they booked, in the words they chose it by
- where — the full address, not the branch name
- a reference they can quote on the phone
- if money moved: what was paid, and what is left
- one line of policy — the notice window, beside the way to change the booking
The reference is the part most systems get wrong: a booking needs a short number a human can read out loud, not a database identifier. We shipped that late ourselves. Appointments carried a per-business sequential number for months while the confirmation email still named a booking only by its date, so a customer ringing to move it had nothing to quote and the person answering had nothing to search.
When it is missed, two things fail at once. The mistyped date is not caught while it is still cheap — the customer meant Thursday, tapped Tuesday, and finds out on Tuesday. And there is no searchable record, which produces the 8am "what time was I again?" call. Most businesses read those calls as friendliness. They are a confirmation that was never sent, or could not be found.
Email, not text. This is the longest of the four and the one people archive: it carries the address, the policy, a deposit line and an attachment, and it costs nothing to send.
2. The reminder, once — occasionally twice
A day before is the standard, and the standard is right for most trades. It exists to catch the person who booked three weeks ago and has since made other plans — so the design rule matters more than the timing. A reminder must let the person act. Telling somebody whose Thursday has fallen apart that they have an appointment tomorrow produces a no-show you knew about in advance and could do nothing with. The same message that lets them move it produces a freed slot by dinnertime, and a freed slot is one you can still sell.
A second reminder is defensible for long or expensive work — a full-day detail, a treatment with preparation, a first session booked six weeks out. A day before, and again on the morning. Beyond that you are training people to ignore your messages, and the training works. VoltsBook ships reminders at 24 hours, 6 hours and 1 hour as separate switches, in email and text: three exist because three trades need different ones, not because one business should run all three.
Two details only surface once this is live. A "24 hours before" reminder should be 1,440 minutes of real time rather than yesterday at this hour on the wall clock, so that a customer either side of a daylight-saving boundary gets a full day of notice instead of 23 hours. And a reminder whose moment has already passed is a real decision: a booking made 30 minutes before it starts should still get its 1-hour reminder, while a booking made a week after its 24-hour moment should send nothing.
When it is missed, you find out at the appointment — the only one of the four whose absence stays invisible until the chair is empty. Send it by text, where you have a number that is used: it has to be seen within the hour, which is what a text is for.
3. The change, when something changes
Rescheduled, cancelled, moved to another person, moved to another room. This is the message businesses most often send by hand and most often forget on a busy day, which is exactly why it should be automatic.
What it has to contain is the difference. "Your appointment has been updated" is worse than sending nothing, because it costs the customer a phone call to find out what changed. Name the old time and the new one in the same sentence; if the person changed, say who, before the customer arrives and finds a stranger holding the clippers.
The rule that matters: the message goes out when the record changes, not when someone remembers. A change made at 4pm and sent at 6pm is two hours in which the customer was arranging their day around the old one. When it is missed, they turn up at the old time, and the fault is unambiguously yours — the only one of the four where the missing message creates the problem rather than failing to prevent it. Text: urgency is the entire point of this one.
4. The receipt, when money moves
Deposit taken, paid in full, refund issued. Separate from the confirmation, because the two answer different questions and get looked for at different times — one before the appointment, one at the end of the quarter.
It needs the amount, what it was for, what is still owed, and the same reference the confirmation used. A deposit receipt that does not say what is left to pay generates a call on the day, which is the exact call the confirmation existed to prevent. Email, always — nobody searches their messages in January for what they spent in September, and this is the one that can carry an invoice as an attachment.
The one-segment budget
Here is the constraint that quietly shapes every text you send, and that almost nobody is told about when they switch texting on.
A text is billed in segments, not messages. A message in the GSM-7 alphabet — the plain Latin set, the digits, a short list of punctuation — fits 160 characters in one segment. Go over and it splits, and each part of a split message carries a header that drops the ceiling to 153 characters.
The trap is the alphabet, not the length. One character outside GSM-7 re-encodes the whole message into UCS-2, which drops the ceiling from 160 characters to 70. Not the offending character — the whole message. An emoji, a curly apostrophe pasted out of a word processor, an en dash your editor helpfully substituted: any one of them doubles the bill for every send of that template, for as long as it stays there.
We shipped exactly that in our own defaults. Both ready-made reminder texts carried an em dash, purely as typography, until we measured the encoding of the rendered body in August 2026 — so every business that had switched a reminder text on and never looked at it was paying two segments to send one sentence. The templates are plain ASCII now, and a test measures what actually renders rather than what the template looks like, because the placeholders expand at send time: a business name with a curly apostrophe in it re-encodes a message that was clean when it was written.
The practical shape falls straight out of the arithmetic: the business name, the service, the time and the reference fit in one segment; the address does not. So the text carries the ask and the email carries the record. Two things to price in — every recipient is billed separately, so texting the customer and the staff member is two sends; and a placeholder that expands to something long, like a service called Full Interior and Exterior Detail with Ceramic Top-Up, can push a template that fitted in testing over the line in production. Count the segments on your longest service name, not your shortest.
Two failures no demo shows you
Sending is a background job, and background jobs retry. A job that sends and then fails while recording that it sent will, on a naive system, send again — and a customer who gets the same reminder three times concludes you are broken. Ask how duplicates are prevented; VoltsBook claims a message in its own log before it goes out, and the claim is unique, so a retry finds it taken and stops.
Then ask what the delivery log says when the mail server is not configured. Ours used to record a message as sent, stamp a delivery time and debit the business's email allowance — for mail that reached nobody. It refuses now, writes a skipped row naming the reason, and bills nothing. A delivery log that agrees with reality beats one with a good success rate.
Where to start
Switch them on in the order of payoff, which is the order above: confirmation email, then the day-before reminder, then the change message, then the receipt. A new VoltsBook business starts with the first two on and everything else off, which is the smallest honest set. Then stop — the fifth message is where a good system starts costing you the first four.
Messaging is the memory layer of a larger machine: deposits create the commitment the reminder protects, an easy exit turns changed plans into notice you can still sell, and a waiting list picks up what falls through anyway. The whole system is in the-no-show-playbook; the version to work through with the settings screen open is how-to-stop-no-shows.
How many reminders should I send?
One, the day before, for most trades. A second on the morning is defensible for long or expensive appointments where the loss is large. Past two you are training customers to ignore your messages, and it works.
Should reminders be email or text?
Text, where you have a number that is actually used — a reminder has to be seen within the hour. Keep the confirmation and the receipt on email: they are records people search for later, and both are far too long for one text segment.
Why is my text bill higher than the number of texts I sent?
Texts are billed in segments, not messages. A message over 160 characters splits into parts of 153, and one character outside the GSM-7 alphabet — an emoji, a curly apostrophe, an em dash — re-encodes the whole message and drops the limit to 70. Check the encoding of the rendered message, not of the template.
