Every repair a customer said no to becomes a tracked item, re-offered at the moment the reason for declining has probably changed.
Bring your stack to a call and we will scope it against how your business actually runs.
Book a callA technician inspects a vehicle, finds four things, and the advisor presents all four. The customer approves the one they came in for and declines the other three. The advisor writes cust declined on the job card, the car leaves, and the three items cease to exist. They were real when the technician found them. They are still real a month later. Nobody will mention them again unless the same customer happens to come back and the same technician happens to look in the same place.
This is the largest and most reliably ignored revenue source in a service department, and it leaks for a structural reason rather than a sales reason. Declined work is recorded as a note, not as data. A note cannot be filtered, cannot be counted, cannot be sorted by urgency and cannot trigger anything. So the follow-up, if it happens at all, depends on an advisor remembering a conversation from six weeks ago, in between answering the phone and handing out keys. It does not happen.
The second failure is that the few shops which do follow up treat every decline identically. They send the same “just checking in about that work” message to the customer who said “not this month” and the customer who said “I'm selling the car in spring”, at the same interval, with the same wording. The reason for the decline is the single most important piece of information in the whole interaction and it is almost never captured. A deferral on cost needs a different timing and a different message than a deferral on time, which needs something different again from a customer who genuinely disagreed with the diagnosis. This build makes declined work a first-class record with a reason, an urgency rating and a re-offer schedule, and it re-offers each item when the reason for saying no has most likely changed.
One pipeline, Declined Work, with one opportunity per declined item, not one per visit. If a customer declines three items, three opportunities are created. This is the decision the whole build rests on: an item that cannot be counted on its own cannot be followed up on its own.
These sit on the opportunity, one set per declined item, with the summary fields mirrored to the contact.
BO runs the re-offer conversations, which are the most delicate messages the shop sends. BO may restate the item in the customer's own prior framing, confirm the technician's reason, offer slots, bundle two items into one visit, process a snooze, record that work was done elsewhere, and route a disagreement to a human.
Hard guardrails. BO must never quote or re-quote a figure, never say the estimate still stands, and never imply a figure has or has not changed. Every pricing question routes to the advisor with the estimate reference attached. BO must never use urgency language on anything rated Maintenance or Cosmetic, and must never escalate the stated risk of an item beyond what technician_reason says. On a Safety item BO states the technician's finding plainly once and offers the soonest slot; it does not repeat the warning across messages, and it does not describe consequences the technician did not write down. If the customer pushes back, disputes the diagnosis, expresses annoyance at being contacted, or mentions another shop's opinion, BO hands off to a human on that message and stops. BO must honor “stop asking” on first mention, in any wording, without asking for confirmation.
One visit, three declined items, followed through to two of the three being completed.
Eight workflows. Every send in every one of them carries the same suppression set: not no-reoffer, not sms-opted-out for SMS, not email-unsubscribed for email, inside quiet hours, and inside the 30-day re-offer frequency cap. Re-check these immediately before each send, not only at enrollment.
Trigger: Declined Item Capture form submitted, or an Authorization Response of Decline or Approve Selected arrives from the booking build.
Actions in order:
Exit: item classified and routed.
Trigger: opportunity moved to Cooling Off.
Actions:
Exit: item reaches Re-Offer Due, or is closed.
Trigger: opportunity moved to Re-Offer Due.
Conditions: urgency is Reliability, Maintenance or Cosmetic; passes the bundling check in workflow 6 first.
Actions:
Exit: booked, closed, snoozed, opted out, or touch 3 completes.
Trigger: opportunity created with urgency_rating of Safety.
Conditions: no cooling-off period applies. This track uses people, not sequences.
Actions:
Exit: booked, completed, customer stops contact, or day 14 reached.
Trigger: decline_reason is Disagrees with diagnosis, or Wants second opinion.
Actions:
Exit: re-inspection completed, or 21 days with no response.
Trigger: two conditions, either of which runs it: an item reaching Re-Offer Due while other open items exist, or any new appointment being booked for a contact with declined-open.
Actions:
Exit: items bundled and sent, or the visit completes.
Trigger: an item is declined a second time, a snooze is taken, or a stop request is received.
Actions:
Exit: terminal in every branch except snooze.
Trigger: scheduled every Monday at 7:30am.
Actions:
Exit: digest sent. Stateless, re-runs weekly.
Capture discipline, whether a digital inspection tool is connected and how much history the shop wants migrated are the variables that move this build. Book a call at bookings.appbo.io to scope it against your shop.
Every build on this page is something we configure, test and hand over with the SOPs your team needs to run it.
Book a call