SpaceXSI describes using two Grok Bot teammates to handle different stages of a support incident. Its October 20 account focuses on noticing repeated reports early and clearing the related backlog after the issue is resolved.
IncidentWatch looks for a shared problem
IncidentWatch reviews the previous 15 minutes of tickets every five minutes, looking for spikes around the same issue. If the pattern does not match an existing incident, it alerts the on-call support engineer with a count and examples.
A person decides whether the reports point to an incident and works with engineering to investigate. The workflow therefore uses a cluster of customer reports as a signal to assess, rather than automatically declaring every spike a confirmed outage.
IncidentSweep prepares a bounded send
After resolution, a support engineer specifies the tickets to consider, exclusions and the exact message. IncidentSweep prepares the proposed batch and sets aside tickets it cannot confidently connect to the incident.
The engineer can inspect and change the batch before approving it. The publisher says no tickets are added after approval, actions are recorded, and a failure stops the process and produces a report.
The account reports clearing 204 tickets in about ten minutes during one September incident. That is a company-reported example with human approval, not a general throughput guarantee or a Franklin benchmark.
What transfers to another support team
Franklin’s interpretation is that the approval boundary is more useful than the headline ticket count. A team evaluating a similar workflow should inspect both false matches and excluded customers, preserve the approved recipient set and keep a record of what was sent.
Detection and communication also require different evidence. Several similar complaints may justify investigation, while a final response should depend on a confirmed incident and an appropriate resolution message.
Read the publisher’s workflow account for the operating sequence and the reported internal example.