A cleaner is out sick: who covers the homes when the owner also cleans.

A small cleaning company runs close to full. When every cleaner has a set of homes on set days, nobody is sitting spare waiting for a sick call; cover comes out of someone else's slack, out of the owner's own day, or from moving a visit. Choosing between those, home by home, and telling the right customers before their usual cleaner fails to arrive, is the heart of managing a house cleaning business on a bad morning.

Everything about the company below is invented: the owner, her four cleaners, their homes, the times and the numbers exist only to make the design concrete, and none of it records a result or a real business. The pillar on the One-Man Army model describes the idea in full; in short, the owner sets up a handful of narrowly scoped Bots, each named for its job, and every decision that matters still comes back to her.

In the illustration the owner, Rosa, cleans on Mondays, Wednesdays and Fridays and runs the office on the other days. Each of the four cleaners holds a set of regular homes, mostly every other week, some weekly, a handful monthly. Every home has a usual cleaner and a usual day, and customers are told who is coming. The roster lives in the company's booking system. Each evening Rosa exports the next day's visits to a spreadsheet in the shared folder on her Bots' computer, the simplest starting point, which needs no integration at all.

Rosa guards one detail above the rest. Keys, lockbox combinations and door codes are kept in a password manager on her phone and in the booking system, and never in a file her Bots can read. The companion guide to running a cleaning office explains why the shared computer rules that out; here it is simply a fixed point the whole morning works around.

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.

Following Aevrion's pattern, Rosa has created two Bots. The Roster Bot owns the daily and weekly roster: who is where, for how long, and what each home's notes say about it. The Desk Bot owns customer wording: notices of changes, replies to schedule questions, and same-day flags from customer feedback. Both work on the same persistent cloud computer, so both read the same spreadsheet and the same home notes from its shared folder.

Rosa puts both Bots in a group chat. The documentation allows between two and six Bots in a group, and its Website Launch example gives one member, a coordinator, the job of handing out work; Rosa gives that job to the Roster Bot. Bots can also message each other directly, and Rosa can see each handoff. Cursor's help pages say no switch turns that messaging off; a Bot follows instructions about it. Making one Bot the coordinator is Aevrion's design rather than a product feature: the documentation's Chief of Staff produces a digest for a person, and nothing in it describes a Bot that oversees others.

The group shows the plan, but it never holds the drafts. The documentation says approval requests and email drafts do not appear in a group, so every customer notice waits in the Desk Bot's own conversation, where Rosa, as the account holder, is the only person who can send it.

On a Tuesday a cleaner, Jo, messages Rosa at ten past six to say she is ill. Jo had four homes that day. Rosa, still at the kitchen table, types one line into the Roster Bot's conversation: Jo is out today. Grok Bot does not read Rosa's texts or take her calls, so Jo's message reaches the Bot only because Rosa passes it on.

The Roster Bot reads the day's spreadsheet and the notes for Jo's four homes, then checks each against the others' days: who finishes early, who is already working in the same area, whether a home has a pet that only knows Jo, whether its customer has asked never to have a stand-in. Rosa wrote those preferences into the notes over many months. The Bot does not lean on its memory of earlier Tuesdays; the documentation says memory is no substitute for the source, so it reads the files fresh. Its proposal reads like this.

• HOME A, NINE O'CLOCK

  Sam finishes a nearby home at half past eleven. Proposal: move this visit to the afternoon, same day, with Sam, if the customer agrees.

• HOME B, ELEVEN O'CLOCK

  The notes say the customer works from home and has asked for Jo each time. Proposal: offer Thursday with Jo, or today with a stand-in.

• HOME C, ONE O'CLOCK

  Rosa is not cleaning on Tuesdays and the home is ten minutes from her. Proposal: Rosa covers it herself at the usual time.

• HOME D, THREE O'CLOCK

  A monthly visit to a customer who is out at work and has said any of the team is welcome. Proposal: Kim adds it after her last visit; access: Rosa to brief Kim.

Rosa reads the proposal at twenty past six. She knows something the files do not: Sam has to leave early that afternoon. So she moves Home A to Kim, who has room after lunch, and agrees the rest. Nothing on the roster changed until she did. When the Roster Bot then updates the day's file, any approval her own rules ask for appears in the chat she is sitting in, and an approval raised there simply waits for her answer.

The Roster Bot then messages the Desk Bot with the two homes whose customers must be told before the morning starts. The Desk Bot drafts both emails in its own conversation: for Home A, the new afternoon time and the name of the cleaner coming; for Home B, the choice between Thursday with Jo or today with a stand-in, and a request to reply either way. Neither draft says why Jo is away. A cleaner's health is not the customer's business, and Rosa's lasting rules for the Desk Bot say so, which guides the Bot without technically binding it, so she reads each draft for it anyway.

Rosa edits both drafts and chooses Send on each. Grok Bot sends no texts, so a customer who only reads texts hears from Rosa directly, in her own words. Home C needs nothing beyond Rosa at the door, and Home D's customer asked not to be bothered about who comes. At five to seven the swap is agreed, two notices are out and the roster file shows the new day.

The team hears last and simplest. The Roster Bot posts the revised day to the group; Rosa forwards the new times to Kim and Sam in the team's own chat. The way into Home D is Rosa's job as well: she reads the lockbox combination from her password manager and passes it to Kim herself. The proposal only ever said that Rosa would brief Kim, because the Roster Bot has never held the code.

A covering cleaner is working from notes, not habit, and the first sign of a missed instruction can be the customer's reply to the request for feedback after the visit. In the illustration those replies collect in the booking system's message log. The Desk Bot reads that log through supervised browser use where the vendor permits it, tested before Rosa relies on it; a custom integration, subject to the vendor's API or terms, is the other route.

A routine on the Desk Bot runs at four and again at seven in the evening; routine schedules may sit no closer than five minutes apart, so twice a day is well within what the documentation allows. It reads the day's replies, puts every covered home at the top, and flags any reply that mentions a missed room, something broken, a door or gate left open, a pet let out or a cleaner who did not arrive.

A flag is a note to Rosa, the same day, with the customer's words and the visit's details. The routine does not reply, offer a re-clean or a credit, or say anything about damage. Those are Rosa's decisions, and a damage claim is a matter for her and whoever she takes advice from. The list waits in the Desk Bot's conversation until Rosa reads it, and any reply to the customer is drafted only after she has decided what it should say. If the booking system's page will not open, the note says so rather than reporting a quiet day, and since the documentation describes no automatic retry or failure alert, Rosa glances at the run history each evening.

Sick days are the loud version of a quieter problem, which is drift. A weekly routine on the Roster Bot runs on Sunday afternoon and drafts the coming week from the booking export: each cleaner's homes by day, the hours those add up to, gaps where a cancellation left room, and every visit where the cleaner is not the home's usual one.

That last column is the one Rosa reads first. A home that has had a stand-in twice in a month is a customer at risk, whatever the feedback says. The draft also carries Rosa's own entries: days off that cleaners have asked for, her own cleaning days, a new customer's first visit. She edits it and gives the final roster to the team herself.

Hours and pay sit outside this design. The draft shows planned hours for planning only, does not feed payroll, and takes no view on how anyone is engaged. Whether a cleaner is an employee is for Rosa and a qualified adviser; the US Department of Labor, as checked on 16 October 2026, places the responsibility for that determination on the employer.

By Thursday the week is back to normal, but Tuesday leaves a trace. The Desk Bot's flags show that Home A's customer noticed nothing, and that a stand-in at another home the week before missed the shoes-off request written in its notes. The Roster Bot can list every home that has only ever seen one cleaner, sorted by how hard each would be to cover: pets, alarms, customers at home during the visit, homes that asked for no stand-ins.

What to do with that list is Rosa's judgment. In the illustration she decides that her ten most particular homes will each have a second cleaner who has visited once, on an introduction visit she schedules herself, so that the next sick day brings a face the customer already knows. The Roster Bot drafts the introduction schedule, the Desk Bot drafts the emails explaining it, and Rosa sends them. The idea is hers, not something this article prescribes for every cleaning company.

Tuesday's early morning is also the thing to measure. The workflow automation readiness assessment, free and with no sign-up, rates sick-day cover as a single workflow on twelve fixed dimensions and hands back a result immediately, with the blockers it found and a suggested next step. Expect ownership clarity to come out low if only the owner knows who can stand in where, and exception frequency to weigh against it in a team small enough that every absence is an exception. If the result points to a Roster Bot worth building, Aevrion Ops can work through the group with you: its stopping points for the owner, and whether the booking system can be reached by a custom integration under its vendor's API or terms.

1. In a small cleaning team, cover for a sick cleaner comes from someone's slack, the owner's own day or a moved visit, decided home by home.
2. A Roster Bot can propose that cover from the day's file and each home's notes, and nothing on the roster changes until the owner agrees.
3. Customer notices are email drafts in the Desk Bot's own conversation, which the owner edits and sends; the group chat never shows them.
4. A same-day feedback routine puts covered homes first and flags complaints to the owner without replying, crediting or promising anything.
5. Access details never pass through the Bots: the owner briefs the covering cleaner on the way into each home.