Service Reminder by Mileage and Date

Nearly every service reminder in the industry is sent on a calendar. Six months after the last visit, everyone on the list gets the same email. It is simple to build and it is wrong for most of the list. The retired customer who drives 3,000 miles a year gets told their oil is due when it is not, learns the reminders are noise, and stops reading them. The delivery driver who covers 2,500 miles a month blew past the service interval in week nine and never heard a word. The reminder that would have earned the booking arrived four months late.

Manufacturer intervals are written as a pair: every twelve months or every 10,000 miles, whichever comes first. Almost nobody's reminder system models that pair, because modeling it requires knowing something the shop does not routinely capture: how fast this particular vehicle accumulates miles. That number is sitting in the data. If you recorded the odometer at the last two visits and the dates of those visits, you have a daily usage rate, and from the rate you can project the date each vehicle will cross its next mileage threshold. The shop stops guessing and starts forecasting.

The same gap breaks safety recalls and time-bound items. A recall notice posted by the manufacturer goes to the registered keeper and the shop has no idea who on its own list is affected, so the work goes to whoever happens to open the letter. Brake fluid, coolant and cabin filters are time-based regardless of mileage, and tires age out on date rather than tread. Without a model that tracks both axes per vehicle, those items are only ever caught opportunistically, during a visit that happened for another reason. This build replaces the single six-month blast with a per-vehicle projection, a dual-axis trigger, and a separate recall and campaign track that targets exactly the affected vehicles. It is rated Advanced because the mileage estimation, the per-vehicle interval table and the recall matching all need to be designed deliberately, not switched on.

Pipeline and stages

A dedicated pipeline, Service Due, separate from the booking pipeline. An opportunity is created here the moment a vehicle is projected into a due window, and it either converts into a booking or closes.

• Projected Due: the vehicle is 30–60 days from its calculated due point. Nothing has been sent yet.
• Reminder Sent: first touch delivered.
• Engaged: opened, clicked, or replied, but no slot held.
• Booked: an appointment exists; the opportunity hands over to the Service Bookings pipeline and closes won here.
• Deferred by Customer: they asked to be reminded later; snooze_until is set.
• Overdue: past the calculated due point with no booking.
• Unreachable: bounced email and undeliverable SMS, or opted out of both.
• Lapsed: more than 150 percent of the interval past due; moved to the win-back track.

Run a parallel pipeline, Recall and Campaign, with four stages: Affected Identified, Notified, Scheduled, Completed. Recalls need their own board because completion is a compliance record, not a sales outcome.

Calendars

• Reminders do not own calendars: they link into the Service Appointment Booking calendars. Reuse Express Service, General Service and Repair and Safety and Emissions Inspection.
• Add one new calendar, Recall Work, with durations set per campaign and a daily cap, so a high-volume recall cannot swallow the retail schedule.
• Set a Due-Window Booking Page: a single link that shows only the calendar matching the vehicle's due service type, resolved from the contact record at click time.

Custom fields

This build lives or dies on its fields. Create all of them before writing a single workflow.

• Odometer history: current_mileage, mileage_captured_date, prior_mileage, prior_mileage_date. Every new reading pushes the old pair into the prior pair.
• daily_mileage_rate (number, two decimals), calculated as (current_mileage minus prior_mileage) divided by the days between the two capture dates.
• estimated_current_mileage (number), recalculated nightly as current_mileage plus daily_mileage_rate multiplied by days since mileage_captured_date.
• Interval definition: service_interval_miles, service_interval_months, interval_source (single select: Manufacturer, Shop Default, Customer Override).
• Due calculation: next_service_due_mileage, next_service_due_date, projected_due_date (the earlier of the date threshold and the date the mileage threshold is projected to be crossed), due_trigger_axis (single select: Mileage, Date, Both).
• Usage classification: usage_band (single select: Low under 6,000 a year, Average 6,000 to 14,000, High 14,000 to 25,000, Commercial over 25,000).
• Time-based items: brake_fluid_last_date, coolant_last_date, cabin_filter_last_date, tire_manufacture_or_fit_date, inspection_expiry_date.
• Recall tracking: open_recall_reference, recall_description, recall_notified_date, recall_completed_date.
• Control fields: snooze_until (date), reminder_channel_preference (single select: SMS, Email, Both, Post only), reminders_paused (checkbox: for sold or written-off vehicles), vehicle_status (single select: Active, Sold, Written Off, Unknown).

Tags

• due-soon, due-now, overdue-30, overdue-90, lapsed
• usage-low, usage-average, usage-high, usage-commercial: written by the nightly recalculation so lists can be segmented without recomputing.
• rate-unknown: only one odometer reading on file, so no rate can be calculated. These vehicles fall back to date-only reminders and get a mileage-capture ask.
• mileage-stale: mileage_captured_date is more than 400 days old, so the projection is no longer trustworthy.
• recall-open, recall-notified, recall-complete
• time-item-due: a date-based item is due regardless of mileage.
• reminder-snoozed, vehicle-sold, sms-opted-out, email-unsubscribed

Forms

• Mileage Check-In: one number field and a submit button, sent by SMS link. This is the single highest-value form in the build: every submission sharpens the projection for that vehicle. Keep it to one question.
• Still Your Vehicle?: three options: Yes still mine, Sold or traded, Written off. Sold and Written off set vehicle_status and tick reminders_paused, which is how the list stays clean without anyone auditing it.
• Remind Me Later: a snooze form with four options: 1 month, 3 months, 6 months, Stop reminders for this vehicle. Writes snooze_until or reminders_paused.
• Recall Acknowledgement: confirms the customer has seen the recall notice and lets them book or request a call. Submission is the compliance record you keep.

BO's role and guardrails

BO handles the inbound replies this build generates, and there will be many: mileage numbers, “I sold it”, “not due yet”, “what does this cover”. BO may read a number from a reply and write it to current_mileage after a sanity check, confirm the service type due, offer slots from the Due-Window Booking Page, process a snooze request, and record a vehicle as sold.

Guardrails: BO must never quote a price for the due service, never state that a recall is or is not safety-critical beyond the manufacturer's own wording, and never argue with a customer who says the vehicle is not due. If a customer disputes the projection, BO accepts it, asks for the current odometer reading, and lets the recalculation settle it. BO must reject implausible mileage readings (lower than the previous reading, or implying a daily rate above 400 miles) with “Just to check I've got that right. Can you read it off the dash again?” and must escalate to a human on the second failure rather than writing bad data. On any recall conversation BO's script is fixed text supplied by the shop, quoting the manufacturer's own description, with a handoff offer on every message.

Numbers and channels

• Send reminders from the same dedicated service number used for bookings, so the thread the customer already has is the thread the reminder appears in.
• Email carries the detail: what the service covers, why it is due now, the projection in plain language (“you're averaging about 1,100 miles a month”), and the booking link.
• SMS carries the ask: short, one link, one question. Never put the interval explanation in an SMS.
• Build a due-service landing page per service type, reached from the reminder link, that explains the work, shows the booking widget and carries a click-to-call.
• Post remains in scope for recalls: where a manufacturer or regulator expects written notice, generate a mail-merge export rather than relying on SMS alone, and record recall_notified_date whichever channel was used.

One vehicle, from the odometer reading taken at its last visit to the booking eleven months later.

1. Last visit, March. The advisor records 41,200 miles on the Shop Arrival Check-In form. The platform pushes the previous reading (28,900 from the prior August) into prior_mileage and prior_mileage_date, writes current_mileage 41,200 and mileage_captured_date today.
2. Rate calculated. 12,300 miles over 212 days gives a daily_mileage_rate of 58.02. usage_band is written as High, and the usage-high tag is applied. The interval table for this model gives service_interval_miles 10,000 and service_interval_months 12.
3. Due point projected. next_service_due_mileage is 51,200 and next_service_due_date is next March. At 58 miles a day the mileage threshold will be crossed in about 172 days: late August. projected_due_date is set to the August date and due_trigger_axis to Mileage, because mileage comes first for this driver. For the low-mileage customer in the next record, the same calculation sets due_trigger_axis to Date.
4. Nightly recalculation. Every night the maintenance workflow updates estimated_current_mileage for every active vehicle and re-derives projected_due_date. The estimate drifts as the driver's habits change, so the forecast moves with them rather than being fixed at the last visit.
5. Day 112, mid-July. estimated_current_mileage crosses 48,000: roughly 60 days from due. The projection workflow creates a Service Due opportunity in Projected Due and applies due-soon.
6. First touch, a mileage ask rather than a sales message. SMS: “Hi Marcus: quick one. What's the odometer on the Hilux reading today? Tap here and it's one number: {{mileage_link}}” He replies with 48,640 from his phone.
7. Projection sharpened. The reading is plausible, so it becomes the new current_mileage, the March figure moves to prior, and daily_mileage_rate recalculates to 61.4. projected_due_date pulls forward by six days. The opportunity moves to Engaged.
8. Day 136. 30 days from the refreshed due point. The reminder email goes out with the reason stated: “You're averaging about 1,840 miles a month, so the Hilux will reach its 10,000-mile service around the 28th rather than next March.” Booking link included. The opportunity moves to Reminder Sent.
9. Day 143. No booking. SMS with the Due-Window Booking Page link and three concrete slot suggestions pulled from the General Service calendar.
10. Day 150. Still nothing. The deferral option is offered rather than another nudge: “Not the right time? Tap here and I'll come back in a month or three. Whichever suits: {{snooze_link}}” He taps 1 month. snooze_until is set, reminder-snoozed is applied, the opportunity moves to Deferred by Customer and all sending stops.
11. Day 180, snooze expires. The tag clears and the opportunity returns to Reminder Sent. estimated_current_mileage is now past next_service_due_mileage, so due-now replaces due-soon and the message changes register: “By our estimate the Hilux is now a little past its service interval. Two slots left this week: {{booking_link}}”
12. Recall intersects. The same week, the shop loads a manufacturer recall affecting that model year. The matching workflow finds the vehicle, writes open_recall_reference and recall_description, applies recall-open, and creates a Recall and Campaign opportunity in Affected Identified. The service reminder is suppressed for 24 hours so the recall notice lands on its own.
13. Recall notice sent using the manufacturer's own wording, with the Recall Acknowledgement form. recall_notified_date is written. He acknowledges and books, choosing a slot that covers both the recall and the service in one visit. The booking page offers a combined duration when recall-open and due-now are both present.
14. Both opportunities close. The Service Due opportunity moves to Booked and hands over to Service Bookings; the Recall opportunity moves to Scheduled. At the visit the advisor records the odometer again, recall_completed_date is written, recall-complete replaces recall-open, and the whole cycle restarts with a rate now based on three readings instead of two.

Eight workflows. Workflow 8 is the governor. Build it first, because every other workflow in this build defers to it. Every SMS action everywhere carries the same suppression set: not sms-opted-out, not reminders_paused, not reminder-snoozed, inside quiet hours, and inside the frequency cap.

1. Odometer Capture and Rate Recalculation

Trigger: current_mileage changed, by any route: Shop Arrival Check-In form, Mileage Check-In form, BO writing a value from a reply, or an inbound sync from the shop management system.

Conditions and validation, in order:

• If the new value is less than or equal to the existing current_mileage, reject it. Do not write. Create a task: “Odometer regression on {{plate_number}}, verify reading” and, if the source was a customer reply, have BO ask once: “Just to check I've got that right: can you read it off the dash again?”
• If the implied daily rate exceeds 400, reject and escalate the same way. Two rejections in a row hands off to a human and the workflow exits.
• If the value is accepted: move the existing current_mileage and mileage_captured_date into prior_mileage and prior_mileage_date, then write the new value and today's date.

Actions:

• Calculate daily_mileage_rate as (current_mileage minus prior_mileage) divided by days between the two dates. If prior_mileage is empty, leave the rate blank and apply rate-unknown.
• Write usage_band from the annualised rate and apply the matching usage- tag, removing the others.
• Recalculate next_service_due_mileage as current_mileage plus service_interval_miles, and next_service_due_date as mileage_captured_date plus service_interval_months.
• Project the mileage-threshold date: days to due equals (next_service_due_mileage minus current_mileage) divided by daily_mileage_rate. Write projected_due_date as the earlier of that date and next_service_due_date, and set due_trigger_axis accordingly.
• Remove mileage-stale and rate-unknown if they no longer apply.

Exit: fields written, or two validation failures.

2. Nightly Projection Sweep

Trigger: scheduled daily at 2:00am.

Conditions: vehicle_status is Active and reminders_paused is unticked.

Actions:

• Recalculate estimated_current_mileage as current_mileage plus daily_mileage_rate multiplied by days since mileage_captured_date. Skip any record tagged rate-unknown.
• Re-derive projected_due_date and due_trigger_axis from the refreshed estimate.
• If mileage_captured_date is more than 400 days old, apply mileage-stale and fall back to date-only logic for that vehicle.
• If projected_due_date is 60 days or fewer away and no open Service Due opportunity exists, create one in Projected Due, named “{{plate_number}}, {{service_type_due}}, due {{projected_due_date}}”, and apply due-soon.
• If estimated_current_mileage is at or past next_service_due_mileage, or today is at or past next_service_due_date, swap due-soon for due-now.
• Write a daily summary to the service manager: counts entering the due window, counts newly due-now, counts newly stale, and any validation tasks created in the last 24 hours.

Exit: sweep completes. Stateless, re-runs nightly.

3. Service Due Reminder Ladder

Trigger: opportunity created in Projected Due.

Conditions: passes the governor in workflow 8.

Actions:

• Day 0: ask, do not sell. SMS: “Hi {{contact.first_name}}, quick one. What's the odometer on the {{vehicle_model}} reading today? Tap here, it's one number: {{mileage_link}}” A reply re-enters workflow 1 and sharpens the projection before any sales message goes out.
• Day 7: the reason-stated email. Subject: “{{vehicle_model}} service: due around {{projected_due_month}}”. Body states the projection in plain language: “You're averaging about {{monthly_miles}} miles a month, so the {{vehicle_model}} will reach its {{service_interval_miles}}-mile service around {{projected_due_date}} rather than on the calendar date.” Lists what the service covers, links the due-service landing page. Move the opportunity to Reminder Sent.
• Day 14: SMS with slots. “{{vehicle_model}} service is coming up. I've got {{slot_1}}, {{slot_2}} or {{slot_3}}, reply with a number or book here: {{booking_link}}”
• If the contact opens, clicks or replies at any point without booking, move to Engaged and create a task for the advisor to call within one working day.
• Day 21: offer the exit. “Not the right time? Tap here and I'll come back in a month, three or six. Whichever suits: {{snooze_link}}” This message exists to convert would-be opt-outs into snoozes.
• Day 30: final email before the overdue track takes over, with the booking link and the direct number.
• Branch on due_trigger_axis for all copy: Mileage framing uses miles (“about 900 miles from its service”); Date framing uses time (“twelve months since its last service”). Never mix the two in one message. It reads as a template.

Exit: appointment booked (move to Booked, hand to Service Bookings), snooze taken, opt-out, or the ladder completes and workflow 5 takes over.

4. Mileage Harvest for Unknown and Stale Records

Trigger: tag rate-unknown or mileage-stale applied, or monthly on the 3rd for the standing population of both.

Conditions: no Service Due opportunity currently in an active reminder stage, so this never collides with workflow 3.

Actions:

• SMS: “Hi {{contact.first_name}}, we're keeping your service schedule accurate rather than guessing. What's the {{vehicle_model}} on today? One number: {{mileage_link}}”
• Wait 4 days. Email with the same ask plus one line on why it matters: “It means we only contact you when the vehicle is genuinely due.”
• Wait 10 days. Send the Still Your Vehicle form instead of asking again: “Just checking: is the {{vehicle_model}} still yours? {{status_link}}”
• If Sold or Written off is selected: set vehicle_status, tick reminders_paused, apply vehicle-sold, close any open Service Due opportunity as lost with reason “Vehicle no longer owned”, and exit permanently.
• If nothing comes back after 30 days, leave the tag in place, stop asking for 90 days, and count the record in the data-debt metric.

Exit: a reading received, vehicle marked sold, or the 30-day step completes.

5. Overdue Escalation and Lapse

Trigger: today is past projected_due_date and the opportunity is not Booked.

Actions:

• Move to Overdue. Apply overdue-30 at 30 days past, overdue-90 at 90 days past.
• Day 30 past due: SMS: “By our estimate the {{vehicle_model}} is now about {{miles_over}} miles past its service interval. Worth getting booked in: {{booking_link}}” Never state this as fact; always “by our estimate”, because the estimate can be wrong.
• Day 45: advisor call task with the full projection on the record, so the advisor can open with the two readings rather than a script.
• Day 90: email covering the specific consequences of deferring the items in this interval, written by the service manager, not generic copy. Include the Mileage Check-In link. A customer who is not actually overdue will tell you so here.
• Day 150 percent of interval past due: apply lapsed, move the opportunity to Lapsed, stop the service-due track and enroll the contact in the win-back sequence: one email at day 0 and one at day 30, then quarterly email only, no SMS.

Exit: booking made, vehicle marked sold, opt-out, or lapsed applied.

6. Time-Based Item Reminders

Trigger: scheduled weekly on Tuesday at 9:00am, evaluating the date fields.

Conditions: each item has its own interval, and the workflow runs independently of mileage entirely.

Actions:

• Brake fluid: brake_fluid_last_date plus the shop's interval, first touch 45 days before. Coolant: same pattern. Cabin filter: 30 days before. Tires: tire_manufacture_or_fit_date plus the shop's age threshold, first touch 60 days before.
• Inspection expiry: inspection_expiry_date minus 42 days, then minus 21, then minus 7, then on the expiry date itself. This is the one sequence worth running to four touches, because an expired inspection has consequences beyond the vehicle.
• Apply time-item-due and append the item to the opportunity name so the advisor sees it on the board.
• Bundling branch: if a Service Due opportunity is already open for the same contact, do not send a separate message. Add the item to that reminder's copy instead: “While it's in, the brake fluid is also due on age.” One message, two items.
• If no service is due, send the item on its own with its own landing page and booking link.

Exit: item date updated at a visit, or the item is booked.

7. Recall Match and Notification

Trigger: a recall record is loaded by the service manager, or the recall feed delivers a new bulletin.

Actions:

• Match the active vehicle population on vehicle_make, vehicle_model and vehicle_year, narrowed by the bulletin's VIN range where one is given and the shop holds the data to apply it.
• For each match: write open_recall_reference and recall_description using the manufacturer's own wording verbatim, apply recall-open, and create a Recall and Campaign opportunity in Affected Identified.
• Suppress for 24 hours any Service Due message queued for the same contact, so the recall notice arrives alone.
• Send the notice by the customer's reminder_channel_preference, defaulting to email plus SMS. Email carries the full manufacturer description, what the shop will do, how long it takes, and the Recall Acknowledgement form. SMS carries one line and the link: never a paraphrase of the safety issue.
• Write recall_notified_date, apply recall-notified, move to Notified.
• Wait 7 days. If no acknowledgement, resend by the other channel. Wait 14 days. Create a call task. Wait 30 days. Add the record to the postal-notice export list and tell the service manager, rather than continuing to text.
• On booking: move to Scheduled and book onto the Recall Work calendar, combining with a due service into one longer slot when due-now is also present.
• After the visit: write recall_completed_date, apply recall-complete, remove recall-open, move to Completed. Retain the acknowledgement submission as the compliance record.

Exit: recall completed, vehicle marked sold, or the record is escalated to postal notice.

8. Governor: Snooze, Hygiene and Frequency Cap

Trigger: runs as a condition set every other workflow checks, plus a daily 1:00am pass.

Rules it enforces:

• Frequency cap: no more than one outbound SMS per contact per 7 days across every workflow in this build, and no more than two emails per 14 days. A send that would breach the cap is held, not dropped, and retried when the window opens.
• Collision rule: a recall notice and a service reminder never go out on the same day. Recall always wins; the service reminder is held 24 hours.
• Snooze: on a Remind Me Later submission, write snooze_until, apply reminder-snoozed, move any open opportunity to Deferred by Customer and halt all sends. The daily pass clears the tag when snooze_until passes and returns the opportunity to the ladder at the step it left, re-evaluating due-soon against due-now first. “Stop reminders for this vehicle” ticks reminders_paused permanently.
• Hygiene: a hard email bounce plus an undeliverable SMS moves the opportunity to Unreachable and halts sending. Two consecutive bounces set a task to confirm contact details at the next visit.
• Quiet hours: hold any SMS scheduled outside 8:00am to 8:00pm local and release at the next permitted window. Reminder emails default to 10:00am on a weekday.
• Audit: log every held, dropped and suppressed send with the reason, and surface the log weekly. Without this log, nobody will be able to explain why a given customer did or did not receive a reminder.

Exit: never. This workflow is permanent infrastructure.

What is different afterwards

• Reminders arrive when the vehicle is actually due. The high-mileage driver hears from you in August; the low-mileage driver hears from you next March. Both are correct, and neither gets a message that teaches them to ignore you.
• The shop can forecast workload. Because every active vehicle carries a projected_due_date, you can look at next month's projected due volume by service type before it arrives and staff and stock against it. That is a planning capability the calendar-blast model cannot give you.
• Mileage data improves itself. Each Mileage Check-In reply tightens one vehicle's rate. After two cycles most of the active list has three or more readings and the projections stop being estimates and start being reliable.
• Time-based items stop being missed. Brake fluid, coolant, cabin filters and inspection expiry fire on their own dates regardless of mileage, instead of being caught by luck during an unrelated visit.
• Recalls become a managed campaign. The shop knows exactly which of its own customers are affected, notifies them with the manufacturer's wording, holds an acknowledgement record and tracks completion on its own board.
• The list stops rotting. Sold and written-off vehicles take themselves out of the population through the Still Your Vehicle form, so deliverability and reporting both stay honest.
• Low-mileage customers stay subscribed. The quiet win is the message not sent. Suppressing reminders that would have been wrong is what keeps the ones that are right getting read.

Metrics to watch

• Reminder-to-booking conversion, split by usage_band. If Low converts much worse than High, your intervals for low-mileage vehicles are probably still too aggressive.
• Projection accuracy: at each visit, compare the recorded odometer against estimated_current_mileage and track the median absolute error in miles. This is the health metric for the whole build. Watch it by usage_band; Commercial is usually the hardest to predict.
• Mileage Check-In response rate, and the share of the active list with two or more readings on file. Both should climb every quarter.
• Share of the active list carrying rate-unknown or mileage-stale. This is your data-debt number and it should shrink.
• Due-window hit rate: bookings that land within 30 days either side of projected_due_date, as a share of all reminder-driven bookings.
• Snooze rate and snooze-to-booking conversion. A healthy snooze rate is a good sign. It means people are telling you when rather than unsubscribing.
• Unsubscribe and opt-out rate per send, compared against whatever the shop's old six-month blast produced. This is where a dual-axis model usually shows its clearest improvement.
• Recall completion rate and median days from recall_notified_date to recall_completed_date. Report these separately from commercial metrics.
• Lapsed recovery rate: vehicles that reached lapsed and later booked.

Data prerequisites: do this first

• Audit your odometer history before building anything. Export the customer list and count how many vehicles have two or more dated odometer readings. That number, not the workflow design, determines when this build starts producing accurate reminders. If most records have one reading or none, plan a mileage-capture campaign as phase one and switch the dual-axis triggers on in phase two.
• Build the interval table. Decide for each make and model you service what service_interval_miles and service_interval_months should be, and where the figure comes from. Agree a shop default for vehicles you have no data for, and allow a per-customer override for severe-duty use.
• Normalize units. Pick miles or kilometres for the whole database and convert once. Mixed units silently corrupt every rate calculation and the failure is almost impossible to spot afterwards.
• Decide the sanity bounds for accepted readings: a new reading must be higher than the previous one and must not imply a daily rate above your ceiling. Anything outside goes to a human.
• Clean the list. Run the Still Your Vehicle form across the whole active population before you start sending due reminders, so you are not projecting mileage for cars that were sold two years ago.

Integrations

• Dealer or shop management system: the odometer history almost certainly lives here. Connect it through Zapier or Make so each closed job pushes the reading back to the contact record. If no API exists, make odometer capture a mandatory field on the arrival form and accept that the history builds forward from launch.
• A scheduled calculation step. The nightly recalculation needs somewhere to do arithmetic. Either use the platform's own calculation and date-math actions if they cover it, or run the recalculation in a scheduled Make or Zapier scenario that reads the contact, computes the fields and writes them back. Design this before you commit to the field list.
• Recall data source: whichever feed, dealer portal or manufacturer bulletin the shop already receives. Matching is done on make, model and year, plus the VIN range where the bulletin gives one. Do not promise VIN-exact matching unless you hold full VINs and are willing to.
• Google Calendar or Outlook sync for the booking handover, and Google Business Profile for the post-visit review step.

Numbers and messaging compliance

• Complete A2P 10DLC brand and campaign registration before sending. Register this traffic honestly: reminders are a recurring campaign with a defined message flow, and your sample messages should be the actual reminder copy. Expect several business days, and expect a resubmission if the sample messages do not match the opt-in language.
• Volume matters here more than in other builds. A reminder system sends to the whole active base over time; check your throughput limits and consider whether the number type you have is appropriate for the volume. Throttle large recall notifications rather than firing them in one batch.
• Opt-in. Reminders are marketing in many jurisdictions even when they feel like a service. Capture explicit consent at intake, store the timestamp and source, and do not retrofit consent onto a historic list you cannot evidence. If the shop has an old list with no consent record, start with email under its own lawful basis and build SMS consent forward.
• Opt-out. STOP, UNSUBSCRIBE, QUIT and CANCEL set sms-opted-out; that tag is a suppression condition on every SMS action in every workflow here. Email carries a working unsubscribe link that sets email-unsubscribed. Honor both per channel and give the customer a middle option. The Remind Me Later form exists so that “not now” does not have to mean “never”.
• Quiet hours: no SMS before 8:00am or after 8:00pm local to the recipient, held and released rather than dropped. Reminder sends should be scheduled mid-morning on weekdays by default.
• Frequency cap. Set a hard ceiling. No more than one reminder SMS per contact per seven days across every workflow in this build, and never let a recall notice and a service reminder land the same day. Without this cap the recall track and the due track will double up on exactly the customers you least want to annoy.

Data protection

• Mileage, service history and vehicle identifiers are personal data when tied to a named customer. Document why you hold them, how long for, and who can export them.
• Store the plate and the last eight of the VIN. If a recall genuinely requires full-VIN matching, hold the VIN in the shop management system and match there rather than copying full VINs into the marketing platform.
• Keep recall acknowledgement records for as long as the manufacturer or regulator requires, and keep them separate from marketing engagement data.
• Automated projections that drive customer communication should be explainable. If a customer asks why they were told their vehicle is due, the advisor should be able to show the two readings and the rate.
• None of this is legal advice. Consent wording, retention periods, recall notification duties and any jurisdiction-specific privacy requirements should be confirmed with the client's own counsel before launch.

Scoping

The size and state of the existing odometer history is the single biggest variable in this build, followed by whether the shop management system can be integrated. Book a call at bookings.appbo.io to scope it against your data.