An outage has been reported, the ticket system is showing red, and users want to know: what's going on, how much longer will it take, and when will I hear back. This is work that service desk and communications staff do daily. The question here is not whether AI can write text, but whether AI can independently take over this specific communication work. The answer: partly, and it depends heavily on what kind of outage it is.
The task scores high on structuredness (4): an outage notification often follows a fixed pattern — what is wrong, since when, which systems are affected, what is the expected resolution time. That pattern is exactly what a language model can fill in well, as long as the underlying information is correct. Physical (5) is also not a barrier: no action in the real world is required, only text that needs to go out.
On the other hand, customer contact scores low (1). This is by definition communication with people who are often already frustrated because their work is at a standstill. The tone, timing, and precision of a message determine whether users feel heard or, conversely, ignored. A generated message that is factually correct but misjudges the urgency does more damage than no message at all.
Cost of error (3) is moderate but not negligible: an incorrect resolution time or a status that doesn't update undermines trust and leads to a stream of follow-up questions — exactly the work you were trying to save. Compliance (4) comes into play as soon as the incident falls under SLA agreements or, in some sectors, mandatory reporting requirements: in that case, communication must be demonstrably sent on time and according to fixed standards. Judgment latitude (2) and creativity (2) are low: there is little room to decide for yourself what to report; it is largely about following a template with current data. Volume (4) is high: in a major outage, it concerns hundreds or thousands of users who need the same message, and that is exactly where automation frees up time.
Three axes determine the picture. Structuredness makes it technically feasible: if the incident status is clearly recorded in the system, a language model can build a message from it according to a fixed template. But low customer contact puts a brake on that — not because AI can't write a correct sentence, but because the risk of a badly timed or badly toned notification is higher than with internal or administrative text. And the cost of error means oversight remains necessary: a status update that goes out before a fix is confirmed, or that estimates the resolution time too optimistically, leads to new complaints instead of fewer.
An example makes this concrete. In the case of an outage in an internal email system, where the impact is known and the resolution time is reasonably predictable, AI can draft the initial notification and the interim status update based on the ticket, with an employee briefly approving it before the message is sent. In the case of an outage affecting customers' payment functionality, with financial consequences and an uncertain resolution time, it's different: human judgment is needed about what to say and what not to say, and when.
At a company with a mature status page and a ticket system that automatically fills in the right fields, the share that AI can handle is larger: the text can come directly from structured data. At a company where outages are reported verbally, in loose Slack messages or via an IT manager who assesses it themselves, the structured basis is missing and there is little that AI can draft independently. The nature of the users also matters: internal employees accept a brief, factual update; external customers with a contract and SLA expect a tone and completeness that is more likely to require human oversight.
This task is not separate from the rest of the incident chain. Whether an outage is communicated effectively depends on how well system performance is monitored — without reliable monitoring, there is no current status to communicate. It also relates to how the incident is logged and prioritized, because that determines what data is available to base a message on. And in some cases, communication runs parallel to the actual resolution of the first-line IT incident, where the update is only as good as the progress actually being made.
Concretely: drafting text based on fixed templates, with the current incident status as input, is feasible once those two preconditions are in place. The decision on when a message goes out, in what tone, and whether the resolution time is realistically stated, remains with the employee. This is not an intermediate stage on the way to full takeover — it is the structure that fits this type of communication as long as the cost of a misplaced message remains higher than the time it takes to check it.
If this analysis leads you to consider the deployment of service desk or communications staff, please note that separate legal requirements apply regarding work and employee representation; this page does not provide personnel advice and is not a justification for a dismissal decision. For broader care around role changes, see due care when cutting roles.
Would you like to know how much of the incident communication in your own company already falls within these preconditions today? The free quickscan from FTE TO AI consists of twelve questions, requires no account, and provides an indication of what portion of the hours in this profile can be taken over by AI today. The full work scan, with the extensive task analysis per team, is still under construction — we deliberately do not yet offer that here.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.