LearnGrokUse this review when the same service failure appears more than once and informal fixes have not held. You will produce one review that separates evidence from assumptions, names contributing factors, assigns corrective actions and sets tests for recurrence. It is for operations managers who need a defensible next step, not another incident summary.
Key point
Review the system, not the latest person
A repeated failure usually persists because the process permits it. Start with the conditions shared across incidents.
1. Set one failure statement
Write a single sentence before you collect material. It must describe the service outcome, the affected group and the repeat pattern.
Use this form:
[Service outcome] failed for [customer, site or process] when [trigger or stage], occurring [repeat pattern].
For example: Dispatch confirmation was not sent to retail customers after an address change, appearing in five incidents during the monthly account update cycle.
Do not write poor communication, human error or system issue as the failure statement. Those are possible explanations. They are not observable outcomes.
Create a review folder or workspace with these sections:
- Incident records: dates, ticket IDs, impact, detection time and resolution time.
- Team notes: handover notes, meeting notes and accounts from people who did the work.
- Process evidence: the current procedure, forms, approval records, screenshots, queue history and training material.
- Review draft: the document you will ask the model to structure.
Remove customer names, personal contact details and credentials before sharing material. Keep the source ID and date, because you will need to trace each claim back to its record.
Watch out
Do not combine unlike failures
If incidents have different triggers or different service outcomes, split them into separate reviews. A broad category hides the cause you need to fix.
2. Build an evidence ledger first
Make a table before asking for analysis. One row should cover one fact, not an interpretation.
| Source ID | Date or period | Observed fact | What it supports |
|---|---|---|---|
| INC-014 | 12 May | Address-change queue had no confirmation task | Possible control gap |
| PROC-03 | Current | Procedure says staff should create the task manually | Reliance on manual step |
| NOTE-07 | 13 May | Two staff members said the handover did not mention the queue | Handover weakness |
Use exact wording for key evidence where possible. Record contradictions too. If one note says the queue was checked and the audit record shows no check, preserve both. The contradiction is part of the review.
Then identify the comparison group. You need at least one example where the process worked, or a period in which the failure did not occur. It helps you distinguish a normal process step from a condition linked to failure.
Check
Your ledger is ready when another manager can locate every major claim
Each important statement should have a source ID, date and enough detail to find the original record without relying on memory.
3. Ask for a structured analysis
Give the model the failure statement, evidence ledger and relevant extracts from the procedure. State that it must not fill missing facts with plausible explanations. Product behaviour and available limits can vary, so check the current guidance in the xAI documentation overview before handling a large set of records.
Use this prompt, replacing the bracketed text:
Act as an operations review analyst. Analyse the recurring failure below using only the supplied evidence.
Failure statement: [insert one sentence]
Evidence ledger:
[insert table]
Process extracts and team notes:
[insert material]
Produce a root cause review with these headings:
1. Failure and impact
2. Confirmed evidence, citing source IDs
3. Patterns across incidents
4. Likely contributing factors
5. Evidence gaps and conflicting evidence
6. Corrective actions
7. Owners, due dates and measures
8. Recurrence checks after implementation
Rules:
- Separate confirmed facts, inferences and unknowns.
- Do not name an individual as a root cause.
- Do not claim a cause unless at least two evidence items support it, or clearly label it as a hypothesis.
- For each action, state the process condition it changes.
- Flag any action that is only a reminder, retraining request or request for greater care.
Read the first output as a draft, not a decision. The useful part is its structure: it should expose unsupported leaps, repeated conditions and missing evidence.
4. Test the proposed causes
For each likely contributing factor, ask three questions:
- Mechanism: How could this condition produce the observed failure?
- Pattern: Does it appear in failed cases more than in working cases?
- Counterfactual: If this condition were removed, would the process still permit the failure?
A cause that passes only the first question is a plausible story. Do not present it as established.
Use a short cause map in the review:
| Contributing factor | Evidence | Confidence | Condition to change |
|---|---|---|---|
| Manual task creation after address changes | INC-014, PROC-03, INC-021 | Medium | Create the task automatically or add a verified control |
| Handover omits queue status | NOTE-07, NOTE-11 | Medium | Add queue status to the handover record |
Do not accept staff were not careful enough as a corrective finding. Ask what made an omission easy, invisible or unrecoverable. A manual step may remain necessary, but it needs a clear trigger, a named owner and evidence that it happened.
Note
Retraining is usually supporting work
Training may help with a changed process. On its own, it rarely changes the condition that allowed repeated failure.
5. Turn findings into corrective actions
Each action needs one owner, one completion condition and one measure. Avoid shared ownership such as Operations and Support. One person can coordinate work across both teams.
Write actions in this format:
[Owner] will [change] by [date]. Complete when [observable proof]. Measure [recurrence or control measure] for [review period].
For example: Service Operations Manager will add a mandatory address-change confirmation field to the handover record. Complete when the field is live and sampled records show it is used. Measure the proportion of address changes with a completed confirmation and the number of missed confirmations each weekly review.
Use two kinds of measure:
- Control measure: whether the new step happens, such as completed confirmation fields or queue checks.
- Outcome measure: whether the customer-facing failure returns, such as missed dispatch confirmations.
A control measure can improve while outcomes remain poor. That tells you the new control is being followed but is not sufficient.
6. Publish, review and close carefully
Publish the review with a short decision section: what is known, what remains a hypothesis, which actions are approved and when you will check results. Send the draft to the people who own the process evidence, not only to the people involved in the latest incident.
At each recurrence check, append results rather than rewriting the original conclusion. Record whether the failure occurred, whether the control operated and what changed in the process or volume. This creates a usable history if the issue returns.
Check
The review is actionable when every action can be verified
You should be able to answer: who changes what, what proves completion, and what result would show the failure is returning.
When the review does not work
If the output gives generic causes, provide more specific evidence: timestamps, process versions, queue records and examples of successful cases. If it treats assumptions as facts, ask it to reproduce the source ID beside every claim and move unsupported statements into Evidence gaps.
If no cause is supported, do not force one. Set a temporary containment action, such as an additional check at the failure point, and collect evidence on the next occurrences. If actions are complete but the failure continues, reopen the review, compare the new incidents with the old pattern and test whether the original scope was too narrow.
