Gutter cleaning scheduling: recall lists, reminders and storm rebooks.

Gutter cleaning is low-ticket work that pays when visits are grouped, so the recall list has to be sorted by where customers are as well as when they are due. Built from the company's own exported customer data, grouped into neighborhood clusters the owner approves, and worked through by a weekly routine that drafts reminders, the list does most of the scheduling thinking before the season opens.

A storm adds work the list was never built for: visits it postpones and requests it brings in. Those belong in a separate rebook queue that the owner orders. This page covers cleaning only. Install quotes, and following them up, are a different list.

The source is the customer data the company already holds, exported from its scheduling or field-service software or kept in a spreadsheet. The Recalls Bot is one the owner creates in Grok Bot, which lets a user run named Bots on a persistent cloud computer. The owner can attach the export to the Recalls Bot's conversation as a spreadsheet; reading it from the software directly is a custom integration, or supervised browser use where the vendor permits it, subject to testing.

Either way, the list is rebuilt from the current export every cycle. The documentation warns that what a Bot remembers should never stand in for the source system, and last autumn's address or season preference is exactly the stale detail a recall cannot afford. The field list below is Aevrion's pattern; the product does not supply it.

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.

Grouping a few hundred addresses into clusters is tedious work that an assistant does quickly and decides badly. The Recalls Bot can propose clusters from street names, postal codes or a service-area map the owner provides, each sized to what the owner says one crew can clean in a day, and return them as a reviewable spreadsheet. The owner then corrects what the data cannot know: the estate where every house is three stories, the street the truck cannot turn in, the customer who wants the same crew every year, the cul-de-sac with the overhanging trees.

Once approved, the clusters are written back into the list and only the owner changes them. A rule such as never splitting a cluster across two weeks without asking can be given to the Bot as a lasting rule, but the documentation says boundaries should rest on approvals and Auto-review rules rather than memory alone, which is why the owner keeps checking each week's draft.

In many areas the autumn recall follows leaf drop and the spring recall clears what the winter left, but when either begins depends on what grows over a given street and on the year's weather. The owner sets each window and the order inside it: which clusters go first because of the trees over them, which can wait, and which customers asked for both seasons. The Recalls Bot applies those windows. It does not guess them.

A recall cycle suits a routine: the same preparation on the same morning each week. A routine, in the documentation's terms, assigns one Bot a workflow and a time to run it: on a schedule or, where supported, when an event occurs. Each Bot is limited to fifty routines, scheduled runs cannot be closer together than five minutes, and only the latest twenty run records per routine are kept. A weekly recall routine sits far inside those limits, and because no failure alert is documented, a Monday with no drafts is itself the signal.

Keeping the routine draft-only matters for a second reason. An approval raised before dawn, with nobody there to answer it, lapses after roughly ten minutes (Cursor's help pages say thirty) and its action never happens. A routine that ends in drafts never meets that problem. It also has one deliberate omission: it does not touch unsigned install quotes, which are a different conversation with a different customer and stay off this list.

What the owner confirms when the routine is created, following the documentation's confirm list, plus two items from its routine-design guidance:

• OWNER AND SCHEDULE

  The Recalls Bot owns it, and it runs early on Monday in the company's own time zone.

• INPUT

  The current export and the approved clusters. If either cannot be read, the routine says so and stops, rather than working from last week's copy.

• RESULT

  Next week's proposed visits by cluster, and a reminder draft for each customer in the clusters the owner has opened.

• APPROVAL BOUNDARY

  Nothing is sent. Every reminder is an editable draft in the owner's conversation with the Recalls Bot, and the owner sends it.

• REPEATS (DOCUMENTED GUIDANCE)

  The documentation asks for retries that are safe to repeat. Aevrion's way of applying it: before writing a draft the routine checks for an existing one, so a second run never leaves two reminders for the same household.

• PARTIAL RUNS (DOCUMENTED GUIDANCE)

  The documentation asks where partial completion is reported. Here, if the routine finishes only some clusters, it lists which were done and which were not.

A wind and rain storm in leaf season does two things to the schedule. It cancels ladder days the owner judges unsafe, and it brings requests from customers whose gutters overflowed. Mixed back into the recall list, those rows push recall dates around without anyone seeing it. Kept in their own queue, they can be ordered on purpose. Two rules keep the queue honest: it drains before the recall list resumes in the clusters the storm touched, and nothing leaves it without a date the owner set.

Some requests will describe damage rather than debris: a section pulled off, a crushed downspout, roofing material in the trough. Those leave the queue entirely and go to the owner, who decides whether it is repair work the company does or a referral to a roofer. This queue schedules cleanings. It is not a storm damage or insurance workflow, and roofing has its own guide for that.

1. 01

   Postponed or requested

   Owner

   Recalls Bot

   Advances when

   The owner cancels a day for weather, or a customer asks for a post-storm cleaning; the Bot adds the row to the rebook queue and flags it on the recall list

2. 02

   Sorted

   Owner

   Recalls Bot

   Advances when

   Rows are ordered by the owner's written rule, for example postponed visits before new requests

3. 03

   Ordered

   Owner

   The owner

   Advances when

   The owner moves rows for what the rule cannot see, such as an overflow spilling against a foundation or a customer away until the weekend

4. 04

   Notice drafted

   Owner

   Recalls Bot

   Advances when

   A new-date draft appears in the owner's conversation with the Bot

5. 05

   Notice sent

   Owner

   The owner

   Advances when

   The owner edits the draft and sends it

6. 06

   Cleaned

   Owner

   The crew

   Advances when

   The visit is done and photographed

   Ends when

   The row closes and the rebook flag on the recall list clears

A long rebook queue tempts a company to catch up on wet roofs. OSHA's construction ladder rule, 29 CFR 1926.1053, puts duties on employers: as checked on 15 October 2026, a ladder must stand on a stable, level surface unless it is secured so it cannot be displaced, and must not be used on a slippery surface unless secured or given slip-resistant feet. Which standard covers a cleaning visit, and whether a state's own OSHA-approved plan applies, is for the owner to confirm. The Recalls Bot can mark which rebooked days follow rain on the owner's forecast note; whether the crew climbs is decided at the house.

Before the routine, write the cluster rule in one sentence: how many visits make a day, and which streets never share one. Then write the storm-order rule the same way. A Recalls Bot can apply both; it cannot invent either, and the reliable-workflows pillar explains why a recall routine should stop rather than guess. The workflow automation readiness assessment, free and ungated, scores the recall workflow on twelve dimensions before anything is built and returns a result with the blockers it found; rule clarity shows whether those two sentences exist yet. Building the list, the routine and any custom integration to your scheduling software is then a conversation to have with Aevrion Ops, if the vendor's API or terms permit it and only after testing.

1. Gutter cleaning pays on grouped visits, so the recall list is sorted by neighborhood as well as by due date.
2. The list is rebuilt from the company's exported customer data each cycle, never from a Bot's memory.
3. Neighborhood clusters are a draft the owner approves and corrects for what the data cannot know.
4. A weekly routine drafts reminders, checks for existing drafts and stops if its sources cannot be read; the owner sends every reminder.
5. Storm rebooks get their own queue, ordered by the owner; damage reports leave the queue, and any roofer referral is the owner's call.