Live Channels
Part of Support platform reliability
Planning customer communication during a helpdesk outage
Prepare an outage message, an independent update route, an owner and a reliable update cadence while support is disrupted.
Plan a way to reach customers when the helpdesk cannot. Name a communication owner, a publishing route outside the affected helpdesk, the likely audience and the next-update rule. Prepare the decision and message structure before an incident; publish only facts confirmed during it.
Decide when to communicate
If customers cannot submit a request, agents cannot answer or replies are failing, confirm the observed effect and issue a bounded update. If the extent is unknown, say so.
Say what is affected, what customers can do now and when another update will appear. Include a restoration estimate only when the response team has a basis for it.
Separate a broad service notice from individual case updates. A public notice can explain that support is delayed.
Someone with an urgent open matter may also need a direct update through a verified alternative route. Keep one agreed account of the incident so the messages stay consistent.
Public Notice vs. Individual Case Updates
- Public NoticeFor all customers: explains support delays, affects all users, shared via status page or email.
- Individual Case UpdateFor urgent matters: direct message through a verified fallback route (e.g., phone, alternative email), requires manual follow-up.
Choose a route that survives the failure
A status page or message tool outside the affected helpdesk can be the public update point if staff have confirmed they can reach and publish to it. Atlassian Statuspage supports incident updates and optional subscriber notifications; it does not directly monitor service health.
Check the publishing login, approval path and out-of-hours cover. For an Australian team serving several time zones, state the time zone in each promised update time.
If the usual support address still receives mail but agents cannot see it in the helpdesk, arrange for its owner to retain and review incoming messages. Do not advertise a fallback address until it is monitored and the team can later transfer its requests into the working queue.
Pre-Outage Preparation Checklist
- Verify access to status pageConfirm staff can log in and publish updates even during helpdesk failure.
- Test approval pathEnsure there's a clear process for approving updates without relying on the helpdesk.
- Confirm out-of-hours coverAssign someone available after hours to maintain communication.
- Specify time zoneAlways state time zone (e.g., AEST) in update times for clarity across regions.
- Monitor fallback inboxOnly advertise a backup contact method once it’s actively monitored and requests can be transferred to the main queue.
Give each update a useful shape
Include the affected channel or service in customer terms, the observed effect, any confirmed working alternative, the action for an urgent matter and the time of the next update. An investigation can continue while a scheduled update tells customers what has and has not changed.
Statuspage has investigating, identified, monitoring and resolved incident stages. Those labels can organise publication, but the message should describe the current customer effect. A monitoring update should not claim restoration before the team has checked intake and replies.
Critical Metrics for Incident Communication
- Incident stage
- Use labels like 'Investigating', 'Identified', 'Monitoring', 'Resolved' (from Statuspage)
- Affected service
- Describe in customer terms (e.g., 'Helpdesk portal', 'Email support inbox')
- Working alternative
- State any available workaround (e.g., 'Use the contact form on our website')
Close the communication loop
After restoration, check that customers can reach support and receive replies, then publish the service update. Identify messages received through fallback routes and customers promised an individual answer.
Assign that work before saying ordinary handling has resumed. Review whether the first notice, update times and fallback instructions helped customers take the next step.
Incident Communication Timeline
- Post-restoration verificationConfirm customers can access support and receive replies before closing the loop.
- Publish final updateShare resolution details and confirm service is fully restored.
- Review fallback messagesIdentify and process any requests received through alternative channels.
- Reassign resolved workAssign tasks from fallback routes to the support queue before resuming normal operations.
- Evaluate communication effectivenessAssess whether first notice, update timing, and fallback instructions helped customers act.
