Business software incidents: specifying useful customer status updates

When a business system stops working, your customer also has to explain the situation to their own customers. Include incident communication in the specification: what is affected, what still works, what users should do and when they will receive another update. The next update time is not a repair deadline. Separating these promises lets a team provide useful information while recovery remains uncertain, without turning an estimate into a business commitment.

What can the Toll incident teach product buyers?

In February 2020, SmartCompany reported disruption at Toll following ransomware. Business owners complained about untraceable deliveries and difficulty answering their customers. The report also records statements from Toll and manual operations at some centres; it does not establish that the company provided no updates. The product-design question is the gap between a general incident announcement and information a customer can use to make decisions.

Our interpretation of the draft is that incident communication forms part of the service a product provides. Software used by another business becomes part of that business’s promises, schedules and support workload. A status page can help explain a delay, but only if it describes the impact in language the business understands. A list of technical components does not necessarily answer whether customers can continue accepting orders or promising delivery dates.

Specify affected actions, not just green and red indicators

Start with the actions customers perform: signing in, submitting a request, paying, updating information and receiving a result. For each action, define the message when it is unavailable, slow or has an uncertain outcome. Also distinguish a general incident from an issue affecting a particular group. You do not need to expose other customers’ information to explain whether an incident is relevant to the reader.

In a hypothetical ordering system, an update might say that new orders remain available while shipment-status updates are delayed. That differs substantially from saying the whole system is down. If it is unclear whether a request was saved, explain how users can check it and when to contact support. Do not issue a blanket instruction to try again before checking whether another attempt could create duplicate orders or charges.

Separate recovery estimates from the next update time

A useful status message can include the known start of impact, affected actions, current investigation, recommended customer action and the next update time. If the start time remains unknown, say so instead of presenting an estimate as fact. Include the time zone, particularly when customers operate in different countries. Readers should be able to establish whether information is current without calculating the difference themselves.

You can commit to reviewing and communicating at a particular time without promising recovery by then. Choose the frequency according to impact and the team’s capacity to maintain it. When there is no progress, a short update can acknowledge that no recovery time is confirmed and identify the next investigation step. If an estimate changes, preserve a clear history instead of silently replacing the previous promise. This also helps the next support representative understand what customers have already been told.

Assign ownership and make updates accessible during an outage

Ask the software team to identify who coordinates information, who checks the facts and who can substitute when needed. Check that publishing permissions and account access do not depend on one person. Approval should match the significance of the message; an initial notice about an impact under investigation does not require inventing an unconfirmed cause. Personal information and investigation details do not belong on a public status page.

A page requiring sign-in to the failed system will not help when customers need it. Define a channel they can reach in that situation and examine its dependence on the same server, account or authentication mechanism. Independence brings operating costs, so match the arrangement to business needs. Designate one authoritative update location for email and support messages to reference, reducing contradictory versions that remain in circulation after the situation changes.

Test the message that declares the incident over

A working login screen does not prove that accumulated work has completed. Define closure checks in advance: the affected action works, pending requests have been handled or are described separately, and customers understand any action required of them. You can report that service has returned while remaining discrepancies are being addressed, if that is the verified situation. Avoid a success announcement broader than the available evidence.

Julius’s documented publishing process records a successful content-system write separately from verification that the page is publicly available. The runbook requires checking public URLs and discovery surfaces before announcing success. This is a documented internal workflow, not a claim about responding to a customer security incident. Its relevant principle is that completion messages should follow the outcome the recipient needs, rather than merely a successful internal operation.

What should the development proposal include?

Add a scenario to the technology product specification in which the main action fails but customers still need to communicate. Request demonstrations of publishing an update, substituting the owner, accessing information without sign-in and announcing recovery. Establish who maintains the channel and what the price includes. This complements accurate transactional notifications, which concerns individual actions, rather than replacing that work.

If AI helps draft updates, restrict it to approved facts and check that it has not introduced a cause, repair promise or untested instruction. That decision also belongs in choosing AI developers, beyond copy editing. When comparing software development services, ask how incident communication ownership fits into specification, testing and maintenance. You can then compare a concrete scope of work before signing.