Lumina Sales is live.See it

Text the caller what you booked

6 min read

By Lumina Software

  • Voice AI
  • Service business
  • Operations
  • Customer communication

A phone call is a bad place to store information. The caller hangs up, and everything they just agreed to lives in their memory and in a record they cannot see. If they misheard the day, they find out when nobody shows up. If the agent misheard the address, they find out when the tech calls from the wrong street.

The fix we put in almost every voice reception system we build is simple. Within a minute of the call ending, the caller gets a short text that says what was booked, and they can reply to it if something is wrong. It is cheap to send and catches mistakes while they are still cheap to fix.

This post covers what goes in that text, when to send it, how to handle replies, and the few places it tends to go wrong.

Why send a text after the call

A good phone agent reads details back before it books. We still send the text, because reading back only checks what the caller heard in the moment. People agree to things on the phone while driving, while holding a kid, or while their dog is barking at the door. "Thursday at two" sounds right until they look at their calendar that night.

A text gives the caller a second look, on their own time, in writing. It also gives them something to find later. When they want to know what time the tech is coming, they scroll back to the text instead of calling the office again.

For the business, the text is a cheap check on the agent. If a misheard address gets corrected by a reply an hour after the call, that is a five minute fix in the office. The same mistake found by the tech at the curb costs a wasted trip.

What goes in the text

Keep it short enough to read on a lock screen. Long texts get skimmed, and the important line gets missed. We usually include:

  • The business name first. The caller just spoke to an agent. They may not connect a text from an unfamiliar number with that call unless the name is right at the start.
  • What was booked. "Drain cleaning" or "AC not cooling, diagnostic visit." Use the words the caller would recognize, not an internal job code.
  • The day and the arrival window. Write the day of the week and the date. "Thu Oct 22, between 1 and 3 pm" is harder to misread than "10/22 1300."
  • The address. This is the detail most worth checking. Street number and street name are enough. Leave out anything the caller did not give you.
  • One clear next step. "Reply here if anything is wrong" or "Reply C to change or cancel." Pick one. Two or three options in one text tend to confuse people.

Here is a version close to what we start with:

"Hi Dana, this is Example Plumbing. You're booked for drain cleaning on Thu Oct 22, arrival between 1 and 3 pm, at 418 Maple St. Reply here if anything is wrong."

The name and details in that example are made up. The shape is the part to copy.

What to leave out matters as much. Do not put prices in the confirmation unless the business already quotes fixed prices on the phone. Do not include internal notes like gate codes or "customer was upset." Texts get forwarded and read by other people in the house. Treat the text as something anyone could see.

When to send it

Send it right after the call ends, not hours later. The goal is to catch the caller while they still remember the conversation and have the phone in their hand.

The text should also come from the record, not from the transcript. If the agent says "Thursday" on the call but the booking got saved as Tuesday, a text built from the transcript will say Thursday and look correct. A text built from the saved booking will say Tuesday, and the caller will catch it. That is the whole point. Send what the system actually stored.

For calls that did not end in a booking, the text is different but still useful. If the agent took a message for staff, the text says that a message was taken and when to expect a callback. "We got your message and someone will call you back today before 5 pm" sets an expectation and gives the caller a way to add details. Only promise a callback time that someone is actually watching for.

Handling replies

This is where most setups fall apart. The business sends a nice confirmation that says "reply here," and the replies go to a number nobody checks. A caller who writes "wrong address, it's 481 not 418" and hears nothing back is worse off than if they never got the text, because now they think it was fixed.

Before turning confirmations on, decide where replies go and who reads them. The options we see most often:

Replies land in the same inbox the office already uses. If the team already works from a shared text inbox or a field service app, send replies there. Do not add a new place to check.

Replies trigger a task. A reply on a confirmation creates a task or flag on the booking, so the dispatcher sees it next to the job it belongs to. This works well when the team lives in the schedule view.

Simple replies get handled automatically. A reply like "C" or "cancel" can open the cancel flow, as long as the system confirms back what it did. Anything else goes to a person. We keep the automatic part narrow on purpose. A model that tries to interpret every reply will eventually move a booking that should not have moved.

Whatever you pick, test it the way a customer would. Book a fake job, reply to the confirmation with a correction, and see how long it takes for someone on the team to notice.

Where it goes wrong

A few problems come up often enough to plan for.

The number on file is a landline. Some callers give an office or home landline. The text never arrives, and nobody knows. Most texting providers can tell you whether a number can receive texts. If it cannot, flag the booking so the office calls to confirm instead.

The text goes out before the booking is final. If the system sends confirmations the moment the agent says "you're booked," a booking that fails to save still gets a confirmation. Send after the record is written, and only then.

Rescheduled jobs send two confirmations. If a job moves, the old confirmation is still sitting in the caller's messages. The new text should say clearly that it replaces the old one: "Your visit has moved to Fri Oct 23." Do not send a second text that looks like a second booking.

Opt outs get ignored. Callers who reply STOP should stop getting texts, and the system needs to remember that the next time they call. Rules for business texting, consent, and opt outs differ by country and carrier, so set this up with your texting provider and whoever handles compliance for your business.

Start with one call type

You do not need confirmations on every call on day one. Pick the most common booking type, write one template, send it from the saved record, and route replies to a place your team already checks.

Run it for two weeks and read every reply that comes in. The replies tell you exactly which details the agent gets wrong, in the caller's own words. That is a better list of fixes than most test plans, and it comes from the people who actually depend on the booking being right.

Written by Lumina Software. Have a question? Book a call

Keep reading