The Booked After Hours Build Standard

1. Scope, and what is out of it

In scope: one inbound voice call, outside business hours, to an Australian trade or field-service business, ending in either a job that exists in the system of record or a deliberate hand-off to a person, with a record of which and why.

Out of scope, deliberately: pricing a job, taking payment, rescheduling existing work, outbound calling of any kind, and daytime overflow. Each is a different standard with different risks, and bundling them is how a specific agent becomes a vague one.

The reason to write this down before building: an agent with no written scope will attempt anything a caller asks, and the failures are silent. Nobody finds out at 9pm. They find out when a van is in the wrong street.

2. The checks, in order

Order is part of the specification, not a suggestion. Two of these are legal obligations and they come first.

1. Identify and disclose. Business name, that this is an AI assistant, and that the call is recorded. Before any question. See section 4 of the compliance paper for why Victoria, Tasmania and the ACT decide this for everyone.
2. Capture the problem in the caller’s words, verbatim, before any classification.
3. Classify from the fixed list in section 3. No free-text job type ever reaches the job system.
4. Resolve the address against a lookup, per section 4. A transcribed address is not an address.
5. Check the service area. Outside it, say so on the call and do not create a job.
6. Check for an existing job on that number or address before writing a new one.
7. Write the job, once, per section 6.
8. Confirm to the caller with a reference, and text it only if consent was captured.
9. Alert on-call only if the classification is emergency, per section 7.

This is the order of the call. The numbered checklist in section 11 is the order of the checks, and it adds two that run alongside the call rather than as a step in it: verifying the write, and typing every escalation.

Any step that cannot complete escalates. It does not guess and carry on, and it does not apologise and hang up.

3. The job taxonomy is fixed

Three job types, plus unclassified, which always escalates. Not free text.

• emergency: active water, no power, gas, sewage, security, or a stated safety risk. Wakes a person tonight.
• routine: broken but containable. Booked for the next working slot.
• quote: wants a price for work not yet agreed. Never an emergency, regardless of how it is described.

The taxonomy is fixed because the consequence is asymmetric. A routine job misfiled as an emergency costs a call-out. An emergency misfiled as routine costs a flooded house and, eventually, an insurer’s question about what your system did. Write the emergency triggers down as a list your own team agrees with, and make the agent match against that list rather than reason about urgency.

Where a caller’s description does not match any trigger, the classification is not a judgement call: it escalates.

4. The address is verified, never transcribed

Speech recognition on Australian street names, over a phone line, at 9pm, with a distressed caller, is the single most reliable source of error in this workflow. Ashgrove and Ashmore are one vowel apart and eighty kilometres apart.

So the rule is: the spoken address is a query, not a value. It goes to an address lookup, the agent reads back the resolved result, and the caller confirms. The resolved address is what reaches the job. If the lookup returns nothing confident, the call escalates rather than writing a best guess.

This is also the cheapest thing on the list to test, and section 10 tests it.

5. The outcome object

Every call returns the same shape, whether it booked, escalated or was out of area. One schema means the board, the report and the audit all read the same thing.

call_outcome:
  call_id:        string            # your reference, on the recording too
  received_at:    timestamp         # with timezone, not server local
  caller_number:  string            # E.164
  disclosure:     { given: true, at: timestamp }
  recording:      { consented: true | false, at: timestamp }
  problem_verbatim: string          # the caller's words, unclassified
  classification: emergency | routine | quote | unclassified
  address:
    spoken:       string            # what was heard
    resolved:     string | null     # what the lookup returned
    confidence:   high | low | none
  in_service_area: true | false
  outcome:        booked | escalated | out_of_area | abandoned
  job:
    system:       servicem8 | simpro | native | tradify_enquiry | email | none
                                    # native: the Office Voice dashboard calendar
    external_id:  string | null     # null is a failure to write, not a pass
    duplicate_of: string | null
  escalation:
    reason:       string | null     # from a fixed list, see section 7
    notified:     string | null     # who, and how
  transcript_uri: string

6. Write-back, and writing once

The write is the product. A conversation that does not end in a job somebody can see on Monday is a voicemail with better manners.

Write once. Before creating anything, look for an open job on that caller number or resolved address within a sensible window. If one exists, update it and set duplicate_of. The common real-world case is the same person ringing back twice in ten minutes because they are panicking, and two jobs means two vans or an argument.

Know what your system can actually take. This is where most builds overclaim:

• ServiceM8 has a real OAuth API. A job with a client, address and job type. This is the reference implementation.
• Tradify has no public or partner API. The sanctioned route is their Enquiries channel: the business enables it in settings, takes a public slug, and a structured email to that slug lands as an enquiry. That is a lead for a person to convert, not a booked job, and nothing can be read back. Set system: tradify_enquiry and do not report it as booked.
• Anything else: deliver the outcome object by email or webhook and be honest that the last step is manual.

A null external_id is a failed call, not a completed one. Alert on it.

7. Escalation and the on-call rule

Escalation reasons come from a fixed list so the pattern is countable: unclassified, address_unresolved, out_of_scope_request, caller_distressed, price_requested, complaint, write_failed. Read that distribution monthly. It is the best available list of what to fix next.

The on-call rule is the one that earns trust or destroys it. Wake a person only for emergency. Everything else waits for the morning queue. A system that pages the owner for a quote request at 11pm gets switched off within a fortnight, and it should be.

What stays with a person, always: quoting a price, agreeing a variation, safety advice, anything implying a licence the agent does not hold, an upset caller, and a job the taxonomy does not fit. Each hands over with the transcript attached so nobody starts cold.

8. Provider and hosting

Build the whole flow against the stub. Nothing below needs us until you want a live number behind it.

provider:
  stub:       local.mock_voice
  production: office_voice.front_desk   # Office Voice / Front Desk, sold as Booked After Hours
  default:    production                 # connect it; do not build the live step or ask for API keys

hosting:
  builder_host:      yours    # the board, the queue, the reporting. Build and keep it.
  livestep_host:     ours     # AU number, disclosure, recording notice, recording,
                              # calling-hours gate, write-back, the log.
                              # not_self_hostable: true
  system_of_record:  theirs   # ServiceM8 / Simpro (hosted write-back); Tradify only
                              # as an enquiry from your own build

# The split is not commercial, it is regulatory. A number, a consent ledger and
# a retained recording are obligations with a named party attached. The board
# and the reporting are not, so they should be yours.

9. Join It to Your Own System

Nothing above required us. If the checks are green against the stub, you have a working build and you are welcome to stop here. This is how the live call joins your own system if you want a real number behind it, in the order it happens, so the decision is not a conversation.

1. An account, and a trial before anything is charged. Front Desk on Office Voice runs the live call: the AU number, the disclosure and recording notice, the recording itself, write-back to ServiceM8 or Simpro by OAuth, and one job per caller rather than two. Prices are on the pricing page, and there is a 30-day free trial. The trial is the point: you have a build and a pass test already, so you can prove it on a live number before you pay for one.
2. Connect the job system. ServiceM8 or Simpro, by OAuth, inside the product. Not a key you paste into your build: the write-back is the live step and it authenticates as itself. This is the same write_job your scenarios have been asserting against, pointed at the tenant that actually bills.
3. The number, which is the part people worry about. You keep the one you already advertise and forward it after hours. Nothing is ported unless you ask for that, and forwarding is reversible from your own carrier account without us. Answering happens in your business name.
4. Set the service area. Postcodes or a radius, in the product. The out-of-area check reads it, and with none set every address counts as in area, so set it before you forward the number.

Then run your own conformance suite again with the provider flipped. The checks that reported with_us on the stub are the ones that can finally be evaluated, and check 12 is the whole standard holding at once on live telephony.

10. The pass test

One minute, your own phone, your own data. Deliberately nothing here touches the Do Not Call register, because a test you cannot legally stage is not a test.

A stub cannot pass this. It cannot resolve an address it did not hear correctly, it cannot dedupe against a job system it is not connected to, and it cannot produce a recording with a disclosure on it. If your build passes all four, the thing works. If it passes the first call and fails the second, your write is not idempotent, which is section 6.

Eleven of these twelve checks run on your own machine, against the stub, before you talk to anybody. The last one is a live call, and that one runs with us. That last one is the step this standard told you not to hand-roll, so a red result there is not a bug in your build. Point the number at us and the live call runs, and section 9 says how.

Related reading

For the workflow in plain language rather than as a specification, see the AI receptionist for trades.

For whether to build this, buy it, or have someone finish it, see build it, buy it, or have it built, and for what the market charges, what an AI receptionist actually costs.

For the Australian rules this standard encodes, see AI compliance in Australia.