Reliable AI workflows for home-service companies, inquiry to job.

A home-service job moves through roughly eleven stages: inquiry, intake, triage, qualification, scheduling, dispatch preparation, field documentation, job quality review, billing follow-up, customer retention and reporting. At every stage an AI assistant can prepare something — a summary, a draft, a checklist, a reminder — and at most stages a person still makes the decision that matters.

For each stage this guide sets out what the assistant prepares, what a person decides, where the authoritative information lives, the failure to design against, and how the stage connects to the business's software: through a capability Grok Bot's documentation describes, through an Aevrion design pattern, or through a custom integration that has to be built. That last distinction decides cost and risk more than anything else.

Every step in a workflow touches some system: an inbox, a calendar, a field-service platform, an accounting package. How an AI assistant reaches that system determines how reliable the step can be.

• DOCUMENTED CAPABILITY

  Something Grok Bot's documentation describes: named Bots, shared skills, scheduled routines, event triggers such as Slack messages, email to a Bot's own address and webhook calls, Bot-to-Bot handoffs, group chats, draft messages a person sends, approval gates, browser use of permitted websites.

• AEVRION PATTERN

  A way of combining documented capabilities that Aevrion recommends — a coordinator role, a review queue, a work-packet format. It needs design and testing, not new software.

• CUSTOM INTEGRATION

  A connection to software the documentation does not name — field-service platforms, CRMs, accounting, telephony, review sites. It is built against the vendor's API (for a Team Bot, through a custom MCP server) or done through supervised browser use where the vendor permits it, and it has to be maintained when the vendor changes.

Inquiry is the moment a request arrives — a web form, an email, a message on a marketplace site, a voicemail transcribed by a phone system. Intake turns it into a structured record: who, where, what service, how urgent, what they have already told you. Triage decides what happens next: an emergency, a normal booking, a quote visit, a referral elsewhere, or no response.

An assistant can read written inquiries it has access to, extract the details into a job summary, flag missing information, and draft a reply in the company's approved tone. It cannot answer the phone — the documentation describes no telephony — and it wakes only when something starts it: a schedule no tighter than five minutes, or an event trigger. docs.x.ai names Slack messages and GitHub notifications, and Cursor's help pages add email sent to the Bot's own address and webhook calls, so a web form reaches a Bot quickly only if its system is built to call a routine's webhook. A business that needs immediate response to emergencies needs a person or an answering service in that path, with the assistant preparing the record afterwards.

The failure to design against is the silent drop: an inquiry that was read, filed and never answered. Every inquiry the assistant cannot classify goes to the exception queue, and someone counts the unanswered inquiries every day.

Qualification asks whether this is work the business does, in its area, at a scale it wants, for a customer it can serve. An assistant can check the request against a written service list and area, look for previous jobs at the same address, and lay out the facts. Declining a customer, quoting a call-out fee or promising a time window are decisions for a person.

Scheduling is where an assistant's convenience and a business's reliability most easily collide. A calendar or field-service platform is the source of truth for availability, and it changes by the minute. An assistant can propose a slot from current availability and the technician skills the job needs, and draft the confirmation; a person confirms the booking. A double-booked technician is a worse outcome than a slightly slower reply.

Dispatch preparation assembles the job packet: address and access notes, the customer's description and photos, equipment details, previous visits, parts that may be needed. This is preparation in its purest form and one of the safest places to start. Grok Bot can accept photos, documents and spreadsheets and produce reviewable outputs; a shared workspace lets one Bot read what another saved.

Field documentation runs the other way. Technicians capture notes and photos in a hurry; an assistant can turn them into a clean job record, check it against the required fields, and ask for what is missing while the technician is still nearby. What it must never do is complete the record on the technician's behalf: diagnoses, measurements, safety observations and any compliance sign-off belong to the licensed person who did the work.

A job quality review compares the completed record with the procedure for that job type: required photos present, materials recorded, the customer's sign-off captured, follow-up work noted. An assistant can run that checklist on every job and return the ones that fail, which is something few small offices have time to do by hand.

Billing follow-up is frequent, rule-based and easy to measure, which makes it a strong early candidate. An assistant can list unpaid invoices by age from the accounting system and draft reminders in an agreed tone and sequence. A person sends them, agrees any payment plan, handles disputes and decides on write-offs. Payments are never taken by the assistant: the documentation routes payment confirmations to a human takeover. Cursor's help pages add that a card saved in the Bot's Vault can be used at checkout without asking each time, so this design saves no card there.

Retention covers review requests, maintenance reminders, seasonal check-ups and follow-up on quotes that did not convert. Each is a scheduled, repeatable task — exactly what routines are for. An assistant can prepare the list and the drafts on a schedule; a person approves what is sent, because every message to a customer carries the company's name.

Reporting closes the loop. A weekly summary assembled from the systems of record — inquiries received and answered, quotes outstanding, jobs completed, invoices overdue, exceptions raised — gives the owner the picture they otherwise build late at night. The point is not the number of tasks completed; it is the exceptions, and whether the same ones keep coming back.

The table summarizes the lifecycle. The connection column is the planning tool: documented capabilities can be configured, Aevrion patterns can be designed, and custom integrations have to be scoped, built and maintained.

Six trade guides in this series each follow one job type through the same lifecycle, and each is a prepare-and-check design. The backflow testing article runs a plumbing shop's annual test-due list while only a licensed tester records results. The HVAC replacement paperwork pack dates every document in a replacement job file. The EV charger and panel upgrade article tracks permit, inspection and certificate around the electrician's capacity verdict. The storm-claim documentation article keeps a roofer's claim files complete without crossing into public adjusting. The garage door safety-check records article prepares a per-job safety record that the technician signs. The drying-log article runs a morning check that finds a missing reading while it can still be taken.

These rules apply whatever tools a business uses. Several appear almost word for word in Grok Bot's own guidance on routine design.

• READ FROM THE SOURCE

  Prices, availability, balances and job status come from the system of record every time; an assistant's memory is not authoritative.

• PREPARE BEFORE YOU EXECUTE

  Start every stage in prepare-only mode and add actions only once the preparation has been right for weeks.

• PLAN FOR MISSING DATA

  Each stage states what it does when an input is missing or stale — usually stop and return the item.

• MAKE REPEATS HARMLESS

  Design steps so that running one twice does no damage; never let a retry send a second message or create a second job.

• REPORT PARTIAL WORK

  If a stage completes half its work, it says so in a known place rather than reporting success.

• RE-TEST AFTER CHANGES

  When a website, connector or form changes, the stages that depend on it are tested again before they run unattended.

• KEEP THE EVIDENCE

  For consequential work, ask for a report that separates facts from source systems, assumptions, completed actions, actions awaiting approval and unresolved questions, and keeps source links, screenshots, timestamps and an action log. The documentation advises this; it is guidance to follow, not something the product does by itself, and a screenshot alone is weak evidence for data that changes fast.

Grok Bot's documentation describes no automatic retry of a failed routine run and no automatic failure alert to the owner. A failed run is visible in the routine's run history, which keeps only the twenty most recent records, and a run that never started is noticed only when a person looks. That is why the reliability rules above are the owner's work, not the product's.

When a routine did not run, the documentation's troubleshooting order is to check that the routine is enabled, that its schedule and time zone are right, that the owning Bot still exists, that plugins are still authenticated, that the computer can reach the source, and that usage or access is not paused, and then to inspect the run history. Every one of those checks is done by a person.

Long absences need their own plan. To control unattended usage, Grok Bot may ask after a long absence whether to keep routines running, and pauses them if nobody answers. The documentation does not say how long counts as long, so paused routines are the first thing to review after a holiday or a slow season.

Most missed runs are prevented at creation. The documentation says to confirm these with the owning Bot when a routine is created, and the Bot then shows the next run:

• OWNING BOT

  Which Bot runs it, so there is one owner per routine.

• SCHEDULE AND TIME ZONE

  When it runs, at least five minutes apart, in the time zone the business works in.

• INPUT SOURCE

  Where it reads from: the system of record, not a copy or the Bot's memory.

• EXPECTED RESULT

  What a finished run leaves behind: a draft, a list or a report in a known place.

• APPROVAL BOUNDARY

  Which of its actions stop for a person's approval.

• WHEN A SOURCE IS MISSING

  What it does when an input cannot be read: report the failure, as the documentation's own example does, rather than work from old data.

Dispatch preparation, billing follow-up and retention reminders are usually the best first stages: frequent, rule-based, low-risk in prepare-only mode and easy to check. Scheduling and anything that touches pricing come later, once the integrations exist and the procedures are proven.

Aevrion Ops can work with a home-service business on this sequence — mapping the lifecycle, choosing the first stages, writing the procedures and approval rules, and building the custom integrations the business's software needs, where each vendor's API or terms allow it, after testing. A short operations assessment is the place to start.

Based on the Grok Bot documentation at docs.x.ai as checked on 13 October 2026. Its statements on Bot rules, Bot-to-Bot messaging, routine triggers, connected apps, approval expiry and payments were rechecked against docs.x.ai and Cursor's help pages on 26 October 2026. The trade examples are Aevrion's illustrations, not documented Grok Bot use cases. Aevrion Ops is an independent consultancy. It is not affiliated with, endorsed by or a partner of xAI, SpaceXSI or Cursor. Grok Bot is named here only to describe it.

1. A home-service job has about eleven stages; an AI assistant can prepare at almost all of them, and a person still decides at most of them.
2. Classify every connection as a documented capability, an Aevrion pattern or a custom integration — it decides cost and risk.
3. No telephony and no trigger for a phone call: emergencies and phone inquiries need a person or an answering service in the path.
4. Technicians certify their own work; assistants tidy and check records but never complete them.
5. Billing follow-up, dispatch preparation and retention reminders are strong first stages.
6. Read facts from the system of record, prepare before executing, plan for missing data and make retries harmless.
7. Nothing retries or alerts on its own: confirm each routine's setup when it is created, check missed runs in the documented order, and review routines paused after a long absence.