Back to the build library
Home services
Standard

Seasonal Maintenance Program

Recurring service agreements that bill on their own and schedule themselves ahead of each season, instead of waiting for the customer to remember.

Industry
Home services
Build effort
Standard
Typical time to launch
3–5 weeks
On this page
The problemWhat gets builtHow it runsAutomations in detailWhat changesBefore you start
Want this built for you?

Bring your stack to a call and we will scope it against how your business actually runs.

Book a call
01

The problem

Almost every home services business sells some version of a maintenance plan, and almost none of them run it as a system. The agreement is signed, the customer is charged, and then the obligation to deliver it sits in a spreadsheet that someone is supposed to work through in spring. In practice the spring tune-ups get booked in June, the autumn ones in November, and a meaningful share never get booked at all - which means the business has taken money for work it did not perform and has no idea how often that happens.

That is the operational failure. The commercial failure is larger. A maintenance plan is the only thing in a home services business that produces predictable revenue, fills the dead weeks between peak seasons, and creates a reason to be inside a customer's home twice a year - which is where replacement work is discovered. Run badly, it does none of that. The calendar still collapses into two frantic peaks with two dead troughs. Plans lapse quietly because a card expired and nobody chased it. Customers who paid for two visits and received one do not renew, and they do not say why.

And the seasonal timing itself is the part automation is actually good at. Nobody wants a furnace tune-up in January; they want it in September, which means the booking conversation has to start in August, which means it has to start without anyone remembering. Businesses that chase it manually always start too late, because the moment they should be filling September is the moment they are busiest with summer emergencies. This build makes the plan bill itself, schedule itself ahead of each season, and surface the ones that did not get delivered while there is still time to fix it.

02

What gets built

Pipelines and stages

Two pipelines, because selling a plan and delivering a plan are different jobs with different failure modes.

Plan Enrollment - the sales side:

  • Offered - plan presented, usually at the end of a completed job.
  • Considering - interested, not signed.
  • Agreement Sent - terms and payment authorization sent.
  • Active - signed and first payment taken.
  • Declined, Lapsed - the second for plans that were active and stopped.

Maintenance Visits - the delivery side. One opportunity per entitled visit per season, created automatically, so an undelivered visit is a visible object rather than an omission:

  • Due This Season - the season window has opened, nothing offered yet.
  • Booking Offered - windows sent, no selection yet.
  • Booked - on the calendar.
  • Completed - visit delivered, report sent.
  • Findings to Quote - the technician found work beyond the maintenance scope.
  • Deferred by Customer - customer declined this season's window, with a reason.
  • Season Missed - the window closed undelivered. This stage exists so the number cannot be hidden.

Calendars

  • Maintenance - Spring and Maintenance - Autumn (or the business's real season names). Each opens only inside its season window - say 1 March to 31 May and 15 August to 15 November - so a maintenance visit can never be booked into a peak-emergency week.
  • Shoulder-week priority. Inside each season window, open the quietest weeks first and hold the final two weeks closed until the quiet weeks are filled. This is how the plan does its real job: flattening the calendar.
  • Visit duration set by plan tier - 60 minutes for a single-system tune-up, 90 for a two-system property - with a 30-minute travel buffer after.
  • Daily maintenance cap per technician, so maintenance never crowds out paid emergency work entirely. Five or six visits is usually the ceiling.
  • Where the estimate-scheduling build is also live, mirror the territory day rules onto these calendars. Maintenance visits are short and dense, which makes them the single best candidate for geographic batching.

Custom fields

  • plan_tier - single select: Essential, Complete, Priority (or the business's own names).
  • plan_status - single select: Active, Payment Failed, Paused, Lapsed, Canceled.
  • plan_start_date, plan_renewal_date - dates. The renewal date drives the entire renewal sequence.
  • billing_frequency - single select: Monthly, Annual.
  • visits_entitled_per_year - number. visits_delivered_this_term - number. The difference between these two fields is the business's unperformed obligation, and it should be on a dashboard.
  • season_window - single select: Spring, Autumn. Written on each visit opportunity.
  • equipment_list - long text: what is covered, make, model, age, location in the property.
  • last_visit_date, next_visit_due - dates.
  • priority_response - checkbox. Whether this tier gets front-of-queue on emergencies, which is usually the most valuable thing the plan actually sells.
  • findings_summary - long text, written at each visit. The running health record of the property.
  • replacement_flagged - checkbox, with replacement_notes. Set when a technician judges equipment near end of life.
  • payment_failed_count - number. card_expiry - date, used for the pre-emptive update prompt.
  • renewal_decision - single select: Renewed, Declined, Upgraded, Downgraded.
  • lapse_reason - single select: Payment, Moved house, Replaced equipment, Price, No reason given.

Tags

  • plan-active, plan-lapsed, plan-paused - the headline segments for everything else in the account.
  • plan-essential, plan-complete, plan-priority - tier mirrors, used for routing and for emergency queue priority.
  • season-due-spring, season-due-autumn - applied when a season window opens for this contact.
  • visit-unbooked - entitled, offered, not booked. The tag the business should watch most closely mid-season.
  • season-missed - a window closed undelivered. Every one of these needs a human decision about credit or goodwill.
  • payment-failed, card-expiring - dunning segments.
  • renewal-window - applied 60 days before plan_renewal_date.
  • replacement-candidate - equipment flagged near end of life. The most valuable list the business owns.
  • plan-eligible - a past customer with no plan whose job type makes them a sensible target.
  • sms-opted-out.

Forms and pages

  • Plan Comparison Page - a landing page setting out the tiers side by side: what each includes, how many visits, whether priority response applies, and the enrollment button. No invented savings claims; describe what is included and let the customer judge.
  • Plan Enrollment - name, service address, equipment details, tier selection, billing frequency, payment authorization, and explicit acceptance of the agreement terms.
  • Equipment Details - make, model, age, location, last serviced. Collected at enrollment and updated at each visit, because this record is what makes the maintenance visit efficient and the replacement conversation credible.
  • Maintenance Visit Report - the technician's on-site form: checklist items completed, readings taken, findings_summary, replacement_flagged, photos.
  • Season Deferral - a short page for a customer who cannot take a window this season, capturing why and whether they want to be re-offered later in the window.

BO's role and guardrails

BO runs the season booking conversation and the payment-failure conversation, and neither of those is a sales conversation.

  • BO opens each season by offering specific windows from the relevant season calendar, not by asking whether the customer would like to book. The default is that the visit is happening; the customer picks when.
  • BO never states plan pricing or discounts. Tier questions get the comparison page link and an offer to have someone call.
  • BO never quotes repair or replacement work found during a visit. Findings go to Findings to Quote and a human prices them.
  • BO never cancels a plan. A cancellation request goes to a human within the hour - that conversation is worth a person every time.
  • BO never tells a customer their equipment needs replacing. It reports that the technician has flagged something and that someone will follow up with detail.
  • BO handles payment failures factually and without pressure: states that the payment did not go through, gives the update link, and stops after the sequence ends.
  • BO hands off on: any cancellation request, any dispute about what the plan covers, any complaint about a missed season, and any request for a refund or credit.

Numbers and channels

  • The existing local business number for season booking and reminder SMS, registered for application-to-person messaging.
  • Email as the primary channel for agreements, receipts, visit reports and renewal notices - these are documents the customer may need later, and SMS is the wrong place for a document.
  • Payment handled entirely through the connected processor's hosted pages, so no card details are ever stored in the platform.
  • A dashboard visible to the owner carrying four numbers: active plans, visits entitled versus delivered this term, unbooked visits in the open season, and plans in the renewal window.
03

How it runs, step by step

One customer across a full plan year, from the moment the plan is offered to the moment it renews.

  1. Day 0 - the offer, at the right moment. A repair job reaches Work Complete. Two hours later - after the satisfaction check, never before it - an email and text offer the maintenance plan with a link to the Plan Comparison Page. An opportunity opens in Plan Enrollment at Offered. This timing is deliberate: the plan is easiest to sell on the day a customer has just experienced why it matters.
  2. Day 2 - enrollment. The customer picks the Complete tier, monthly billing, and submits Plan Enrollment with equipment details for a furnace and an air conditioner. Payment authorization goes through the processor's hosted page. The opportunity moves to Active, plan_status is set to Active, plan_start_date and plan_renewal_date are written, visits_entitled_per_year is set to 2, and plan-active plus plan-complete go on the contact.
  3. Day 2 - the welcome that sets expectations. An email confirms the agreement, restates exactly what the two visits cover, names the two season windows the visits will fall in, and confirms priority response if the tier includes it. The agreement PDF and the first receipt are attached. Nothing here is a marketing email; it is a record.
  4. Day 2 - delivery obligations created immediately. Two opportunities open in Maintenance Visits at Due This Season - one tagged Spring, one Autumn - dormant until their windows open. The obligation now exists as an object, which is the single most important design decision in this build.
  5. 15 August - the autumn window opens. The autumn visit wakes up. season-due-autumn is applied, and BO sends the first booking offer with three specific windows drawn from the quietest weeks of the Maintenance - Autumn calendar: "Your autumn furnace service is due. I have Wed 27th 8-10am, Thu 28th 10am-12pm or Tue 2nd 1-3pm. Reply 1, 2 or 3." The opportunity moves to Booking Offered.
  6. 18 August - booked. The customer picks the Thursday. The appointment lands on the autumn calendar, the opportunity moves to Booked, and a confirmation goes out with an .ics attachment. Three weeks of lead time, in a quiet week, with no one in the office having thought about it.
  7. 28 August - the visit. The technician arrives with the equipment_list already on their phone - make, model, age, location - so the visit is 55 minutes of work rather than 20 minutes of hunting. They complete the Maintenance Visit Report: checklist items, readings, four photos.
  8. 28 August - findings. The furnace is fine. The air conditioner's compressor is 16 years old and showing its age. The technician ticks replacement_flagged and writes replacement_notes. findings_summary is written in plain language.
  9. 28 August - completion and report. The opportunity moves to Completed, visits_delivered_this_term increments to 1, last_visit_date is written and next_visit_due is set to the spring window. The customer gets an email report: what was checked, the readings, the photos, and the honest note that the AC is near end of life with no pressure and no price attached.
  10. 28 August - the replacement path opens properly. replacement-candidate is applied and a task goes to the estimator, not a sales email to the customer. A human decides when and how to have that conversation. This is the single highest-value output of the whole build and it is deliberately not automated past this point.
  11. 4 November - a payment fails. The monthly charge is declined. plan_status moves to Payment Failed, payment_failed_count increments, payment-failed is applied, and BO sends a factual message with an update link. No threat, no urgency language. The customer updates the card two days later, plan_status returns to Active, and the tag clears.
  12. 1 March - the spring window opens. The spring visit wakes up and the same booking sequence runs. The customer is traveling and submits Season Deferral, so the opportunity moves to Deferred by Customer with a reason and a flag to re-offer later in the window.
  13. 20 April - re-offered and delivered. BO re-offers windows, the customer books, and the spring visit completes. visits_delivered_this_term reaches 2. The plan has now actually delivered what it sold, and the system can prove it.
  14. 60 days before renewal - the renewal sequence. renewal-window is applied. The renewal email leads with the record rather than the offer: both visits delivered, the dates, the findings each time, and the AC note still standing. Then the renewal terms.
  15. Renewal. The customer renews and upgrades to the tier with priority response, having spent a winter thinking about that compressor. renewal_decision is set to Upgraded, plan_renewal_date rolls forward, visits_delivered_this_term resets to 0, and two fresh visit opportunities are created for the new term. The cycle restarts without anyone touching it.
04

Automations in detail

Eight workflows. Workflow 2 is the one that makes the build work - if visit obligations are not created as objects at enrollment, every other workflow is guessing.

1. Plan Offer at Job Completion

Trigger: a job reaches Work Complete, or a completed-job tag is applied.

Conditions: exit if the contact already carries plan-active, if they carry a detractor tag from the job, or if job_type was Warranty. Never sell to someone whose repair just went badly.

  1. Wait 1 day, so the plan offer never lands before the satisfaction check.
  2. Apply plan-eligible. Create an opportunity in Plan Enrollment at Offered.
  3. Send email - "{{first_name}}, now that the {{job_type}} is sorted, the thing that keeps it from happening again is a service twice a year. Here is what our plans cover: {{plan_page_link}}." The email describes coverage; it makes no claim about savings.
  4. Wait 2 days. Send SMS - "Quick one, {{first_name}} - our maintenance plan covers the twice-yearly service on your {{equipment_type}} and puts you in front of the queue when something goes wrong. Worth a look? {{plan_page_link}}"
  5. Wait 5 days. On no engagement, send one final email framed around the next season: "Autumn is when these get booked out. If a plan makes sense, now is the moment."
  6. Wait 7 days. Move to Declined and apply a 180-day re-offer tag. Stop. Three touches is the whole sequence.
  7. On any click to the plan page: move to Considering and notify whoever sells plans. A human closes from here.

Exit: enrollment completed, declined, opt-out, or sequence end.

2. Enrollment, Welcome and Obligation Creation

Trigger: Plan Enrollment form submitted with payment authorization successful.

  1. Set plan_status to Active. Write plan_tier, plan_start_date, billing_frequency, visits_entitled_per_year from the tier, and plan_renewal_date as plan_start_date plus one year. Set visits_delivered_this_term to 0.
  2. Apply plan-active and the matching tier tag. Set priority_response from the tier.
  3. Move the Plan Enrollment opportunity to Active.
  4. Create one opportunity in Maintenance Visits per entitled visit, at Due This Season, each with season_window set to the season it belongs to. Do this now, at enrollment - not at the start of the season. An obligation that exists as a record cannot be quietly forgotten, and this is the structural reason the build works.
  5. Send the welcome email: agreement PDF, first receipt, what each visit covers, which two season windows the visits fall in, and the priority response terms if applicable.
  6. Send the Equipment Details form if equipment_list is thin - make, model, age, location. Wait 2 days and send one reminder if still empty.
  7. Notify the office so the plan is known to whoever answers the phone.

Exit: welcome sent and visit obligations created.

3. Season Window Opens and Booking Sequence

Trigger: the season window start date is reached, for every Maintenance Visits opportunity with matching season_window at Due This Season.

Conditions: exit if plan_status is anything other than Active - a plan in Payment Failed or Paused does not get offered visits until it is resolved. Spread the trigger across the first two weeks of the window rather than firing every contact on day one, or the booking replies will arrive faster than the office can absorb them.

  1. Apply the season tag. Move to Booking Offered, apply visit-unbooked.
  2. Send SMS with three specific windows from the season calendar's open weeks - "Hi {{first_name}}, your {{season}} {{service_name}} is due. I have {{slot_1}}, {{slot_2}} or {{slot_3}}. Reply 1, 2 or 3, or BOOK for other times." Note the framing: the visit is due, not optional.
  3. Send the matching email with a booking link scoped to the season calendar.
  4. Wait 4 days. On no response, send three fresh windows - the earlier ones have likely been taken, and saying so is both true and useful.
  5. Wait 7 days. Send email with the seasonal reason attached: "Getting this done before the first cold week is the whole point of the plan - it is much harder to get a slot once the emergencies start."
  6. Wait 10 days. Create a task for the office to call. A paid-for visit going unbooked is worth a human phone call.
  7. Wait 14 days. Send a last message offering the Season Deferral page as an explicit alternative - "If this season is not workable, tell me here and I will stop chasing: {{deferral_link}}."
  8. On booking: move to Booked, remove visit-unbooked, write the appointment, and send confirmation with .ics attached.
  9. On deferral submitted: move to Deferred by Customer, record the reason, and if they asked to be re-offered, schedule one further offer for 30 days later while the window is still open.

Exit: booked, deferred, window closed, or opt-out.

4. Visit Reminders and Delivery

Trigger: maintenance appointment on a season calendar.

  1. 3 days before: send SMS - "Reminder: your {{season}} service is {{arrival_window}}. Reply Y to confirm or R to move it. {{technician_first_name}} will need access to {{equipment_location}}."
  2. 1 day before: send SMS asking for an active Y. On no confirmation by 5pm, create an office call task - a maintenance no-show is a wasted slot in a quiet week that could have gone to another plan holder.
  3. Morning of: include the visit in the technician's day sheet with equipment_list, findings_summary from the last visit, and access notes. Arriving already knowing the equipment is what makes these visits profitable.
  4. On the way: send the standard on-my-way message with eta.
  5. On Maintenance Visit Report submitted: move to Completed, increment visits_delivered_this_term, write last_visit_date, set next_visit_due to the next season window, and update equipment_list with anything the technician corrected.
  6. Wait 1 hour. Send the visit report email: checklist completed, readings, photos, findings_summary in plain language, and the date of the next visit. No sales content in this email at all.
  7. Branch - replacement_flagged ticked: apply replacement-candidate, create a task for the estimator, and add one honest line to the report email: "{{technician_first_name}} noted your {{equipment_type}} is getting on in years. No action needed today - someone will be in touch to talk through options when you are ready." No price, no urgency, no automated quote.
  8. Branch - findings beyond maintenance scope: move the opportunity to Findings to Quote and notify the estimator. A human prices it.

Exit: visit completed and report sent, or appointment canceled.

5. Season Miss Watcher

Trigger: daily, checking every Maintenance Visits opportunity against its season window end date.

  1. 21 days before the window closes: notify the office with a list of every contact still carrying visit-unbooked. This is the report that saves the season, and it has to arrive while there is still capacity to fix it.
  2. 14 days before: send those contacts one direct message - "{{first_name}}, there are two weeks left in the {{season}} window and your service is still unbooked. Here is what is left: {{slot_1}}, {{slot_2}}. After that we are into {{next_season_pressure}}."
  3. 7 days before: escalate to the owner with the count and the names. Someone senior should be deciding whether to extend the window or add capacity.
  4. On the window closing with the visit undelivered: move to Season Missed, apply season-missed, and create a task for the owner - not an automated message to the customer. A missed season is a service failure and the response is a human decision about credit, a goodwill visit outside the window, or an explanation.
  5. Report monthly: visits entitled against visits delivered, by season and by tier. This number is the honest measure of whether the plan is a product or a subscription that takes money for nothing.

Exit: visit booked or delivered, or the miss recorded and escalated.

6. Billing, Dunning and Card Expiry

Trigger A - payment failure reported by the processor.

  1. Set plan_status to Payment Failed, increment payment_failed_count, apply payment-failed.
  2. Send SMS and email immediately - "Hi {{first_name}}, this month's plan payment did not go through - usually an expired card. You can update it here: {{update_link}}. Nothing changes on your plan in the meantime." Factual, no threat, no urgency language.
  3. Wait 3 days. Retry the charge. On failure, send one reminder.
  4. Wait 4 days. Retry. On failure, create an office call task.
  5. Wait 7 days. Retry a final time. On failure, set plan_status to Lapsed, apply plan-lapsed, remove plan-active, set lapse_reason to Payment, and notify the owner. Pause any unbooked visit obligations rather than deleting them - if the customer resolves it, the entitlement should return intact.
  6. Send a plain closing message stating the plan has paused, what that means for priority response and visits, and how to restart. Never a punitive tone; most of these are expired cards, not decisions.
  7. On successful payment at any point: set plan_status back to Active, clear the tags, reset payment_failed_count, restore visit obligations, and send a one-line confirmation.

Trigger B - card_expiry is 30 days away. Apply card-expiring and send one email with the update link. Wait 14 days; if unchanged, send one SMS. Preventing the failure costs one message; recovering from it costs five.

Exit: payment resolved, or plan lapsed and owner notified.

7. Renewal Sequence

Trigger: 60 days before plan_renewal_date.

Conditions: exit if plan_status is Lapsed or Canceled. Branch the whole sequence on whether visits_delivered_this_term equals visits_entitled_per_year - you cannot ask for a renewal the same way when you under-delivered.

  1. Apply renewal-window.
  2. Full delivery branch - day 60: send the value-recap email. Lead with the record: both visit dates, what was checked each time, findings, and anything flagged. Then the renewal terms and date. The recap is the argument; nothing else needs to be.
  3. Under-delivery branch - day 60: do not send an automated renewal at all. Create a task for the owner to call, with the delivery record attached. Asking someone to renew a plan you only half-delivered, by email, is how a business loses a customer and earns a review about it.
  4. Day 30: send SMS - "{{first_name}}, your plan renews on {{plan_renewal_date}} and carries on automatically. Nothing to do unless you want to change tier or stop - just reply and tell me." Say it plainly; a renewal that surprises someone becomes a chargeback.
  5. Day 7: send email restating the renewal date, the amount due per the agreement, and the cancellation method. This notice is a courtesy and in several jurisdictions a requirement.
  6. On renewal processing: set renewal_decision to Renewed, roll plan_renewal_date forward one year, reset visits_delivered_this_term to 0, create the new term's visit obligations, and send a receipt with the agreement restated.
  7. On an upgrade or downgrade request: set renewal_decision accordingly, hand to a human to adjust billing, and recreate visit obligations to match the new tier's entitlement.
  8. On a cancellation request: stop all automation on this contact, set renewal_decision to Declined, create an urgent task for the owner, and reply - "Understood, {{first_name}}. {{owner_first_name}} will call you today to sort it out properly." BO never processes the cancellation itself.

Exit: renewed, changed, or handed to a human.

8. Lapsed Win-Back and Priority Response

Trigger A: plan-lapsed applied.

  1. Wait 30 days. Exit if the plan was restarted or the contact carries sms-opted-out.
  2. Send email - "{{first_name}}, your plan lapsed in {{month}}. Your service history and equipment records are still here. If you want to pick it back up, it takes one click: {{restart_link}}."
  3. Wait 60 days. Send one message timed to the next season window opening - that is when the absence is actually felt.
  4. Wait 90 days. Send a final message and then apply a permanent suppression for this sequence. Three attempts across six months, then stop.
  5. Where lapse_reason is Moved house, exit entirely - re-offer to the new address only if the customer initiates it.

Trigger B - priority response: an emergency request arrives from a contact with priority_response set and plan_status Active.

  1. Flag the request as priority in the dispatcher's queue ahead of non-plan requests of the same urgency.
  2. Send SMS - "We have you, {{first_name}} - your plan puts you at the front of the queue and {{technician_first_name}} is being assigned now."
  3. Where the dispatch build is live, open the Emergency Overflow slot for plan holders before offering it to anyone else.
  4. Record every instance. Priority response is the benefit customers actually renew for, and the business should be able to show how often it was honoured.

Exit: request dispatched, or win-back sequence complete.

05

What changes

The plan stops being a promise and becomes a product. Every entitled visit exists as a record from the day of enrollment, so the question "have we delivered what we sold?" has an answer rather than a shrug. The season booking conversation starts when it should - weeks before the weather turns - and it starts without anyone in the office having to remember during the busiest month of the year.

The calendar flattens. Because season calendars open the quiet weeks first and stay closed during peak emergency periods, maintenance work fills the troughs it was always supposed to fill. That changes the economics of the whole business: technicians stay busy in the shoulder weeks, and peak capacity stays available for the work that pays most.

Revenue stops leaking quietly. Expiring cards get caught before they fail, failures get a calm factual sequence rather than silence, and lapses get a reason attached. Renewals lead with a delivery record rather than an invoice, and under-delivered plans are routed to a human instead of being asked to renew by email - which is the difference between a renewal conversation and a complaint.

And the equipment record becomes an asset. Two visits a year, each updating make, model, age and condition, produces the most valuable list a home services business can own: properties with equipment approaching end of life, flagged by a technician who was standing in front of it. That list is handed to a person, not to a campaign.

Metrics to watch

  • Visits entitled versus visits delivered per term, by season and tier. This is the headline number and the one most businesses have never seen. Treat any gap as an operational defect.
  • Season miss count - opportunities reaching Season Missed. The target is zero, and every instance should have a named cause.
  • Days from season window opening to booking. Falling numbers mean the offer timing and copy are working.
  • Share of maintenance visits booked into shoulder weeks versus the last two weeks of the window. This measures whether the build is actually flattening the calendar or just relocating the rush.
  • Plan enrollment rate at job completion, by job_type. Replacement jobs should convert far better than service calls; if they do not, the offer is landing at the wrong moment.
  • Active plan count and net change per month - enrollments minus lapses and cancellations. The direction matters more than the level.
  • Renewal rate, segmented by whether the term was fully delivered. The gap between those two rates is the business case for everything in workflow 5.
  • Payment failure rate, recovery rate, and days to recovery. Also the share of failures prevented by the card-expiry prompt, which is usually the cheapest win available.
  • Lapse reason distribution. Payment-heavy is a dunning problem; Price-heavy is a packaging problem; Moved-house is neither and should be excluded from win-back.
  • Replacement candidates flagged, and conversion from flagged to quoted to won. This is where the plan pays for itself several times over, and it is measurable end to end.
  • Priority response instances honoured, with response time compared against non-plan customers. If the difference is not real, stop selling it.
06

Before you start

Prerequisites

  • A written plan agreement. What each tier includes, how many visits, what is explicitly excluded, the billing terms, the renewal mechanism, the cancellation method and notice period. This document must exist before anything is built, because half the automation references it and the other half depends on it being honest.
  • Defined season windows with start and end dates, set from the business's real demand curve rather than the calendar. Getting these wrong defeats the purpose - the point is to fill quiet weeks, so look at last year's job data and find them.
  • A maintenance checklist per service type, specific enough that two different technicians produce comparable reports. Vague checklists produce vague visit reports, and vague visit reports do not justify a renewal.
  • Honest visit durations and an agreed daily maintenance cap per technician. Maintenance that destroys emergency capacity costs more than it earns.
  • A decision on what priority response actually means - a response-time commitment, queue position, or after-hours access - and confirmation that dispatch can honor it. Selling a benefit the operation cannot deliver is the fastest way to lose a plan holder.
  • An owner-level policy for missed seasons: credit, goodwill visit, or extension. Decide before the first one happens.
  • Capacity planning for the first full season. A hundred plan holders means two hundred visits a year that must fit inside two windows, and that arithmetic should be done before the plan is sold.

Integrations

  • Stripe (or the business's existing processor) for recurring billing, with the subscription object as the source of truth for billing state and webhooks reporting success, failure and card updates back into plan_status. Never run recurring billing from a reminder task.
  • Hosted payment and card-update pages from the processor, so no card details ever reach the platform.
  • QuickBooks or Xero for recognizing plan revenue, which differs from job revenue because it is received before the work is performed. Talk to the accountant about this before launch; deferred revenue on maintenance agreements is a real bookkeeping question.
  • Google Calendar two-way sync on both season calendars.
  • E-signature, if the agreement needs signing rather than tick-box acceptance - confirm with counsel which is sufficient in the jurisdiction.
  • Where a field-service system already holds equipment records, integrate via Zapier or Make rather than maintaining equipment_list twice. A duplicated equipment record is worse than none, because technicians stop trusting it.

Number provisioning

  • Reuse the existing registered local business number. This build adds moderate recurring volume - two booking sequences and two reminder ladders per plan holder per year - which should be declared when registering or updating the messaging campaign.
  • Confirm brand and campaign registration for application-to-person messaging covers both the transactional traffic (booking, reminders, payment notices) and the promotional traffic (plan offers, win-back). Those are different message categories and some carriers treat them differently.
  • If the plan offer sequence will go to a large existing customer list on launch, throttle the first sends over several days. A sudden spike in outbound volume on a number with no history is the classic way to get filtered.

Compliance

  • Recurring billing law. This is the most regulated part of any build in the home services set. Automatically renewing subscriptions attract specific rules in many jurisdictions: clear disclosure of terms before enrollment, affirmative consent to the recurring charge, advance notice before each renewal, and a cancellation method at least as easy as the sign-up. The renewal notices in workflow 7 are written with that in mind, but the specifics vary by state and country.
  • Consent, separated by purpose. Enrollment consent covers plan-related transactional messaging - booking, reminders, payment notices. It does not cover promotional messaging, and the plan offer sequence in workflow 1 is promotional. Collect marketing consent separately and honor it separately.
  • Opt-out handling. STOP and its variants must apply sms-opted-out and halt every sequence. Be careful here: a plan holder who opts out of SMS still needs their season visits booked and still needs renewal notice. Route them to email and a phone-call task, and record that the preference was honoured.
  • Quiet hours. 8am-9pm in the customer's timezone, narrowed where local rules require. None of this traffic is urgent, so there is no reason to push the boundary.
  • Payment data. Card details stay with the processor. The platform stores only a reference and card_expiry. This keeps the business's payment-security obligations small and should not be compromised for convenience.
  • Claims. Describe what the plan includes. Do not state or imply savings figures, equipment-life extensions, efficiency gains or failure-rate reductions unless the business can substantiate them - those are advertising claims and they are enforceable.
  • Data retention. Equipment records, visit reports and property photos accumulate for years, which is exactly what makes them useful and exactly what makes a deletion request complicated. Set a retention policy and a documented process for handling a request without destroying records the business needs for warranty or dispute purposes.
  • None of this is legal advice, and recurring-billing rules in particular are both strict and jurisdiction-specific. Have the client's own counsel review the plan agreement, the enrollment consent language, the renewal notice wording and the cancellation process before the first customer enrolls.

Scoping the build

Effort depends on the number of tiers, how many service types each covers, the state of existing equipment records, and whether billing has to integrate with an accounting system already in use. Book a call at bookings.appbo.io to scope it against the plan the business actually wants to sell.

Field notes

Build it with us.

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