AI for plumbing companies: what an AI back office can and cannot do.

In plumbing the work does not wait politely. A supply line that let go overnight is still soaking a cabinet while the office catches up, and a nine o'clock water-heater replacement depends on options, parts and, where one is needed, a permit that somebody should have prepared the day before. That is the test for an AI back office in this trade: when the first van rolls, are the triage card, the water-heater options and the permit packet already in front of the owner, checked against the shop's own rules?

Supervised AI assistants can prepare all three. They start from what has already been captured, such as an answering-service note, a web form or a technician's notes and photos, and turn it into structured work a person can review. They do not take the call, they do not tell a customer where the stop valve is, they do not set a price and they do not decide whether a job needs a permit. Those stay with the licensed owner. Plumbing is one of the trades in Aevrion's home-service industries overview, and this page is its guide to the back office.

Write the split down, even if today it lives only in the owner's head. A workable rule looks like this. An emergency is water that will not stop or a hazard in the house: an active leak or burst pipe, no water at all, sewage backing up indoors, a leaking water heater, or any mention of a gas smell. Urgent work is a real problem that will hold for a day, such as one fixture out of action or a slow main drain. Scheduled work has a date attached: a fixture swap, a water-heater quote, a remodel rough-in.

Google's Local Services Ads help pages describe plumbing as an urgent category, because people call plumbers about time-sensitive problems such as a hot water outage (as checked on 13 October 2026). When every caller feels urgent, the classification has to be written down before an assistant applies it. The assistant matches what the customer said against the owner's written rule and flags the result. The owner, or whoever is on call, decides what is actually an emergency.

Grok Bot is an agent product, documented at docs.x.ai. A plumbing shop using it sets up named Bots, each owning one job, all working on a persistent cloud computer and leaving drafts for a person to review. Its documentation describes no telephony: no answering calls, no voicemail, no texting customers. Routines run on schedules that must be at least five minutes apart. So the phone stays with whoever answers it today, whether that is the owner, a technician, an answering service or a separate phone system.

What an assistant can do is start from what that person captured. An answering-service email, a web-form submission or the owner's voice memo turned into a note can be moved into a shared folder or channel the Bot reads; that link is a custom integration, built and tested for the services the shop actually uses. From there an intake Bot turns the note into a triage card. It does not ring the customer back. Nothing in this setup deals with a burst pipe in the night; it makes the morning faster for the person who does.

The safety words belong to the owner, not the assistant. When a caller has water coming through a ceiling, someone has to tell them where the main shut-off usually is and whether to close it. When a caller mentions a gas smell, someone has to tell them to leave and contact the gas utility. Those messages should be written once by the licensed owner, from the gas utility's and local authority's published guidance, and given by the person on the phone. In Great Britain, HSE's guidance for householders says anyone employed to work on gas appliances in domestic premises must be Gas Safe registered (as checked on 13 October 2026). An assistant may check that a captured note records the script being read. It never composes one.

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.

The triage card is the unit of work for everything that follows. The intake Bot fills it from the captured note and photos, marks what is missing and applies the owner's written classification. The fields are an Aevrion pattern, not a Grok Bot feature.

• WHAT THE CUSTOMER SAID

  The symptom in their own words, quoted from the note, so nobody downstream works from a paraphrase.

• WATER STATUS

  Still running, stopped at a fixture valve, or stopped at the main, and whether the customer found a shut-off at all.

• WHERE THE WATER IS GOING

  Ceiling, cabinet, slab, basement or outside. A leak under a slab and a leak at a trap are different jobs, and the card says which one the note suggests instead of guessing.

• GAS MENTIONED

  Yes or no. A yes moves the card straight to the owner, and nothing else is prepared until the owner has looked at it.

• FIXTURE OR APPLIANCE

  Water heater, toilet, supply line or main drain, with any make, age or model the customer gave.

• ACCESS AND PROPERTY

  Owner or tenant, who will be home, gate or lockbox notes, and the shut-off location if a previous visit recorded it.

• CLASS AND REASON

  Emergency, urgent or scheduled under the owner's written rule, with the clause it matched, so the owner can overrule it at a glance.

• MISSING

  Every question the note did not answer, so the person who calls back knows exactly what to ask.

The technician has looked at the old unit and noted its condition, the fuel, the venting, the space and anything that would have to change. The customer wants to know their choices. An estimate-prep Bot can turn those notes into a draft option sheet in the shop's good, better, best format: what each tier includes, what it replaces and what the technician flagged as needing attention.

The prices come from the owner's flat-rate book, read from wherever the book actually lives, every time. Grok Bot's documentation is explicit that a Bot's memory cannot stand in for the authoritative record, and a price remembered from last spring is exactly the error a shop cannot afford on a replacement quote. When the notes describe something the book has no line for, the draft says so and stops; it does not estimate. Reading a price book held in field-service or pricing software is a custom integration, or supervised browser use where the vendor permits it, subject to testing.

Whether to repair or replace is the plumber's call, the price is the owner's, and the customer approves before work starts. The sheet reaches the customer only when a person sends it.

Whether a replacement or remodel job needs a permit, an inspection or both is a local question, which is why an assistant should never decide what a jurisdiction requires. The owner writes down, once for each jurisdiction the shop works in, which job types need a permit, what the application asks for, how inspections are booked and what the homeowner has to do. The job-documentation Bot then builds each job's packet from that written list: permit needed or not, as the owner decided; application status; permit number once issued; inspection request drafted; homeowner access confirmed; result recorded by the person who attended.

The same idea applies under a different regulator. For work covered by the Water Supply (Water Fittings) Regulations 1999, WaterSafe's guidance explains that certain installations must be notified to the local water company before the work starts (as checked on 13 October 2026). A shop working under those regulations can add a notification line to the packet, filled from the owner's own list of notifiable work.

The packet is a checklist, not a judgment: a job that matches nothing on the owner's list goes back to the owner. Applications, signatures and anything submitted to a building department are handled by a person, and portal logins go through a human takeover of the Bot's computer, not around it.

Where a water supplier requires annual testing of backflow prevention assemblies, a shop with testers on staff inherits a recurring list: every assembly, every customer, every purveyor deadline. EPA's cross-connection fact sheet notes that these programs differ between states and municipalities, down to how often assemblies are tested and what credential a tester must hold (as checked on 13 October 2026). The list suits a scheduled routine, with test-due dates, notice drafts and a check that each tester's credential is current, and it never suits anything that records a result. Only a licensed tester records pass or fail.

The backflow testing article in this series works through that list in detail, using the San Antonio Water System's published program as a worked example.

The documentation's advice is to begin with the fewest Bots that do the job: one that owns an outcome from end to end, and specialists only once a role is stable and distinct. For most plumbing shops the first Bot is intake preparation, because every other piece of work starts from a triage card. Estimate preparation and job documentation follow once the cards are reliable.

With three or four Bots, a coordinator helps. The documentation describes a group chat in which a coordinator Bot can assign work; in a plumbing shop its morning job is to post the queue with overnight emergencies first, then booked jobs and their dependencies, then drafts waiting for the owner. In Aevrion's design the coordinator only posts and assigns, and approvals stay in each Bot's own conversation with the owner. Approving from a phone between jobs works because every signed-in device shows the same Bots and conversations, and per-Bot notifications can say when a Bot finishes or needs input.

Two cautions belong in the design from the first day. If a Bot working through the night asks for approval, the request expires after about ten minutes (Cursor's help pages say thirty) and the action never runs, so the shop's overnight work should finish as drafts, not sends. And every Bot on the shop's account works on the same cloud computer, files and browser sign-ins included; in the documentation's words, separate Bots are not a security boundary. The business bank login does not belong there.

The line does not move as the assistants improve.

• SAFETY INSTRUCTIONS

  Shut-off and gas-smell messages are written by the owner and given by a person. The assistant never composes one.

• EMERGENCY CLASSIFICATION

  The assistant applies the written rule and flags the card; the owner or the plumber on call decides.

• ARRIVAL PROMISES

  Only a person commits the shop to a time window, above all for an emergency.

• PRICE AND APPROVAL

  Prices come from the owner's book, and the customer approves before work starts.

• REPAIR OR REPLACE

  A diagnosis made by the plumber who saw the equipment.

• PERMITS AND SIGNATURES

  Whether a permit is needed, the application and every signature belong to the owner.

• GAS WORK AND TEST RESULTS

  Gas work goes to someone qualified for it, and a backflow pass or fail is recorded only by a licensed tester.

• MONEY

  Payments, refunds and warranty decisions. Grok Bot's documentation routes payment confirmations to a human takeover, and the assistant never takes a payment. 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.

The useful first step is not software. It is a week of real inquiries traced from the first note to the paid invoice: where each one waited, who had to remember it, and which should have been emergencies. That trace shows whether intake, water-heater options or permit packets are the bottleneck in a particular shop.

Aevrion Ops can help plumbing businesses through that sequence: helping the owner write down the classification rule and decide where the safety scripts sit in the process, designing the Bots and their approval boundaries, and building custom integrations to the answering service, price book and field-service software the shop already runs, where each vendor's API or terms allow it, after testing. The workflow automation readiness assessment is the place to start.

1. A plumbing back office is judged on whether the triage card, the water-heater options and the permit packet are ready before the first van rolls.
2. The phone stays with a person, an answering service or a phone system; Grok Bot's documentation describes no telephony, so assistants start from the captured note.
3. Shut-off and gas-smell messages are written by the licensed owner and given by a person, never improvised by an assistant.
4. Water-heater option drafts read the owner's flat-rate book every time; the plumber decides repair or replace and the owner sets the price.
5. Permit packets follow the owner's own jurisdiction notes; the assistant tracks status and never decides what a code requires.
6. Overnight Bot work should finish as drafts: an approval nobody answers expires after about ten minutes (Cursor's help pages say thirty), and the action never runs.