What can customers be told at 09:30?
Use verified broadband service counts and keep the next update time clear.
The question
You coordinate updates for a fictional residential fixed broadband fault in Australia. At 09:00 the incident lead has checked part of the service list. The team has promised the next public status update by 10:00.
| Distinct services | |
|---|---|
| Under review | 1600 |
| Confirmed affected | 1200 |
| Unconfirmed | 400 |
Each service ID belongs to one group. The incident lead owns the verified counts and approves public updates.
“What can you say from the current record, and what would you check before the next update?”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Separate confirmed and unknown
What would you do here? Open the move you’d make.
Use 1,200 as confirmed and keep 400 under review.
The strong move. The list includes every service under review. Only the verified group counts as affected.
Use all 1,600 as confirmed affected.
Tempting, but it misses something. The incident lead has yet to confirm the status of 400 service IDs.
See how a strong candidate says it
“At 09:00 we have confirmed 1,200 affected broadband services. The lead is still checking the other 400 service IDs.”
Why it works: The list includes every service under review. Only the verified group counts as affected.
Step 2: Give the first update
What would you do here? Open the move you’d make.
Name broadband as the affected service and give the 10:00 update time.
The strong move. A verified description and a clear update time give customers information while the team checks the fault.
Promise that all services will recover by 10:00.
Tempting, but it misses something. 10:00 is the next update time. The lead has yet to confirm the recovery time.
See how a strong candidate says it
“Some broadband services in this area are affected. Our incident team is checking the remaining service records. We will share another update by 10:00.”
Why it works: A verified description and a clear update time give customers information while the team checks the fault.
Step 3: Reconcile the new counts
At 09:30 the lead verifies that 900 of the first 1,200 affected services have recovered and 300 remain affected. Of the 400 under review, 100 are now confirmed affected and still offline. The other 300 were unaffected throughout the window.
What would you do here? Open the move you’d make.
Report 900 restored and 400 still affected out of 1,300 confirmed affected.
The strong move. The current affected count is 300 from the first group plus 100 from the group under review. 900 of 1,300 is about 69.2% restored.
Subtract 900 from the 1,600 originally under review and report 700 still affected.
Tempting, but it misses something. 300 of the original service IDs were unaffected throughout the window. They belong outside the affected total.
See how a strong candidate says it
“We now have 1,300 confirmed affected at some point. We’ve verified restoration for 900. There are 400 still affected, including the 100 the lead just confirmed.”
Why it works: The current affected count is 300 from the first group plus 100 from the group under review. 900 of 1,300 is about 69.2% restored.
Step 4: Give the corrected update
What would you do here? Open the move you’d make.
Give the lead the checked counts and keep the 10:00 update.
The strong move. The update states what the team has verified and keeps an owner and time for the next check.
Close the incident when the first 900 services recover.
Tempting, but it misses something. 400 services remain affected. The lead still owns the next update.
See how a strong candidate says it
“I’d ask the incident lead to approve this update. At 09:30, 900 broadband services have recovered and 400 remain affected. We will update customers again by 10:00.”
Why it works: The update states what the team has verified and keeps an owner and time for the next check.
The answer, in short
- Decision
- Report 900 verified restorations and 400 broadband services still affected.
- Because
- 1,300 services were confirmed affected and the groups reconcile to the service list.
- What would change it
- A new verified count or recovery estimate from the incident lead would change the next update.
Common traps
- Reporting every service under review as affected.
- Using the next update time as a recovery promise.
Check your answer
- I separated affected from unconfirmed.
- I gave an update time.
- I reconciled the new counts.
- I kept the incident lead as owner.
Last reviewed Nov 11, 2026