The Next Service Build Standard

1. What this standard covers

Equipment a trade business installs or services, and the customer who owns it: hot water systems, air conditioners, solar inverters, switchboards, water filters. When a job is marked complete, the equipment on it is recorded. The next service date and, where the job recorded a term, the warranty expiry are worked out from your written schedule. A written lead time before each date, the customer gets a reminder on a channel they agreed to, and one follow-up if they do not answer. A yes becomes a booking request in your job system, once. This is the method in the warranty and maintenance reminders paper, made into something you can check.

What is out of scope. Legal obligations. Testing a building must have done by law, notices to a tenant or an owner, and breach clocks are the Compliance Calendar standard. This one is a commercial reminder to a customer about their own equipment, sent only with their consent, and what it produces is a booking request, not a notice. It does borrow one rule from the Compliance Calendar: due dates are derived, not stored. Things owed to the business, like an unsigned quote or a missing certificate, are the Follow-Up standard; this is a service the customer may want. Working a whole contact list with no particular trigger is Database Reactivation; this is one asset and one date at a time. And the Review Request standard starts from the same moment: one job marked complete starts both the review ask and the capture of the equipment, and neither waits for the other.

What cannot meet it, and what can. The booking request has to be written into the job system the business already runs. ServiceM8, Simpro, Fergus, Jobber and AroFlo each have an API a build can create a job through, so each can meet it; check your plan includes API access. Tradify cannot: it has no public API, so there is no sanctioned way to write the request back, and check 11 cannot be met live there. A Tradify business can still run the reminders and take the yes by hand. Equipment recorded only in a technician’s head cannot meet check 1 either: the job has to hold the type, the model and the date.

Is there a ready-made version? Not yet. No product takes the finished jobs, sends these reminders and writes the yes back once. So this standard is a Draft, and the build is yours, or ours as a scoped build.

2. Where the dates come from, and why nobody types one

Five things are taken from the finished job, exactly as the technician recorded them:

Then two dates are worked out, on every run. The next service is the last service date, or the install date if there has not been one, plus the months your schedule gives for that type of equipment. The warranty expiry is the install date plus the term on the record. The schedule is yours, written down once: one row per equipment type, with the months between services. Base it on the manufacturer’s instructions for what you install, or on what you advise your customers. The standard does not supply the numbers.

Nobody types a date, and no date is stored to go stale. Decide hot water systems should be serviced every six months instead of twelve, change one row, and every hot water date moves. A next-due date somebody typed onto the job is ignored. This is the rule the Compliance Calendar standard is built on, applied to a customer’s equipment rather than a legal obligation.

Anything missing goes to a person, never a guess. No install date, no model, no equipment type, or a type your schedule has no row for: the asset is listed with the gap named, and no reminder goes until somebody fixes the record. A warranty term is never assumed from the brand or from what is usual. No term on the job, no warranty reminder.

3. The reminder, the follow-up and the stop

One reminder per date, sent inside a lead time you write down (say, three weeks before the date), and never for a date already gone. Before it goes, two checks. Is there a job already open for that unit in the job system? Then the customer is sorted, and they hear nothing. Did the customer agree to SMS or email? Then it goes on that channel, and if they agreed to neither it does not go at all: it is listed for a person instead.

A service reminder names the unit and the date: “Hi Ana, your Rheem Stellar 315 is due for its service on 10 November. Reply YES and we will call to book a time, or use the booking link. Reply STOP to opt out.” A warranty reminder states the date the warranty on your record ends, and nothing else about it: “The warranty on your Fronius Primo ends on 12 November, according to our record.” It never says what the warranty covers, that a repair would be free, or anything about the customer’s rights. The manufacturer’s warranty and the consumer guarantees under the law are different things, and neither is the reminder’s to explain.

No answer after a written number of days, one follow-up. Then it stops for that date. Any reply ends the follow-ups. STOP, or any request to stop, is recorded for the customer and holds for good, on every unit they own, including one you install for them next year. A reply that is not a yes or a stop, like “can you come after 3pm?”, goes to a person to answer.

4. The records it keeps, in the shape your developer needs

Six objects. Note what the Asset does not have: a due date. Dates are worked out from the Schedule every time, so there is nothing stored to go stale.

Asset                             # one per piece of equipment
  - id, customer_id, source_job_id
  - equipment_type, make, model, serial (nullable)
  - installed_on, last_serviced_on (nullable)
  - warranty_months (nullable)      # as written on the job; never assumed
                                    # no due-date field, on purpose

ScheduleRule                      # one per equipment type, written by the business
  - equipment_type, service_months
  - changed_by, changed_on
Settings
  - lead_days, follow_up_days       # written once, not per customer

DueDate                           # derived on every run, never stored
  - asset_id, kind (service | warranty)
  - due_on = anchor + months        # anchor: last service, else install

Reminder                          # unique on (asset_id, kind, due_on, stage)
  - asset_id, customer_id, kind, due_on
  - stage (reminder | follow_up), channel (sms | email)
  - body, sent_at
  - reply_text (verbatim), outcome (none | yes | stop | unclear)

BookingRequest                    # unique on (asset_id, due_on)
  - asset_id, customer_id, reply_text
  - job_number                      # from the job system, once written
  - no time slot, no price          # a person books and prices it

OptOut                            # keyed on the customer; no field clears it
  - customer_id, said, received_at

Exception
  - asset_id or reply_id
  - kind (missing_install_date | missing_model |
          missing_equipment_type | no_schedule |
          no_consent | unclear_reply)
  - detail, raised_at, cleared_by

Two booking requests for one asset and one date is the defect this standard exists to make impossible. A stored next-due date that survives a schedule change is the other.

5. The checks, in order

The order is the claim. The record comes first, because every date is worked out from it, and a gap in it stops that asset before anything is sent. The checks on the job system and on consent sit in front of every message, and the booking request sits behind a yes.

1. The equipment is taken from the finished job, as recorded. When a job is marked complete, its equipment type, make and model, serial if any, install or service date and warranty term are recorded against the asset exactly as the job holds them. A job that is not complete records nothing, and running twice records nothing twice.
2. A missing install date, model or equipment type goes to a person. An asset without one of them, or of a type with no written schedule, is raised as an exception with the gap named. No date is guessed, no schedule is borrowed from a manufacturer the record does not name, and no reminder goes.
3. Due dates are worked out from the schedule, never typed in. The next service date is the install or last service date plus the interval the written schedule gives for that equipment type, worked out on every run. Change the schedule and the dates move. A date somebody typed onto the job is never used. The same rule as the Compliance Calendar standard.
4. The warranty expiry comes from the term on the record. Install date plus the warranty term the job recorded. No term on the record, no warranty reminder: the term is never assumed from the make, the type or what is usual.
5. One reminder, a written lead time ahead of each date. The lead time is written down, not decided per customer. A reminder goes inside that window before the date, once per date, and never for a date already past.
6. Only on a channel the customer agreed to. SMS to someone who agreed to SMS, email to someone who agreed to email. A customer with neither is an exception for a person, not a message.
7. Already booked means no reminder. Before every reminder the job system is checked for an open job on that asset. If one exists, the customer is already sorted and hears nothing.
8. One follow-up if there is no answer, then stop. A written number of days after the reminder, one follow-up, and nothing more for that date. Any reply ends the follow-ups, and a reply that is not a yes or a stop goes to a person.
9. A stop is honoured for good, on every asset. A reply of STOP, or any request to stop, is recorded as withdrawn consent for that customer. Nothing is sent to them again, about any asset, including equipment installed after they said it.
10. A warranty reminder states the expiry date and nothing about cover. It says when the warranty on the record ends. It never says what the warranty covers, that a repair would be covered, or anything about the customer's rights under the consumer guarantees.
11. A yes becomes one booking request in the job system. A reply of yes, or a tap on the booking link, writes one booking request into the job system against that customer and that asset. A second yes, or a second run, makes no second one.
12. The build never picks a time or a price. The booking request carries the customer, the asset and what they said. A person books the time and prices the work, and is told a request is waiting.
13. Every reminder, reply and booking is on the record, by asset. Each reminder and follow-up with its date and channel, each reply word for word, each stop and each booking request with its job number, kept against the asset so the history of one hot water system can be read in one place.
14. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
15. The pass test passes. In the business's own job system: change a schedule and the due dates move without anyone editing a date; a customer marked do not contact hears nothing; a YES from a real phone makes exactly one booking request, and a second YES makes no second one.

The exceptions, a closed list:

6. A yes, written back once

A reply of yes, or a tap on the booking link, becomes one booking request in your job system, against that customer and that unit, carrying what they said. Before it is written, the build looks in the job system for one already there for that unit. If there is one, nothing new is written. So a customer who says yes twice, or a run that happens twice, or a retry after the job system was slow to answer, still leaves one request.

The request carries no time and no price. The build does not know who is free on Tuesday, how long the job will take on that site, or what you charge for it, and a time or a price it made up is one you then have to honour or walk back. A person is told a request is waiting, by its job number, and books it the way you book everything else. If the customer rings instead of replying, that is an ordinary call, and the Booked After Hours standard covers answering it when nobody is at the desk.

7. What stays with a person

• ✓Booking the time and pricing the work for every booking request.
• ✓Writing the schedule: how many months between services for each kind of equipment. The build reads it and never invents a row.
• ✓Fixing a record with a missing install date, model or type. The build names the gap; a person fills it from the job, the unit's label or the customer.
• ✓Answering any reply that is not a yes or a stop.
• ✓Anything about what a warranty covers, a claim, or the customer's rights. The reminder states a date and stops there.
• ✓Taking a customer off the opt-out list, which happens only if they ask.

8. Run it on what you already use

The reminders live wherever the business already works. Three ways, all held to the same checks:

• Existing tools only. A spreadsheet of installed equipment fed from the job system’s export, or Microsoft 365 lists. The Microsoft 365 plan lays out the lists and flows, with the schedule as its own list so nobody types a date.
• A personal dashboard. Hand this page to a coding agent and it builds a small page of what is due this month, the replies and the booking requests, against the stub until the write into the job system has to be real.
• A long-lived bot. A routine that wakes when a job is marked complete and once a day after that, sends what is due, reads the replies and writes each yes back once.

How to run any standard each of these ways is in run a standard anywhere.

9. What your developer builds, and the step that needs care

One step not to hand-roll: writing each yes into the live job system as exactly one booking request, against the right customer and unit, safe to retry. No product does it today, so it is quoted as a scoped build. Everything else a coding agent builds against the stub in an afternoon.

provider:
  stub:       local.mock_service_book
  production: none                       # scoped build, not a product

the stub                             # local.mock_service_book
  - finished and open jobs, with equipment as the technician recorded it
  - a written schedule the runner can change between runs
  - customers with the channels they agreed to
  - a send that refuses a stopped customer or an unagreed channel
  - a job system that does NOT deduplicate: two writes are two jobs

the hard step: the booking request
  - no hosted product writes it. Quoted as a scoped build against
    the job system the business runs (ServiceM8, Simpro, Fergus,
    Jobber, AroFlo), and the pass test is run on that system
  - read the open jobs for the asset, claim the request, then write;
    a retry after a timeout must find the first one

stays local                          # yours, and the standard
  - capture, the schedule, the dates, the reminders, the follow-up,
    the opt-outs, the exceptions and the record

cannot meet the standard
  - Tradify: no public API, so check 11 cannot be met live there
  - a job that does not record the type, the model and the date

A vendor selling automated service reminders is usually selling the SMS. Ask them three things: what happens when you change the schedule, what the customer gets when they reply YES twice, and what their warranty message says about cover.

10. A checklist to hold any build or supplier to

Hold a DIY build or a vendor to this. If a box is empty, it is not in production.

• ✓1. The equipment is taken from the finished job, as recorded. When a job is marked complete, its equipment type, make and model, serial if any, install or service date and warranty term are recorded against the asset exactly as the job holds them. A job that is not complete records nothing, and running twice records nothing twice.
• ✓2. A missing install date, model or equipment type goes to a person. An asset without one of them, or of a type with no written schedule, is raised as an exception with the gap named. No date is guessed, no schedule is borrowed from a manufacturer the record does not name, and no reminder goes.
• ✓3. Due dates are worked out from the schedule, never typed in. The next service date is the install or last service date plus the interval the written schedule gives for that equipment type, worked out on every run. Change the schedule and the dates move. A date somebody typed onto the job is never used. The same rule as the Compliance Calendar standard.
• ✓4. The warranty expiry comes from the term on the record. Install date plus the warranty term the job recorded. No term on the record, no warranty reminder: the term is never assumed from the make, the type or what is usual.
• ✓5. One reminder, a written lead time ahead of each date. The lead time is written down, not decided per customer. A reminder goes inside that window before the date, once per date, and never for a date already past.
• ✓6. Only on a channel the customer agreed to. SMS to someone who agreed to SMS, email to someone who agreed to email. A customer with neither is an exception for a person, not a message.
• ✓7. Already booked means no reminder. Before every reminder the job system is checked for an open job on that asset. If one exists, the customer is already sorted and hears nothing.
• ✓8. One follow-up if there is no answer, then stop. A written number of days after the reminder, one follow-up, and nothing more for that date. Any reply ends the follow-ups, and a reply that is not a yes or a stop goes to a person.
• ✓9. A stop is honoured for good, on every asset. A reply of STOP, or any request to stop, is recorded as withdrawn consent for that customer. Nothing is sent to them again, about any asset, including equipment installed after they said it.
• ✓10. A warranty reminder states the expiry date and nothing about cover. It says when the warranty on the record ends. It never says what the warranty covers, that a repair would be covered, or anything about the customer's rights under the consumer guarantees.
• ✓11. A yes becomes one booking request in the job system. A reply of yes, or a tap on the booking link, writes one booking request into the job system against that customer and that asset. A second yes, or a second run, makes no second one.
• ✓12. The build never picks a time or a price. The booking request carries the customer, the asset and what they said. A person books the time and prices the work, and is told a request is waiting.
• ✓13. Every reminder, reply and booking is on the record, by asset. Each reminder and follow-up with its date and channel, each reply word for word, each stop and each booking request with its job number, kept against the asset so the history of one hot water system can be read in one place.
• ✓14. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
• ✓15. The pass test passes. In the business's own job system: change a schedule and the due dates move without anyone editing a date; a customer marked do not contact hears nothing; a YES from a real phone makes exactly one booking request, and a second YES makes no second one.

Facts that can change, and when we checked them