The "on the way" text from the field-service technician is no longer a nice-to-have. The customer who orders a Lyft sees the driver's photo, name, and car before the trip starts. The customer who orders a DoorDash burrito gets a notification when the driver leaves the restaurant. The customer who buys a Samsung TV from Amazon sees the truck on a map two hours before it arrives. By the time the HVAC tech, the plumber, or the electrician shows up at the customer's house, the customer has been trained by every other service interaction in their life to expect the same level of pre-arrival notification. The iFleet Customer Notification feature is the operational piece that brings the field service business into the same standard.
The feature is also one of the cheapest customer-experience upgrades a field service business can deploy. The notification is auto-generated from the dispatch record, sent the moment the technician taps Start Traveling in iFleet, and requires zero new work from the tech or the office staff. The implementation guide below covers what the customer sees, what the merge fields do, the setup path inside iFleet, and which office-workflow problems the feature replaces once it is live.
The On-the-Way Text Standard
The customer benchmark: the average homeowner who books a service appointment in 2026 has received between five and ten "your driver is on the way" notifications in the past week from food delivery, ride share, package delivery, and same-day retail. The field service business that does NOT send an equivalent notification feels operationally behind the brands the customer interacts with daily, regardless of how good the actual service is.
The downstream cost of not sending the notification is measurable in two places: inbound calls to the office ("is the tech still coming?") and missed appointments where the customer left the house assuming the tech was not coming. The contractor who runs the notification feature reduces both line items meaningfully inside the first quarter. The contractor who continues to rely on the office to make confirmation calls before each appointment burns staff hours on a workflow the software now does for free. The broader millennial customer-experience framework covers what this baseline looks like for the cohort that now drives most homeowner service decisions.
What the Customer Sees
The notification arrives as a text message (or an email, depending on the customer's preference set in their service record) the moment the technician taps Start Traveling in iFleet. The contents are auto-assembled from the dispatch record and the office-configured template. A typical iFleet customer notification includes:
- A friendly time-of-day greeting: "Good morning," "Good afternoon," or "Good evening," populated by the [ifleetDayPart] merge field based on the technician's local time when the message is sent.
- The technician's name: populated by the [ifleetServiceTech] merge field. This is the actual technician headed to the customer's house, not a generic "your tech" placeholder.
- The job type: populated by the [ifleetJobType] merge field. The customer sees "annual maintenance" or "leak repair" or "thermostat install" depending on what is actually on the work order.
- A photo of the technician: uploaded once per technician in the iFleet settings and attached automatically to every notification that technician sends. The photo is the trust signal the customer uses to confirm the person at the door is the same person the company sent.
- A short sign-off: "See you soon!" or whatever closing the office configured into the template.
The full message takes about 15 seconds for the customer to read and answers the three questions the customer would have called the office to ask: when is the tech coming, who is the tech, and what are they coming to do.
The Merge Fields Behind It
The iFleet Customer Notification template uses bracketed merge fields that pull data from the dispatch record at the moment the notification is sent. The office configures the template once and every technician on every job uses the same skeleton, with the merge fields auto-filling per appointment.
[ifleetDayPart] populates the time-of-day greeting based on the technician's local clock. Mornings get "morning," afternoons get "afternoon," evenings get "evening." The greeting feels human because the customer reads it at roughly the same time the technician sent it.
[ifleetServiceTech] populates the technician's first name (or whatever name field the office has configured in the technician record). The customer gets a real name rather than a generic dispatch reference.
[ifleetJobType] populates the job-type description from the work order. This is the field the office configures in the job-type list inside Smart Service. The customer sees the actual job description, which doubles as a confirmation that the right work is on the schedule. Pairing this with the broader core software feature set the back office runs surfaces other places the merge-field pattern shows up across the product.
The office can also write static text around the merge fields to match the brand voice. A more formal business might write "Good [ifleetDayPart], Mr. or Ms. customer. This is [ifleetServiceTech] from Acme HVAC, and I am on my way to perform your [ifleetJobType]." A more casual operation might write the version shown in the Customer Notification screen: "Good [ifleetDayPart]! I'm [ifleetServiceTech] and I'm on my way to do your [ifleetJobType]! See you soon!"
How to Set It Up in iFleet
The full setup takes about ten minutes per technician and one office-side template configuration. The sequence:
- Open Customer Notification in iFleet: on the technician's tablet or phone, open the iFleet settings menu and tap Customer Notification. The screen with the Enable Customer Notifications toggle, the Current Photo block, and the template text area appears. The vendor's post-purchase onboarding sequence covers this step as part of the initial iFleet rollout.
- Toggle Enable Customer Notifications on: the green toggle in the top right turns the feature on for this technician. Once on, the notification fires every time the technician taps Start Traveling on a new job.
- Upload the technician photo: tap Choose Photo and select a head-and-shoulders photo of the technician in company uniform. The photo attaches to every notification this technician sends. Replace it with Clear Photo when the technician changes uniform style or the photo gets stale.
- Write or paste the template text: the text box at the bottom of the screen holds the message template with merge fields. The office should standardize the template across the company so the customer experience is consistent regardless of which technician is dispatched. The SOP framework the office already runs is the right home for the standardized template language.
- Confirm the customer record holds a valid phone number or email address: the notification needs a destination. Check the customer record in Smart Service before the first dispatch, and add the missing contact info during the same customer-record cleanup pass that the equipment tracking module rollout already touches.
The feature is live the moment the toggle is on, the template is saved, and the customer record holds a destination. The technician does nothing different on the job itself, the notification fires automatically when the Start Traveling button is tapped, which the technician was tapping for time-tracking purposes anyway.
Office Workflows It Replaces
The customer-notification feature is not just a customer-experience upgrade. It also removes work the office was doing manually before the feature was live. Three specific workflows that get reclaimed once notifications are running for every job.
Inbound Where Is the Tech Calls
The single most common inbound call to the field-service office is the customer asking where the technician is. The contractor running a five-truck operation can field eight to twelve of these calls per day during peak season. Each call eats two to four minutes of office time including the look-up, the call-back to the tech, and the report back to the customer. The notification preempts the call because the customer sees the tech is on the way before they would have picked up the phone. The dispatching framework the office runs around tech ETAs depends on the inbound-call reduction to free dispatcher time for actual schedule optimization.
The Day-of Confirmation Call
The contractor who runs confirmation calls the morning of the appointment is doing the customer's job for them. The notification is the modern confirmation. The customer sees the technician is on the way, the customer confirms they are home (or texts back if they are not), and the office staff time that was going into the confirmation-call workflow can go to the recurring service agreement renewal campaign or the customer-review follow-up program. The automated billing workflow for recurring agreements is one of the back-office programs that wins time when the confirmation-call workflow goes away.
The Tech-to-Office ETA Update
The technician who has to radio the office every time they leave for a job to give the office an ETA update is doing more dispatch work than they should be. The notification captures the leave-time automatically. The office sees the notification fire in the dispatch view (which is the same Start Traveling event the customer sees) and the dispatcher knows the tech is on the move without asking. The office-to-tech radio chatter that used to fill the morning compresses to actual scheduling exceptions, not status updates.
Smart Service for Field Service
If you are running a field service business and want a software stack that handles scheduling, dispatch, customer and equipment history, mobile invoicing, recurring service agreements, and the iFleet customer-notification feature that turns the on-the-way text into a zero-touch workflow, Smart Service integrates with QuickBooks Desktop and QuickBooks Online and iFleet keeps techs in the field synced with the office. Try a free demo to see how it fits!
