The one-van carpet cleaner: job cards ready before the truckmount leaves.

A one-van carpet cleaning company does five or six homes on a good day, and each needs the same things before the van pulls up: the address and where the van can park for the hose run, what is being cleaned, the pets and stains the customer mentioned, and an inspection template to fill in with the customer before starting. Built at six in the morning, those cards make the first home late. Not built at all, they make the inspection note the step that gets skipped, and it is the record the business most needs when a customer later complains.

This guide follows an illustrative owner through a working week. The pillar article on the one-man army explains the model; in short, one person directs a few named Bots, each with its own job, and keeps every decision. Here the Bots prepare while the owner drives, cleans and sleeps, and the owner approves from the phone between homes.

Based on the Grok Bot documentation at docs.x.ai as checked on 15 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.

Consider, as an illustration, an owner-operator with a single truckmount van in a mid-sized town, no office staff, and a customer base of repeat households and a few property managers. Inquiries come in by web form and email. Calls go to the owner's phone and are returned between jobs, because nothing in the Grok Bot documentation covers telephony; there are no calls, no voicemail and no customer texts for a Bot to handle. Under Aevrion's pattern the owner sets up four Bots. They are the owner's creations, named and described by the owner, and the roles are Aevrion's design rather than product features.

• THE DESK BOT

  Turns forms and emails into booking cards, and drafts replies and quotes from the owner's price sheet.

• THE CARDS BOT

  Owns tomorrow: each evening it builds one job card per home, in the order the owner confirmed.

• THE PAPER BOT

  Checks each day's inspection notes and invoices for missing fields before anything goes to a customer.

• THE RECALL BOT

  Keeps the due list: who agreed to a yearly or twice-yearly clean, and when that falls.

The four Bots work on one persistent cloud computer, with a workspace folder for each day's cards. That sharing makes handoffs easy and sets a limit: a booking-system login saved there is open to every Bot, since separate Bots are not a security boundary. Logins, two-factor codes and payments are handed back to the owner to complete. Cursor's help pages add a Vault, where saved logins and cards let a Bot sign in and check out without seeing them, and no setting asks for approval each time a saved card is used, so this design saves no card there.

Bookings held in scheduling software reach the Bots through a custom integration or supervised browser use where the vendor permits it, subject to testing. Until one is built, the owner saves an export of the next day's bookings to the workspace each afternoon, which takes a minute and gives the Bots a dated file to work from rather than a memory.

The cards Bot owns a routine scheduled for eight each evening, in the time zone the owner set. It reads the afternoon's booking export, matches each home to its booking card and the customer's history, and writes the cards into a dated folder. Background routines run with the laptop closed, and the documented rule that scheduled runs sit at least five minutes apart is no constraint on a job that runs once a night.

Each card carries what the owner needs at the door, plus a few inspection prompts picked from what the booking says. They are reminders for the owner acting as technician, not findings. A wool rug on the list adds a note to confirm the fiber and the method on site before anything is sprayed. A customer who mentioned a stain adds a prompt to photograph it and record what they were told about it. A pet in the house adds a prompt about urine. The full template, and the invoice check that follows it, are in the companion guide.

The routine's last step is a folder of cards and nothing more. It sends nothing, books nothing and changes no booking. The owner's yes or no comes at seven the next morning, with the cards in hand.

1. 01

   Booked

   Owner

   Desk Bot, then the owner

   Advances when

   The owner confirms the quote and the arrival window

2. 02

   Card built

   Owner

   Cards Bot, overnight

   Advances when

   The card is filed with the prompts the booking suggests

3. 03

   Read before leaving

   Owner

   The owner

   Advances when

   Cards read on the phone; the order confirmed or changed

4. 04

   Inspected

   Owner

   The owner, with the customer

   Advances when

   Wear, stains and fiber recorded and acknowledged before cleaning

   Ends when

   If the customer will not acknowledge the note, the owner decides whether to go ahead

5. 05

   Invoiced

   Owner

   Paper Bot, then the owner

   Advances when

   Invoice checked for date, method and areas, then sent by the owner

6. 06

   On the recall list

   Owner

   Recall Bot

   Advances when

   Next due date recorded at the interval the customer agreed

The owner keeps all four Bots in one group chat named Tomorrow. In the documentation's own example of a group, one Bot is a coordinator that can assign work; here the cards Bot plays that part, posting a short note when the cards are ready and asking the paper Bot to open a file for each job. The documentation does not describe a Bot that supervises and decides for the others, and the cards Bot does no such thing. Bots can also send each other direct, asynchronous messages, with the handoff visible in the conversation. Cursor's help pages say no switch turns off messaging between Bots; a Bot follows instructions about it.

The group is the wrong place for anything that needs the owner. The documentation keeps approval cards, login and secret requests, and email drafts out of group chats, so the desk Bot shows a quote for sign-off in its own one-to-one conversation. Handoffs posted to a group are text-only for now, so when a customer emails a photo of a stain, the owner attaches it in the desk Bot's conversation and the desk Bot sends it straight to the cards Bot, which adds it to that home's card.

At seven the owner reads the cards on the phone, moves one home to the end of the day because the customer asked to be last, and the van leaves with every card and every prompt already in the folder.

Late in the morning an email asks for a sofa, two armchairs and a hall runner to be cleaned the following week. A custom integration, tested and within the email provider's terms, copies inquiries from the company inbox into a workspace folder, and the desk Bot reads that folder on an hourly routine; at its next run it drafts a booking card and a quote from the price sheet and leaves both in its conversation. The owner opens them on the phone at the next stop, parked outside the fourth home. The phone app reaches the same Bots, conversations and routines as the desktop, and an email draft there offers Send or Discard. The owner edits the upholstery line, because nobody has yet read the care labels, adds a sentence saying fiber and method are confirmed on arrival, and sends it.

Where the desk Bot needs a yes before acting, the approval card offers Allow once, Always allow and Deny (the documentation says these controls match on iPhone), and a request raised in a chat the owner is in waits for the answer. Approving does not undo anything already done, so the owner reads the card's target and values before answering. Nothing in this design asks the owner to read the phone while driving: the cards are written to be read before the van moves.

At the end of each job the owner photographs the inspection note the customer acknowledged, adds the post-clean comments, which marks did not release and what the customer was told, and attaches them to the paper Bot's conversation. The paper Bot compares the invoice draft with the note: is the date there, is the method written out in words, are the rooms and items listed, does the note say which stains were there before cleaning. Anything missing comes back as a short question, the owner answers it, and then the owner sends the invoice.

The paper Bot does not decide whether a stain was pre-existing, and it does not tell a customer what their carpet warranty asks for. Manufacturers word those conditions differently; the companion guide sets three of them side by side.

The recall Bot's routine runs once a month and reads the customer export, not its own memory, since the documentation tells users to keep changing facts in the source system rather than in what a Bot remembers. It lists households whose agreed interval falls in the next four weeks, groups them by area so that a recall day can fill one part of town, and drafts a short reminder for each. The owner sends them from the recall Bot's conversation, a few at a time, at stops during the week.

No alert arrives if a monthly run fails, so on the first Monday the owner looks at the routine's run history; the phone app shows run history and can pause a routine, while editing or testing one needs the desktop. A household that asked not to be contacted, or whose interval was a guess rather than an agreement, is left off the list.

On Saturday morning the van is restocked and the hoses are checked, and the owner spends a few minutes in the week's folder. The questions are practical: did any home get cleaned without an acknowledged inspection note, did any invoice go out without a method, and did any card miss something the owner found on site, such as a dog the booking never mentioned. Each answer becomes an edit to the booking form or the card template, made by the owner, so that next week's cards are better at the door.

For an owner in this position the next step is the workflow automation readiness assessment, scored on this week's own routine. It has no charge and nothing to sign up for, scores a single workflow on twelve fixed dimensions, and returns one of four results with the blockers it found. Score next-day job card preparation; if tomorrow's bookings live in a paper diary or in notes on a phone, data availability is where it will score lowest. After that, Aevrion Ops can scope the four Bots, the card template and the export or custom integration from your booking software, which depends on what the vendor permits and on testing.

1. In a one-van company the evening decides the next day: cards built overnight keep the inspection note from being the step that gets skipped.
2. Four Bots, each created by the owner under Aevrion's pattern, prepare booking cards, job cards, invoice checks and the recall list.
3. A nightly routine builds the next day's cards from a booking export and stops; it sends nothing and books nothing.
4. Quotes are approved from the phone while parked, in the drafting Bot's own conversation, never in the group chat.
5. Photos travel from Bot to Bot, because handoffs posted to a group are text-only for now.
6. Calls stay with the owner, because the Grok Bot documentation describes no telephony.