Running a plumbing business without an office manager.

Running a plumbing business by yourself means being the plumber, the dispatcher, the estimator and the person who chases invoices, usually in that order. Supervised AI assistants can take a share of the desk work, and a Monday after an overnight burst supply line shows exactly where that share ends. Some desks can work while the owner sleeps: building the intake card, drafting invoice reminders, preparing the day's paperwork. Others cannot move until the licensed owner is awake: the shut-off script, anything that might involve gas, and every promise about when a van will arrive.

This article follows one illustrative Monday in a two-van shop. It is a design sketch, not an account of a real business or a measured result.

In this illustration the owner is the licensed plumber and there is one other technician. After-hours calls go to an answering service, which reads the owner's scripts to callers and emails a note for each call. Nobody works in the office, so the owner's evenings go on quotes, permits and invoices.

Under the One-Man Army model the owner keeps every decision and hands each kind of desk work to its own named AI assistant. The pillar article explains the model in full. This shop runs four Bots: Intake, Job Docs, Billing, and a Coordinator that posts the morning queue.

The Bots are built on Grok Bot. All four run on the one cloud computer the account provides. One Bot can ask another for something or pass it a task outright, and because the Bots and their conversations sync to every device the owner signs in on, drafts and approval requests can be reviewed from the van.

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.

Late on Sunday a homeowner calls the answering service. The braided supply line under the kitchen sink has split, there is water on the cabinet floor, and they have closed the main because the operator read them the owner's shut-off script. The answering service emails its note, and a custom integration copies it into the shop's shared folder. An overnight routine on the Intake Bot, scheduled every fifteen minutes, which is comfortably above the documented five-minute minimum, reads the folder and builds a triage card: water stopped at the main, kitchen cabinet and possibly the ceiling below, no gas mentioned, photos requested, classed as an emergency under the owner's written rule.

What the Intake Bot does not do matters as much. It does not call or text the homeowner, because Grok Bot's documentation describes no telephony, and it does not decide that the job can wait for morning. Whether anyone went out overnight was settled by the owner's arrangement with the answering service, not by software. The card simply waits at the top of the queue for a person.

If the shop's approval rules stop customer messages for approval, as Aevrion recommends, a confirmation raised overnight would have expired after about ten minutes (Cursor's help pages say thirty) with nobody there to answer it, and the message would not have gone. That is the documented behavior for approvals raised by unattended work, and the shop's rule is written to match it: overnight, drafts wait and nothing sends.

A morning routine on the Coordinator assembles the queue and posts it to the shop's group chat, where the four Bots work together. A group chat can hold between two and six Bots, and the documentation lets a coordinator in it assign work. The order is the owner's, given to the Coordinator in chat as a lasting rule to remember: overnight emergencies first, then booked jobs with an outside dependency, then drafts waiting for approval, then money, then anything the Bots could not classify.

The last line earns its place. 'A smell' could be a dry trap or a gas leak, and the Intake Bot's rule is that anything which might be gas goes to the owner with nothing prepared.

Monday's queue, as the owner reads it before loading the van (illustrative):

• 1. EMERGENCY: KITCHEN SUPPLY LINE

  Water off at the main since late last night. Card complete apart from photos. Needs a person to call the homeowner, set the arrival window and decide which van goes.

• 2. 10:00: WATER-HEATER PERMIT INSPECTION

  Booked last week, after Thursday's replacement. The homeowner must be home to let the inspector in. Access confirmation drafted, not sent.

• 3. 11:30: BOOKED REPAIR

  Slow main drain at a rental, tenant access confirmed on Friday. No change unless the emergency moves it.

• 4. DRAFTS WAITING

  Two invoice reminders and Friday's water-heater option sheet.

• 5. THIS WEEK'S BACKFLOW TESTS

  Assemblies due before the water supplier's deadline and customer notices drafted. EPA's cross-connection fact sheet counts test dates and results among the records a backflow program should keep, so those fields stay blank until the licensed tester fills them.

• 6. COULD NOT CLASSIFY

  A web-form inquiry that mentions a smell but not what kind.

Laid side by side, the split is consistent. Everything that reads, sorts and drafts could move before dawn. Everything that commits the shop, promises a time or touches safety waited.

Emergencies take the attention; booked dependencies fail quietly. The water-heater inspection depends on three things the shop does not control: the inspector's slot, the homeowner being at home, and a van being available if the inspector asks for a correction. If the emergency swallows the morning and nobody confirms access, a missed inspection becomes a return visit and a late close-out.

The Job Docs Bot cannot prevent that, but it makes sure the owner sees it. Its access confirmation to the homeowner sits as an editable email draft, and the owner checks the time and chooses Send. Neither email drafts nor approval requests show up inside a group chat, so the queue line only points to the draft; the decision happens in the Job Docs Bot's own conversation. The Bot does not contact the building department, rebook the inspector or report the result to the homeowner. Those are the owner's.

Billing is easy to neglect when the owner is also the plumber, and it suits overnight preparation. The Billing Bot reads the open invoices from the accounting system, through a custom integration or supervised browser use where the vendor permits it, subject to testing. It drafts a first reminder for the newer invoice and a firmer second one for the older, in the tone the owner approved, and the owner reviews and sends both from the drafts.

Everything after the reminder is human. If a customer disputes the work, asks for time or offers part-payment, the Bot summarizes the job record and stops. A Bot never takes a payment; the documentation routes payment confirmations to a human takeover of the computer. 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.

One caution belongs here. The four Bots work on one cloud computer, browser sign-ins and all, and separate Bots are not a security boundary. An accounting login saved there is open to Intake and the Coordinator as much as to Billing. Where the owner wants that separation, the documentation's answer is a separate user account, not a separate Bot.

At the kitchen the plumber replaces the supply line and checks the shut-off, and can see whether water has reached the cabinet base, the subfloor or the ceiling below. Drying a structure is a different discipline with its own published standard. The IICRC's S500 standard for professional water damage restoration covers drying technology and project documentation, and it treats finding and correcting the water source as the property owner's responsibility, which the owner may hire a plumber or another specialist to carry out (as checked on 13 October 2026). The plumber fixes the source; the drying belongs to a restorer.

The hand-off is a decision, and it is the owner's. What the Job Docs Bot can prepare is a referral note: the timeline from the answering-service note, the photos the technician sends it directly (group handoffs are text-only, so images go Bot to Bot), where the water went, when the main was closed and what the plumber did. If the homeowner agrees, the owner sends it to the restoration company the shop works with. The water damage restoration article in this series covers the other side of that note.

A burst-pipe Monday tests the rules more than the Bots. In this illustration the owner made four changes before the next weekend.

• THE SMELL RULE

  Any inquiry that mentions a smell without saying what kind now goes straight to the owner, exactly like a gas mention. The rule sits in the Intake Bot's memory as a lasting rule, which is guidance for the Bot rather than a technical control, so the owner still reads the exception line every morning.

• PHOTOS DIRECT

  The technician now sends job photos straight to the Job Docs Bot instead of mentioning them in the group, because group handoffs carry text only.

• A NOON QUEUE

  A second Coordinator routine posts a short midday queue, so drafts raised in the morning are not left until evening.

• A RUN LOG ON FRIDAY

  The app keeps only the 20 most recent run records per routine, about five hours of the fifteen-minute overnight routine. So that routine also appends one line per run to a log in the shared folder, and the owner reads the log every Friday.

The order matters: the classification rule and the safety scripts first, then the intake card, then the morning queue, then billing drafts. Each runs in prepare-only mode until the owner trusts it, and the roster grows only when a desk is stable.

Aevrion Ops can help owner-operators map their own Monday, decide which desks can prepare overnight, and build the integrations to the answering service and accounting software they already use, where those vendors' APIs or terms allow it and after testing. The workflow automation readiness assessment is the place to start.

1. Overnight, assistants can read, sort and draft: the intake card, invoice reminders and the day's paperwork.
2. The shut-off script, anything that might be gas and every arrival promise wait for the licensed owner.
3. An approval requested while the owner sleeps expires after about ten minutes (Cursor's help pages say thirty) and its action does not run, so the overnight rule is simple: drafts wait for the morning.
4. A coordinator posts one morning queue with overnight emergencies first; approvals and email drafts stay in each Bot's own conversation.
5. Booked dependencies such as a permit inspection fail quietly on an emergency morning, so the queue puts them second.
6. Dry-out is a hand-off to a restoration company, decided by the owner and prepared as a referral note.