ChatGPT
Claude
Google AI
Copilot
The text said Thursday. It did not say when on Thursday. The customer called to ask, which was the call the reminder was meant to prevent, and they were annoyed that the text had created the question. The appointment was still "sometime." The part was not confirmed. The skill on the work order was blank. The message had gone out because a flow fired when a date field was filled, and a date without a window is not a promise.
People still search for appointment reminders in FSL. FSL is Field Service Lightning. The help page has a current name and a current tool, in one sentence.
"Take Agentforce Field Service and Operations (formerly Field Service) to the next level with tools like Appointment Assistant, Visual Remote Assistant, and Workforce Scheduling." Appointment Assistant is the name to use for this problem. Visual Remote Assistant and Workforce Scheduling are named beside it. This article does not invent what those two do. It stays on reminders.
The thing you are reminding them about is a work order. "Schedule one-time or recurring work orders for customers, and add details about worker preferences, required skills, and parts." If those details are empty, the reminder is a promise you have not made yet.
Confirm the window, then remind
A reminder is a statement that a person will arrive in a window you are willing to keep. If the appointment is still "Thursday, sometime," do not send it. The customer will call to ask when. You will have spent a message to create the question, and you will have trained them to treat the next message as incomplete too.
Confirm means a start and an end a dispatcher would defend, on a job that has the skill and, where it matters, the parts. Customer preferences belong in that check. If the site only accepts morning access, a reminder for the afternoon is a confident mistake. If induction takes forty minutes and the window is thirty, the window is a lie. Widen it or do not send.
Who confirms is a named role, not "the system." The system can send. A person, or a rule a person wrote and still owns, decides the window is real. When the rule is wrong, that person changes it. An unowned flow that sends on any populated date will send for holds, for drafts, and for jobs nobody has staffed. The flow is obedient. The date was not a decision.
When the window moves, the old reminder is wrong. Send the change. Do not leave the first message as the one the customer believes. A second message that does not say it replaces the first will be read as a second visit. Say that the earlier window is no longer the one you are keeping, and say the new start and the new end. One correction. Not a thread of maybes.
What the message has to contain
The day, the window, what the visit is for, and what you need from them: access, a parking note, someone on site. Pull that from the work order. Do not let a template say "our technician" with no context, and do not let it invent a technician name you might still change. A name you retract is worse than no name. The customer tells the household who is coming. The household then refuses the person who actually arrives.
Required skills and parts are how you know the visit you described is the visit that will happen. A reminder that says "service" when the van is coming to quote, or the other way around, creates the same call. If the part is not confirmed, do not confirm the window. Hold the message. The hold can be a sentence a person says. It should not be an automated confirmation.
Keep the wording short enough to read on a phone in a hallway. One change of time, one sentence about what you need at the door. A brochure in the reminder trains people to ignore the lot, including the sentence that mattered. If legal wording is required, put it where it does not bury the window. The window is the point of the message. Everything else is how you miss it.
Preferences that change the visit should be reflected, not contradicted. A site that asked for morning access should not be reminded of an afternoon arrival because the template ignores the preference field. Read the preference before you send. If the scheduled window breaks it, fix the window. Do not paper over it with a friendly sentence.
Do not start with a texting vendor
Appointment Assistant is the product Salesforce names in this area. Use it. A separate texting tool is justified only when you can say what Appointment Assistant cannot say or cannot send, in your organisation, on the channels your customers actually answer. Do not pick a vendor because a project plan had a blank row labelled messages.
The sentence has to be specific. "Our customers answer on this channel, and Appointment Assistant cannot send there." "The message must include this fact, and Appointment Assistant cannot include it." If you cannot finish one of those, you do not have a gap. You have a habit of buying a sender. This page will not rank senders. A ranking would go stale and would still not confirm the window.
If you do add one later, it still does not own the appointment. The work order owns the window. The sender reads the window. Two senders, each with a template, will contradict each other by Friday. One will have the old time. One will have the new. The customer will believe the one they saw first, which is not always the true one. Turn the first sender off before you turn the second on, and check a real appointment, not a test contact nobody uses.
Which jobs are allowed to send
| State of the job | Send Appointment Assistant | What the customer should hear instead |
|---|---|---|
| Date filled, no start and end | No | Nothing yet |
| Window set, required part unknown | No | A person can say the visit is held |
| Window set, skill and parts in place, preference respected | Yes | The day, the window, the visit, what you need from them |
| Window moved after a message | Yes, a correction | That the earlier window is no longer kept, and the new one |
| Multi-day fit, part not yet named | No | The inspection can be confirmed. The later day is held |
The last row is where reminders do the most damage. A multi-day job often has a firm first day and a later day that depends on a part. Sending both as confirmations creates a promise the scheduling optimizer is not in a position to keep, because the part does not exist yet. How later days stay movable is set out in multi-day scheduling. Confirm the step that is real. Hold the step that is not.
An emergency that bumps a planned visit is the same rule at higher speed. The planned customer still holds the first message. Someone has to send the change before they are standing at the door. The dispatcher who was allowed to break the day owns that message as part of the move, not as a follow-up for Monday.
Measure the call you still get
Measure the thing you care about: how many reminded customers still call to ask when someone is coming. If that number does not fall, the window is not real, or the message does not state it. Another vendor will not fix a blank time. Read ten of those calls. Write down whether the message lacked a window, contradicted a preference, named the wrong kind of visit, or referred to a day that had already moved. That list is the fix. It will be one of those four more often than it will be "we need a different product."
Also count messages sent for jobs that were still a hold. That count should be zero. If it is not, the rule that decides "confirmed" is firing too early. Move the rule. Do not add a sentence to the template asking the customer to ignore the message if the time is not final. They will not ignore it. They will call, or they will wait at home.
The number you send to has to be the number the customer will answer, and it has to be a field you trust. A reminder to a generic accounts mailbox, or to a mobile captured once and never corrected, creates a message that looks sent and was not received. Then the customer calls anyway, and the report says the reminder worked because the flow did not error. Delivery without an error is not confirmation that a person saw the window. If you care about the call volume, sample the calls. Do not sample the send log and call it the outcome.
Say who the message is allowed to reach. The site contact, not every contact on the account. A reminder to the finance contact about a pit visit is noise, and it may be a detail they should not have. The work order's preference, or the contact named for access, is the recipient. A default of "all contacts" is how a private access note gets forwarded around a company that did not ask for it. Read one real message before you automate the rest. If you would not read it aloud to that customer, do not send it. Check the window in the message against the window on the work order, character for character. A template that formats noon as a date, and drops the end time, has recreated the original failure in a cleaner font.
Agentforce Field Service and Operations is the product. Field Service Lightning is the search. Appointment Assistant is the named tool for the reminder. The work order is the source of the window. Send after a person, or a rule a person still owns, can defend the start and the end. Until then, silence is the accurate message.
