The Reason For Outage document is usually written by the people least available to write it — the engineers who have just spent the night restoring service — for an audience they never meet, against a deadline set by a contract they did not negotiate. Very little in the operational reward structure encourages doing it well.
It is also, frequently, the only artefact about the incident that the customer's executives will ever read. The restoration is judged on minutes; the relationship is judged on the document that explains them.
An RFO Is Not a Shortened RCA
The internal root cause analysis answers a question about your systems: what in our design, process or configuration allowed this to happen. The RFO answers a question about the customer's service: what happened to it, for how long, was it your fault, and will it happen again.
These are the same facts at different resolutions and different disclosure levels. The RFO should be a projection of the RCA, derived from the same evidence base, rather than a retelling of it in softer language.
Carriers often maintain two distinct customer-facing artefacts rather than one. Colt, for example, distinguishes a short RFO — a brief statement of cause and preventive steps, attached to a closed repair ticket — from a detailed Incident Report showing the full ticket progression timeline, which is requested separately and takes five to seven working days. Conflating the two is a reliable source of customer dissatisfaction.
What Belongs In It
Five elements appear consistently across carrier and vendor practice: incident overview with start and end times, root cause, impact assessment, resolution, and preventive measures. In practice a further three earn their place: the customer's own service or circuit identifier rather than yours, the impact window stated in the customer's timezone, and the SLA position — whether the event is credit-eligible and how to claim.
The preventive actions section is the one customers actually scrutinise, and it is worth very little without named owners and target dates. A commitment with no date is read, correctly, as an absence of commitment.
The Failure Modes
Too technical: the internal RCA shipped with hostnames, vendor names, engineer names and code versions intact. This creates disclosure exposure and still tells the customer nothing about their service. Too vague: a hardware issue in the core network was resolved. This signals either that you do not know or that you will not say, and the second reading is the damaging one.
Blame-shifting is subtler. Attributing an outage to an upstream provider without addressing why a single third party could take the service down leaves the design question conspicuously unanswered, and customers notice the omission immediately.
The most expensive error in an RFO is not an imprecise root cause. It is a stated outage window that disagrees with the ticket record, because that window is the credit calculation input.
Duration disputes turn a service problem into a contractual one. Whether the clock starts at first alarm, first customer report or ticket creation — and stops at service restoration, customer confirmation or ticket closure — must be defined in the contract and applied identically every time. An RFO that says fibre cut while the ticket says card failure, against a third duration used for the credit, is how that dispute begins.
Timeliness Against Accuracy
Late delivery is the commonest failure and the most avoidable. By the time a thirty-day document arrives, the customer has escalated, claimed credits and formed a settled view. But issuing early risks asserting a cause that the problem record later contradicts, which is worse.
Regulators have already settled this tension with staged reporting, and the pattern transfers cleanly to commercial RFOs. Under the FCC's outage rules in 47 CFR Part 4, wireline, cable, satellite, wireless and SS7 providers file notification within 120 minutes, an initial report within three days, and a final report within thirty. A preliminary RFO within 24 to 48 hours — stating what is known, what is not, and when the final will arrive — protects both the relationship and the record.
Regulatory filings and customer RFOs are different documents with different disclosure regimes and must not be produced by copy-paste. Data submitted to the FCC's Network Outage Reporting System is presumed confidential. In Europe, note also that NIS2 repealed Articles 40 and 41 of the EECC on 18 October 2024; reporting obligations that still cite the EECC articles are out of date.
Where Machine Assistance Earns Its Place
Language models are genuinely useful here, and the useful applications are narrow. Drafting a first version from the incident timeline and ticket notes. Enforcing a house structure and a consistent reading level across hundreds of documents and many authors. Translating. Flagging over-disclosure — named individuals, internal hostnames, vendor names — before a human reviews. Checking the draft against the ticket record for internal contradictions, particularly on duration.
The boundaries matter more than the capabilities. A model should never be asked to assert causation: it will produce a fluent causal narrative from a merely correlated timeline, which is precisely the failure mode that good root cause analysis exists to prevent. The causal chain comes from the problem record. Nor should the model compute the impact window — derive it deterministically from the alarm and ticket systems and pass it in as a constrained input.
Responsibility does not transfer to the tool. When Air Canada's chatbot invented a bereavement fare policy in 2024, the airline argued the bot was a separate entity responsible for its own statements; the tribunal rejected that and ordered damages. An RFO is a contractual document that may later be contested, so retain the evidence each one was drafted from alongside the issued version.
Treating It As a Product
The organisations that do this well stop treating the RFO as a writing task and start treating it as an output of the incident pipeline. One verified timeline, one agreed impact window, one causal chain, and two documents generated from it under review gates appropriate to severity — engineering verifies the facts, service management verifies the SLA position, and anything above a threshold gets a commercial read before it goes out.
That this is achievable at scale is not theoretical. Lumen exposes an RFO request as a ticket-keyed operation in its ticketing API. Once the document is addressable by system rather than assembled by hand, consistency with the technical record stops depending on the diligence of whoever was on shift.