The Reason For Outage (RFO) is the customer-facing account of the incident. After the Major Case is closed, the MSO team drafts it, one member of the MSO approver group approves it, and it's published as a PDF to every affected customer's case and emailed to their contacts.
When the RFO starts
The RFO starts when the Major Case is closed. Before that, the Reason For Outage tab just explains what will happen. When the case is closed:
Version 1 is created as a Draft, with all five sections empty.
Its due date is set: the closing date plus the Publication target (days) in your Major Incident settings, 14 unless changed. Changing the setting later doesn't move RFOs that already exist.
A high-priority task, RFO due: Major Case [reference], is created for the Named Incident Manager, due on the same date. It's completed automatically when the RFO is published.
The tab's heading shows the version and status, for example v1 · Draft, and the target date. Once the target has passed it also shows how many days overdue the RFO is.
Step 1: draft it
You need the MSO Team or MSO Manager role. Fill in the five sections under Customer-facing document:
Section | What to write |
Incident background | What service was affected, who was affected and when it started. |
Incident details | The sequence of events in plain language. |
Root cause analysis | What caused it, in neutral and factual terms. |
Corrective improvements | What has been changed so it doesn't happen again. |
Follow-up actions | Anything still to be done, with owners and dates. |
Nothing is copied in from the Structured Review. Use it as your source, rewritten for customers.
The boxes are plain text. Leave a blank line to start a new paragraph.
Click Save draft as you go.
Step 2: submit it for approval
When all five sections are filled in and saved, click Submit for approval. It stays greyed out until they are.
Confirm. Your latest changes are saved first.
Everyone in the MSO approver group with an email address is emailed RFO awaiting approval: [Major Case reference], with a link to the case. The status becomes Awaiting approval and the document can't be edited until someone decides. You can't withdraw a submission yourself. If you spot a mistake, ask an approver to request changes.
Step 3: approve it, or ask for changes
This step is for members of the MSO approver group. Open the Major Case's Reason For Outage tab. Open Who receives it to check who it will be emailed to and who won't be.
To send it back: write what needs to change in What needs to change and click Request changes. The person who submitted it is emailed your note. The status becomes Changes requested, the note is shown at the top of the tab, and the drafter edits and submits it again.
To approve: click Approve and publish and confirm. Approving publishes it straight away, so check it first.
One approval is enough. If Allow self-approval is No in your settings, the person who submitted the RFO can't approve it, even if they're in the approver group.
What publishing does
The RFO is turned into a PDF.
Each affected customer's case gets the PDF, named Reason For Outage [their case reference] v1.pdf, available on the customer portal, and a customer-visible note saying the Reason For Outage has been published.
Each customer contact on those cases is emailed with the PDF attached. If the customer uses your customer portal, the email also has a link to open it there. Staff watchers on the child cases get a link instead of an attachment.
The Major Case's own staff watchers get a summary email, and the Major Case gets an internal note with a link to the PDF.
The RFO task is completed, and the Major Case shows as Closed instead of Closed, awaiting RFO.
You'll see, for example, RFO v1 approved and published: attached to 6 cases and emailed to 14 recipients. Recipients follow the same rules as a customer update, see Keep everyone updated during a Major Case.
What's in the PDF
Your company logo, or your company name if you don't have one, and the Major Case reference and version number.
The title Reason For Outage with the Major Case's subject.
A summary: incident reference, incident manager, outage type, supplier or provider (if set), when it started and was resolved, its duration, and the publication date. The start and resolution times come from the Structured Review.
Your five sections. A section left empty prints "None."
A closing line saying your company prepared it as a factual account of the incident.
Every affected customer receives the same PDF, and it shows the Major Case's subject and reference and the Named Incident Manager's name. Make sure the subject reads well to a customer before you publish.
If publishing doesn't finish
If some cases couldn't be reached, you'll see, for example, The RFO reached 5 of 6 affected customers' cases; 1 failed. Use Publish to retry the rest. The RFO stays Approved. Someone with an MSO role clicks Publish to the affected customers. Cases it already reached are skipped, so nobody gets it twice.
If the PDF couldn't be created, the message says so. Use Publish to try again, or contact support.
Correct a published RFO
On the Reason For Outage tab, click Amend (new version) and confirm.
Version 2 opens as a draft with the same text. Correct it, then submit it and get it approved as before.
Until version 2 is published, version 1 stays on the customers' cases and portal. When version 2 is published, every customer gets the new PDF and email, and the version 1 files are renamed Superseded: ... and taken off the portal. Copies already sent as email attachments can't be recalled.
Version 2 gets a new due date, counted from when you clicked Amend. No new task is created.
Overdue RFOs
An RFO is overdue once its due date has passed and it hasn't been published. It shows as, for example, 3 days overdue on the Reason For Outage tab and in the Major Incident section, and it's listed on the Overdue RFOs dashboard tile. See Find Major Cases and track overdue RFOs.
What your customers see
An email about their own case, Reason For Outage for your case [their case reference]: [their case subject], with the PDF attached and, if they use the portal, a link to open it there.
On the customer portal, a note on their case saying the Reason For Outage has been published, and the PDF in that case's files.