Membership and Service Plan Enrollment

Every home services owner who has read a book about business knows they should have a service plan. Recurring revenue smooths the winter trough, a plan member calls you instead of searching, and a maintained system fails less often and generates fewer angry call-outs. So most of them launch one. A surprising number of those plans are, within eighteen months, a spreadsheet with forty names on it, a handful of standing orders nobody reconciles, and a quiet agreement in the office never to mention it to new customers.

The failure is almost never the offer. It is the servicing. A plan is a promise to do something on a schedule, and nothing in a typical trade business is built to remember a promise eleven months out. The included annual visit does not get booked unless the customer rings to ask for it, which the conscientious ones do and the rest do not. Six months in, a member who has paid every month and received nothing cancels, and they are right to. Meanwhile the member who does ring gets treated exactly like a stranger, because the person answering the phone has no way of knowing they are a member until they say so, and even then has no way of knowing what they are entitled to.

The money leaks in three directions at once. Involuntary churn: a card expires, the payment fails, and nobody finds out for two months because failed-payment emails go to an inbox nobody owns. Unfulfilled entitlement: the visits that were sold and never delivered, which is both a liability and the direct cause of voluntary churn. And unrealised upsell: members are the warmest list a trade business will ever own, and most businesses cannot even produce a clean list of them. This build makes the plan an object the system understands. A tier, a subscription, an entitlement count, a visit schedule, a renewal date and a status, so that the promise gets kept automatically and the failures surface the day they happen rather than the quarter after.

Pipelines and stages

Two pipelines, because selling a plan and servicing a plan are different jobs with different owners.

Plan Enrollment: the sales side:

• Plan Candidate: identified by a workflow, not by hand: anyone with a completed job, an aging appliance, or a repeat call-out.
• Plan Offered: the comparison page has been sent and seen.
• Considering: engaged with the page or asked a question but not signed.
• Signed, Payment Pending: the enrollment form is in but the first payment has not cleared. A real stage, because this is where enrollments silently die.
• Active: first payment taken and the subscription is live.
• Declined: with a reason captured.
• Not Suitable: equipment too old to cover, or outside the service area. Being honest here protects the plan's economics.

Member Servicing: the delivery side, where every active member lives for as long as they are a member:

• Active, Visit Not Due.
• Visit Due: inside the scheduling window.
• Visit Scheduled.
• Visit Overdue: the entitlement window has passed unfulfilled. This stage is the single most important object in the build: it is the business's own liability register, and it must be visible on a dashboard someone looks at weekly.
• Visit Completed.
• Payment Failed.
• At Risk: dunning exhausted, cancellation requested, or a complaint logged.
• Canceled: with a reason and an effective date.
• Lapsed: payments stopped without a formal cancellation.

Calendars

• Plan Service Visit: a round-robin calendar across qualified techs, with a long booking horizon so a member can book their visit months ahead. Slot length is set per plan tier, because a two-appliance plan is not a one-appliance visit.
• Member Priority Response: a service calendar with slots held back daily and released to non-members only late in the day. This is the mechanism behind a priority-response promise; without held slots, priority response is a sentence in a brochure.
• Plan Consultation: a short call calendar for people who want to talk the plan through before enrolling. Pricing conversations belong on this calendar or at bookings.appbo.io, never in an automated message.

Custom fields

• Plan Tier: single select: Essential, Protect, Protect Plus. Keep it to three; a plan with six tiers does not get sold at the door.
• Plan Status: single select: None, Offered, Pending Payment, Active, Payment Failed, At Risk, Canceled, Lapsed. This field is the one every other system reads, so it must only ever be written by a workflow.
• Plan Start Date, Plan Renewal Date, Billing Frequency (Monthly or Annual), Billing Day.
• Subscription Reference: the payment-processor subscription identifier, so a record in the platform can always be reconciled against the processor without anyone searching by name.
• Visits Included Per Year, Visits Used This Year, Last Visit Date, Next Visit Due, Visit Window Opens, Visit Window Closes. Entitlement is arithmetic, and it only works if every one of these is written by automation rather than typed.
• Equipment Covered: repeating entries of make, model, age, location in the property and serial where available. The equipment schedule is what is actually being insured, and a plan without one generates disputes.
• Priority Response Entitled: checkbox derived from Plan Tier, read by the phone system.
• Member Benefits Applicable: checkbox flags for the benefits the tier includes, used to drive messaging and to tell staff what to honor. No figures are stored here; benefits are described, and anything involving a number is confirmed by a person.
• Dunning Attempt Count, Last Payment Failure Reason, Payment Method Expiry Month.
• Cancellation Reason, Cancellation Requested Date, Cancellation Effective Date, Save Attempted.
• Enrollment Source: At Job, Inbound Call, Web Page, Email Campaign, Post-Emergency, Renewal Reminder. Without this you cannot tell which channel sells plans and which just advertises them.

Tags

• plan-candidate, plan-offered, plan-member.
• tier-essential, tier-protect, tier-protect-plus.
• billing-monthly, billing-annual.
• visit-due, visit-scheduled, visit-overdue: the last of these should trigger an internal alert, not a customer message.
• payment-failed, dunning-active, card-expiring.
• plan-at-risk, cancellation-requested, save-offered, plan-canceled, plan-lapsed, win-back-eligible.
• plan-not-suitable: permanent, so the offer automation never cycles back round to someone whose equipment cannot be covered.

Funnel, pages and member area

• A plan comparison page with the three tiers side by side, what each includes in plain words, and a separate order form per tier. The page carries the full terms and the cancellation terms, linked and unavoidable, not buried.
• A member area built on the memberships module, containing the plan certificate, the terms, the equipment schedule, visit history, the remaining entitlement for the year, the booking link for the included visit, and the payment-method update link. Most support contact from members is one of those six things, and a member area removes nearly all of it.
• A short plan explainer page the techs can send from their phone at the door, because the door is where most plans are actually sold.

Forms

• Plan Interest: two questions: which tier, and would you like a call or a link. Submitting it does not enroll anyone; it starts a conversation.
• Plan Enrollment: the real one, on the order form: contact and service address, equipment schedule entries, billing frequency, an explicit tick confirming the terms and the auto-renewal basis have been read, and payment details captured by the processor's own hosted fields.
• Equipment Schedule Update: used at the first visit, when the tech records what is actually in the property rather than what the customer thought.
• Cancellation Request: a real, easy-to-find form rather than a phone-only process. Captures Cancellation Reason from a fixed list and routes to a human.

BO's role and guardrails

BO carries most member service contact, and the guardrails here are tighter than anywhere else in these builds because BO is talking about a contract.

• BO answers "am I covered for this" by reading Plan Tier, Plan Status and Equipment Covered and describing what the tier includes in the plan's own published wording. BO states what the plan says, and never interprets, extends or guesses.
• BO never confirms that a specific repair will be covered. Coverage decisions on an actual fault are made by a person who has seen it. BO's line is that the tier includes the category and a tech will confirm on site.
• BO never states any price, fee, rate or discount, not the plan, not an excess, not a benefit amount. BO sends the comparison page or offers a Plan Consultation booking.
• BO never cancels a plan, never pauses billing and never changes a tier. Those all create a task for a human, and BO says so plainly rather than implying it is done.
• BO can tell a member their remaining entitlement, their next visit date and their renewal date, and can send the booking link and the payment-update link.
• BO escalates immediately on any cancellation request, any dispute about what was promised, any mention of a chargeback, and any complaint about billing.

Numbers and channels

• Inbound calls matched to a contact carrying plan-member route to a member queue with a whisper message naming the tier, so whoever answers knows before they speak. Where Priority Response Entitled is set, the call jumps the normal queue.
• The business SMS number for visit scheduling and billing-failure messages. Billing messages must come from a number the member recognizes, never a short code they will assume is a scam.
• Email for the plan certificate, the terms, the renewal notice and the annual benefit summary, sent from an authenticated domain. These are the messages that must not land in spam, because a missed renewal notice is a complaint waiting to happen.
• Payment-method update links generated by the processor and sent by both SMS and email. Never collect card details over the phone into a CRM field, and never store them anywhere in the platform.

1. A tech finishes a repair on a nine-year-old boiler and submits the Job Debrief. The candidate workflow sees a completed job, equipment over five years old, and no existing plan, so the opportunity is created in Plan Enrollment at Plan Candidate with Enrollment Source set to At Job.
2. Before leaving, the tech sends the plan explainer page from their phone. The homeowner opens it in the kitchen while the tech is washing their hands, which is the highest-converting moment this build has.
3. Two hours later the automated offer lands: a short message naming the boiler, pointing at the comparison page, with the Protect tier highlighted because the equipment age and the repair history fit that tier's coverage. The stage moves to Plan Offered.
4. The homeowner visits the page, reads the terms, and opens the Protect order form. The stage moves to Considering on the page visit.
5. They complete the Plan Enrollment form: address, the boiler plus a hot water cylinder as two equipment entries, monthly billing, the terms tick, and card details entered into the processor's hosted fields. The stage moves to Signed, Payment Pending and Plan Status is set to Pending Payment.
6. The first payment clears. The processor webhook writes Subscription Reference, and the activation workflow sets Plan Status to Active, Plan Start Date to today, Plan Renewal Date to twelve months out, Visits Included Per Year to the tier's allowance, Visits Used This Year to zero, and Priority Response Entitled from the tier. Tags plan-member and tier-protect are applied. The stage moves to Active and a new opportunity opens in Member Servicing.
7. Within minutes they get the welcome pack: the plan certificate as a PDF, the terms, member-area credentials, and, critically, a booking link for their first included service visit, with available dates already in it. Enrollment and the first booking happen in the same session or they frequently never happen at all.
8. They book a visit for six weeks out. The stage moves to Visit Scheduled. The standard appointment reminder ladder takes over.
9. At that visit the tech runs the full service and submits the Equipment Schedule Update, correcting the cylinder model and adding its serial number. Visits Used This Year increments to 1, Last Visit Date is written, Next Visit Due is set twelve months on, and the stage moves to Visit Completed, then back to Active, Visit Not Due.
10. Four months later their boiler loses pressure on a Tuesday morning and they ring the main line. Caller ID matches a contact tagged plan-member with Priority Response Entitled set. The call jumps the queue and the whisper message tells the office "Protect member, two appliances covered" before anyone says hello.
11. The office books them into a held Member Priority Response slot that afternoon. A slot that existed because the calendar holds some back rather than selling every hour first-come.
12. In month nine the card on file reaches its expiry month. The card-expiry workflow sends a payment-update link ten days before the next billing date, and the payment never fails at all. This is the cheapest churn the business will ever prevent.
13. In month eleven the renewal workflow sends a benefit summary: the visits delivered, the priority call-out attended, the equipment on the schedule and the renewal date. No figures, because any change to terms is communicated separately and in writing. Then it sends the booking link for next year's included visit.
14. Two weeks before renewal, a formal renewal notice goes out stating the renewal date, that the plan continues automatically, and exactly how to cancel. Sending that notice properly is both a compliance matter and the thing that stops a member feeling trapped, and members who do not feel trapped cancel less.
15. If instead the payment had failed in month nine, the stage would have moved to Payment Failed, Plan Status to Payment Failed, and the dunning workflow would have run its retries and messages. Had it exhausted them, the member would sit at At Risk with a human task: never silently canceled by a workflow.

1. Plan Candidate Identification and Offer

Trigger: Job Debrief submitted, or a daily scan of customers with a job completed in the last ninety days and no plan.

Conditions and branches: exclude anyone with Plan Status other than None, anyone tagged plan-not-suitable, and anyone offered a plan in the last six months. Branch on equipment age to pick the recommended tier: newer equipment fits Essential, older or multiple appliances fit Protect, and a property with three or more covered items fits Protect Plus.

Actions in order:

1. Create the opportunity in Plan Enrollment at Plan Candidate. Apply plan-candidate. Set Enrollment Source.
2. If the trigger was a debrief, create a task for the tech to send the plan explainer page before they leave site. The door-step send converts better than anything the office does later, so the workflow should prompt it rather than replace it.
3. Wait two hours from job completion so the offer does not collide with the feedback request.
4. Move to Plan Offered. Apply plan-offered. Send SMS: "Hi {{Customer first name}}, {{Tech first name}} mentioned our service plan while he was with you. Your {{Equipment Make and Model}} is the kind of thing it's designed for: a service every year, priority if something goes wrong, and no scrambling for a tradesperson in January. Everything that's included, side by side: {{plan comparison page}}"
5. Wait two days. If the page was not visited, send an email with the three tiers laid out and a link to book a Plan Consultation for anyone who would rather talk it through.
6. Wait five days. If the page was visited but no enrollment started, send one message addressing the most common objection honestly: "No hard sell. Plenty of people are better off without a plan, and if your {{Equipment Make and Model}} is newer that may be you. If you want a straight answer, book ten minutes and we'll tell you either way: {{Plan Consultation link}}"
7. Wait seven days. If nothing, move to Declined with Cancellation Reason left blank and no reason recorded, and schedule re-entry eligibility for six months out, timed to the equipment's next service date.
8. On a page visit, move to Considering. On an order-form start, enter workflow 2.

Stop and exit conditions: three messages maximum, then silence for six months. Stops on enrollment, on a consultation booking, on any reply declining, or on plan-not-suitable being applied. Never runs on a contact with service-recovery-open.

2. Enrollment Completion and Activation

Trigger: Plan Enrollment form submitted on the order form.

Conditions and branches: branch on whether the first payment succeeded. Branch on Billing Frequency. Branch on whether the equipment listed is within eligibility rules.

Actions in order:

1. Move to Signed, Payment Pending. Set Plan Status to Pending Payment. Write Plan Tier, Billing Frequency, the equipment entries and the consent record including the terms version shown.
2. On the payment-succeeded webhook: write Subscription Reference, set Plan Status to Active, Plan Start Date to today, Billing Day, and Plan Renewal Date to twelve months out.
3. Set Visits Included Per Year from the tier, Visits Used This Year to zero, Visit Window Opens to today, Visit Window Closes to the renewal date, and Priority Response Entitled from the tier.
4. Apply plan-member, the tier tag and the billing-frequency tag. Remove plan-candidate and plan-offered.
5. Move the Plan Enrollment opportunity to Active and create a new opportunity in Member Servicing at Active, Visit Not Due.
6. Generate the plan certificate as a PDF and send the welcome email: certificate attached, terms attached, member-area credentials, the equipment schedule as recorded, how priority response works, and how to cancel. Putting cancellation in the welcome email is deliberate and it does not increase cancellations.
7. Send SMS immediately after: "You're all set, {{Customer first name}}, welcome aboard. Your first service visit is included; grab a slot that suits you here: {{Plan Service Visit booking link}}"
8. Wait three days. If no visit is booked, send one reminder, because the first-visit booking is the strongest predictor of whether this member is still a member in a year.
9. Wait fourteen days, then move the record into workflow 4's scheduling logic regardless.
10. If the equipment entered fails eligibility, do not take a second payment. Apply plan-not-suitable, create an urgent task for the office to call and refund the first payment, and move to Not Suitable. Selling cover you cannot honor is the one mistake that is worse than not selling.

Stop and exit conditions: exits once Plan Status is Active and the servicing record exists. If the payment never succeeds, hands to workflow 3.

3. Pending Payment Rescue

Trigger: Plan Status is Pending Payment for more than fifteen minutes.

Conditions and branches: branch on the processor's decline reason. An authentication failure needs a different message from an insufficient-funds decline.

Actions in order:

1. Send SMS: "{{Customer first name}}, we've got your plan details but the first payment didn't go through, usually just a bank check. Here's a secure link to finish it: {{payment link}}"
2. If the reason was authentication, add: "Your bank may ask you to approve it in their app."
3. Wait one hour. If still pending, send the same link by email with the plan summary so the customer can see what they were signing up to.
4. Wait twenty-four hours. If still pending, create a task for the office to call. A person recovers these far more often than a link does.
5. Wait seven days. If still pending, move to Declined, set Plan Status back to None, remove any member tags, and make sure no member benefits are live. A record must never sit indefinitely in a state where the member thinks they are covered and the business is not being paid.

Stop and exit conditions: stops on payment success, which returns to workflow 2. Two automated messages and one human task, then close.

4. Included Visit Scheduling and Entitlement Tracking

Trigger: daily scan of active members where Next Visit Due falls within sixty days and Visits Used This Year is below Visits Included Per Year.

Conditions and branches: branch on whether a visit is already scheduled. Branch on whether the window is about to close. Branch on Plan Tier for slot length.

Actions in order:

1. At sixty days out, move to Visit Due and apply visit-due. Send email: "It's nearly time for the service visit included in your plan. Here's the calendar. Pick whatever suits: {{Plan Service Visit booking link}}"
2. Wait fourteen days. If unbooked, send SMS: "Hi {{Customer first name}}, your included service visit is due. Two taps: {{booking link}}"
3. Wait fourteen days. If unbooked, send a message naming the deadline plainly: "Your included visit needs to happen before {{Visit Window Closes}}. Dates are filling up for that period. Here's what's left: {{booking link}}"
4. Wait ten days. If unbooked, create a task for the office to call and book it on the member's behalf. By this point an automated message has had three attempts and a phone call is owed.
5. On booking: move to Visit Scheduled, apply visit-scheduled, and enter the standard appointment reminder ladder with an added line confirming the visit is included.
6. On completion: increment Visits Used This Year, write Last Visit Date, set Next Visit Due by the service interval, move to Visit Completed then Active, Visit Not Due, and run the Equipment Schedule Update so the schedule stays accurate.
7. If Visit Window Closes passes with the visit unfulfilled: move to Visit Overdue, apply visit-overdue, and create a task on the owner, not the member. The business owes a visit it has been paid for, and that is an internal problem to solve, not a customer to nag.
8. At the renewal date, reset Visits Used This Year to zero and roll the window dates forward. Decide explicitly whether unused visits carry over, document it in the terms, and have the workflow enforce whatever the terms say.

Stop and exit conditions: three member messages, then a human task, then an internal escalation. Stops on booking or on the plan ceasing to be active. Never sends while payment-failed or cancellation-requested is present.

5. Card Expiry Pre-emption

Trigger: daily scan where Payment Method Expiry Month falls in the current or next month, or the processor flags an upcoming invoice with an expiring method.

Conditions and branches: branch on whether the processor's automatic card updater has already replaced the method. If so, exit silently and send nothing.

Actions in order:

1. Apply card-expiring.
2. Fourteen days before the next billing date, send email: "Nothing's wrong. The card on your plan is due to expire. Updating it now means your cover carries on without interruption: {{payment update link}}"
3. Wait seven days. If not updated, send SMS with the same link from the business number, worded so it does not read as a phishing message: "{{Business name}} here. The card on your service plan expires soon. You can update it in your member area or here: {{payment update link}}. We'll never ask you for card details by text or phone."
4. Wait five days. If not updated, create a task for the office to call before the billing date rather than after the failure.
5. On update: remove card-expiring, write the new Payment Method Expiry Month, and send a one-line confirmation.

Stop and exit conditions: stops on update, on the updater handling it, or on cancellation. Two messages and one task maximum. Preventing the failure is always cheaper than recovering it.

6. Failed Payment Dunning and Recovery

Trigger: payment-failed webhook from the processor.

Conditions and branches: branch on Last Payment Failure Reason: insufficient funds gets different timing and wording from an expired card or a hard decline. Branch on Dunning Attempt Count. Branch on tenure: a member of three years gets a phone call earlier than a member of three weeks.

Actions in order:

1. Set Plan Status to Payment Failed. Move to Payment Failed. Apply payment-failed and dunning-active. Increment Dunning Attempt Count. Write the failure reason.
2. Suspend every marketing send to this contact. A plan upsell email landing the day after a failed payment is the kind of error members remember.
3. Within one hour, send SMS: "Hi {{Customer first name}}, this month's plan payment didn't go through. Usually it's just the card. Here's a secure link to sort it: {{payment update link}}. Your cover is still in place for now."
4. Wait twenty-four hours. If unresolved, send email with the same link plus what happens next and by when, stated plainly rather than implied.
5. Wait three days. Let the processor's automatic retry run: do not place your own retry on top of it. If it succeeds, exit.
6. Wait two more days. If unresolved, create a task for the office to phone. Say in the task what the member is entitled to while in arrears, so whoever calls is not improvising a policy.
7. Wait five days. If unresolved, send the final notice: states the arrears, states what happens to cover, and gives the link one more time. No pressure tactics and no threats: just facts and a date.
8. Wait three days. If still unresolved: move to At Risk, apply plan-at-risk, remove Priority Response Entitled, and create a decision task on the owner. No workflow cancels a plan. A person decides, every time, and that decision is logged with a date.
9. On recovery at any point: clear payment-failed and dunning-active, reset Dunning Attempt Count to zero, restore Plan Status to Active and Priority Response Entitled, return to the previous servicing stage, resume marketing, and send a short thank-you that does not mention the failure again.

Stop and exit conditions: stops instantly on successful payment or on the member canceling. Four messages across two weeks, then human ownership. Members in dunning are excluded from every campaign, every review request and every upsell for the duration.

7. Renewal Notice and Annual Benefit Summary

Trigger: daily scan where Plan Renewal Date falls in forty-five days.

Conditions and branches: branch on whether the terms are changing at renewal. Branch on whether the member actually received their entitled visits. A member who received nothing must not be sent a summary claiming value.

Actions in order:

1. At forty-five days, if Visits Used This Year is zero, suppress the summary entirely, escalate to the owner, and get the visit done before the renewal conversation happens. This branch exists to stop the business invoicing for a promise it did not keep.
2. At thirty days, send the benefit summary email: visits delivered with dates, priority call-outs attended, the equipment on schedule, and the work carried out over the year. Facts drawn from the record, no figures, no claims.
3. At twenty-one days, send the formal renewal notice: the renewal date, that the plan renews automatically, the renewal basis, and precise instructions for canceling including the link to the Cancellation Request form. If terms are changing, that notice carries the change in writing and is sent with whatever notice period the terms and local law require.
4. At fourteen days, send one upgrade or review message only where it is genuinely appropriate. For example where the equipment schedule has grown since enrollment: "Your cover is set up for {{Equipment count}} items and we've recorded more at the property since. Worth ten minutes to check you're on the right tier: {{Plan Consultation link}}"
5. On the renewal date: roll Plan Renewal Date forward twelve months, reset Visits Used This Year, roll the visit window, and send a short confirmation with next year's booking link.
6. If the renewal payment fails, hand to workflow 6: do not treat it as a cancellation.

Stop and exit conditions: the formal renewal notice sends regardless of engagement, because it is a compliance artefact rather than marketing. Stops on cancellation. Upgrade messaging is suppressed for anyone in dunning, at risk, or with an open complaint.

8. Cancellation, Save Attempt and Offboarding

Trigger: Cancellation Request form submitted, inbound message BO classifies as a cancellation request, or the processor reporting a customer-initiated subscription cancellation.

Conditions and branches: branch on Cancellation Reason. Branch on whether the member received their entitled visits. Branch on whether a complaint is open. If so, skip every save attempt and go straight to a human.

Actions in order:

1. Apply cancellation-requested. Write Cancellation Requested Date and Cancellation Reason. Move to At Risk. Acknowledge within minutes, because a cancellation request that goes unacknowledged becomes a chargeback.
2. Send: "Thanks {{Customer first name}}: that's received and we'll process it. {{Office contact}} will confirm the effective date today. If there's something we got wrong, we'd genuinely like to know."
3. Create a task for a named human. One save attempt is permitted, by phone, by a person, and it is logged in Save Attempted. No automated save sequence, no retention maze, no delaying the cancellation while a sequence runs.
4. Branch by reason. "Never had a visit" goes straight to the owner and the visit is offered immediately with no retention pitch attached. "Moving house" offers a transfer to the new address or to the incoming owner. "Too expensive" offers a tier conversation on a Plan Consultation booking, with any figures given by the person on the call rather than in a message. "One bad experience" routes to service recovery first and retention never.
5. Process the cancellation within the notice period in the terms, whatever the save attempt's outcome. Write Cancellation Effective Date, cancel the subscription with the processor, and confirm in writing by email with the effective date and the final billing position.
6. On the effective date: set Plan Status to Canceled, move to Canceled, apply plan-canceled, remove plan-member, the tier tag and Priority Response Entitled, and revoke member-area access to member-only content while leaving their own records and documents available to download for a stated period.
7. Send the offboarding email: confirmation, the service history and equipment schedule as a downloadable record, and nothing that argues.
8. Wait thirty days, then apply win-back-eligible unless the reason was a complaint or the member asked not to be contacted.

Stop and exit conditions: cancellation always completes within the contractual notice period, regardless of save outcome. One save attempt, by a human, logged. No automated message ever attempts to talk a member out of canceling.

9. Lapsed Member Win-Back

Trigger: win-back-eligible applied, or Plan Status set to Lapsed thirty days earlier.

Conditions and branches: branch on Cancellation Reason: complaints, service failures and opt-outs are permanently excluded. Branch on whether their equipment is still within eligibility.

Actions in order:

1. At thirty days, send one email: no offer, just the equipment's service date approaching and a one-off booking link. Selling a plan back to someone who just left it does not work; selling them a service visit does.
2. Wait sixty days. If the equipment's service date is now near, send a reminder naming it: "Your {{Equipment Make and Model}} is due a service around {{Next Visit Due}}. Happy to do it as a one-off: {{Annual Service booking link}}"
3. On a one-off visit being booked and completed, wait fourteen days and then re-offer the plan once, through workflow 1, with Enrollment Source set to Renewal Reminder.
4. If no engagement after both messages, remove win-back-eligible and leave the contact in the general customer base. No perpetual win-back loop.

Stop and exit conditions: two messages, ever. Stops on any booking, on opt-out, or on a reply asking to be left alone. Permanently excluded for anyone whose cancellation reason was a service failure or complaint.

The plan stops being a spreadsheet and becomes a state machine. Plan Status is authoritative, written only by automation, and read by the phone system, the calendars, every campaign's suppression logic and every report. That single piece of discipline is what makes everything else possible: whoever answers the phone knows who they are talking to, and the business can produce a clean member list on demand.

The entitlement gets delivered. Before this build, the included visit happened if the customer remembered to ring. Afterwards, the scheduling window opens on a date the system calculated, the member is invited three times, and if the window closes unfulfilled the record lands in Visit Overdue where it is visible as an unmet obligation rather than quietly becoming a cancellation three months later. Running a plan without that stage is running an unmeasured liability.

Involuntary churn largely disappears, which is the fastest financial win in the build. Expiring cards get caught before they fail. Failures that do happen get a structured retry and message sequence instead of an email to an unwatched inbox. And a member is never canceled by silence: a person decides.

Finally, cancellation becomes information. A reason from a fixed list, captured every time, tells you whether people leave because the plan stopped feeling worth it, because they never got a visit, because they moved house, or because of one bad experience. Those are four completely different problems and before this build they all looked the same.

Metrics to watch:

• Plan penetration: active members as a share of serviceable customers, trended monthly. The single headline number.
• Offer-to-active conversion, and separately the drop-out at Signed, Payment Pending. A high pending drop-out is a payment-flow problem, not a sales problem, and it is usually fixable in an afternoon.
• Enrollment conversion by Enrollment Source: at-the-door enrollment almost always outperforms every digital channel, and knowing by how much tells you where to spend effort.
• Visit fulfillment rate: visits delivered divided by visits entitled, per plan year. Treat anything short of near-complete as a live problem.
• Visit Overdue count as an absolute number, reviewed weekly. This is the liability register.
• Involuntary churn rate (lapses caused by payment failure) tracked separately from voluntary cancellation. Conflating them hides the cheapest fix in the business.
• Dunning recovery rate: the share of failed payments recovered, and at which attempt. If recovery mostly happens on attempt three, the earlier messages need rewriting.
• Card-expiry pre-emption rate: payment methods updated before a failure, as a share of cards that were due to expire.
• Voluntary churn by tenure, in cohorts by Plan Start Date. Churn concentrated in the first ninety days means the onboarding promise is not landing; churn at renewal means the value summary is not landing.
• Cancellation reason mix, and within it the share who had received no visit. That cross-tab is the most actionable number this build produces.
• Member versus non-member behavior: job frequency, emergency call-out rate and review rate, compared across the two groups. This is the evidence that tells you whether the plan is worth running at all.

The plan itself, before any software

• Write the plan terms before building anything. What is included, what is excluded, what the visit covers, what happens to equipment that fails an initial inspection, the minimum term if there is one, the renewal basis, the cancellation method and notice period, and what happens if the customer moves house. Every workflow in this build reads from those terms, and a workflow cannot be clearer than the document it describes.
• Decide the eligibility rules honestly (maximum equipment age, condition on first inspection, geography) and build plan-not-suitable to enforce them. A plan that covers equipment it should not have accepted loses money quietly for years.
• Agree the capacity arithmetic. Every plan sold is a visit owed in a specific month. Model the visit load against tech hours before launch, and keep the Plan Service Visit calendar's capacity aligned to it, or the plan sells itself into a service failure.
• Decide what priority response actually means in hours, and hold back the slots that make it true.

Payments and billing

• Stripe connected with subscriptions configured per tier and per billing frequency, and webhooks wired for payment succeeded, payment failed, subscription updated, subscription canceled and upcoming invoice. The webhooks are the spine of this build; without them the platform's view of membership drifts from the processor's within weeks.
• Enable the processor's automatic card updater where available, and still run the expiry pre-emption workflow. The updater does not catch everything.
• Strong customer authentication and 3-D Secure handled correctly on first payment, and a tested path for what happens when a renewal payment requires authentication the customer has to complete.
• QuickBooks or Xero connected for subscription revenue, and an agreed treatment for annual plans paid up front, which is deferred revenue rather than a good month. Confirm that treatment with the client's accountant.
• Never store card details in the platform. No custom field, no note, no form answer, no call recording. Payment details are captured by the processor's hosted fields only, and call recording must be paused or suppressed for any conversation where a customer might read out a card number.

Platform prerequisites

• All custom fields created first, and a firm rule that Plan Status, Visits Used This Year and the visit-window dates are written only by workflows. Allowing staff to edit those by hand is the fastest way to lose trust in the whole system.
• The member area built and tested on a phone, since that is where members will open it.
• Qualified techs assigned to the Plan Service Visit round-robin, with the slot lengths that each tier actually needs.
• Caller-ID matching tested, including the case of a member ringing from a number not on their record, which is common and must not result in a member being treated as a stranger.

SMS, email and consent

• A2P and 10DLC registration complete and approved before launch. Billing and dunning messages are exactly the traffic carriers scrutinize, and a filtered failed-payment text becomes an avoidable cancellation.
• Opt-out handling live. Note the tension and resolve it deliberately: a member who opts out of SMS must still receive billing and renewal notices, so those must have a working email and, where necessary, postal fallback. Decide that policy before launch rather than discovering it during a dispute.
• Quiet hours enforced on every send in this build. Nothing about a membership is urgent enough to arrive at night.
• Keep the consent record from the enrollment form. What was ticked, what wording was shown, and when. Version the terms and the page so you can show what a member actually agreed to on the day they agreed to it.

Compliance and legal

• Automatically renewing consumer subscriptions are specifically regulated in many jurisdictions, and the rules commonly cover pre-renewal notice, how clearly the renewal basis is disclosed at sign-up, how easy cancellation must be, cooling-off and refund rights, and record-keeping. Those rules vary by market and they change.
• Build the easy cancellation path properly (a real form, found easily, routed to a human) rather than a retention maze. It is the right thing to do and in several markets it is also the required thing to do.
• Equipment schedules, serial numbers, service histories and property details are a detailed picture of someone's home. Apply role-based visibility, set retention periods, and have a documented process for a member who asks for their data or asks to be erased after cancellation, bearing in mind that some records must be kept for warranty, safety or tax reasons.
• None of this is legal advice. The plan terms, the auto-renewal and cancellation disclosures, the pre-renewal notice content and timing, the cooling-off handling, the consent wording and the retention schedule must all be drafted or reviewed by the client's own counsel for their jurisdiction and sector before the plan is sold to anyone. For scoping and pricing the build itself, book a call at bookings.appbo.io.