When ITIL Taught Me About Writing a Status Update No One Misunderstands

Or... when operational excellence and language teaching combined...

A few years into my ops career, I got ITIL v4 Managing Professional certified because I thought it would teach me better processes. It did. But the thing that actually changed how I manage teams wasn’t a framework diagram, it was a much smaller idea buried inside incident management: communicating to stakeholders throughout the entire lifecycle of an incident, not just at the start and the end.

That sounds obvious until you’ve sat in an ops channel during a live payment outage and watched someone type: "Looking into it, should be back soon." Six words. Completely unhelpful. Nobody knows what "it" is, who’s affected, what "soon" means, or who’s actually doing anything. In a fast-moving iGaming environment; deposits failing, players messaging support, affiliates asking questions - that one vague line multiplies. Support escalates unnecessarily. Leadership pings three people for an update they should already have. The incident channel is filled with "any update?" instead of information.

This isn’t a technical failure. It’s a writing failure. And it’s expensive.

PMI’s research on project communication found that 56% of dollars at risk on a troubled project ($75 million of every $135 million at risk per $1 billion spent)  traces back to ineffective communication, not the underlying technical problem. Separately, PMI found that organizations with highly effective communicators are more than five times as likely to be high-performing (38% versus 7%), complete projects on time far more often (71% versus 37%), and stay within budget more often (76% versus 48%) than those with weak communication practices. None of that is about technical skill. It’s about whether people write status updates that actually transfer information.

ITIL’s answer to this is structural: a defined stakeholder, a preferred method, and a templated communication that has to answer specific questions before anyone hits send. That structure is worth stealing for any team, but it matters most for teams where English is a second or third language, because the instinct under pressure, in an unfamiliar language, is to default to short, vague, "safe" phrases. "Should be fine soon" feels safer to write than "Payment gateway is down since 14:02, affecting EU card deposits, engineering is on it, next update at 14:30" - even though the second version is barely longer and eliminates every follow-up question.

Here’s the framework I now teach, and it maps directly onto what ITIL already expects from a good incident update:

•  What broke - name the specific system or process, not "it" or "the thing"

•  Who’s affected - which users, region, or team, and since when

•  What’s being done - who owns it right now, by name or role

•  When you’ll update again: a specific time, not "soon" or "shortly"

None of that requires native-level fluency. It requires training people to replace hedging language with specific language. A skill that’s entirely teachable, and one that pays for itself the first time it prevents a five-person escalation call over an incident that was already being handled. If your ops, support, or compliance teams are still writing "should be fine soon" under pressure, that’s not a confidence problem. It’s a vocabulary and structure problem - and it’s fixable a lot faster than a reorg.

Sources

1 - INOC, "5 ITIL Incident Management Best Practices," https://www.inoc.com/blog/itil-incident-management

2 - PMI, "The Essential Role of Communications," Pulse of the Profession, https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/the-essential-role-of-communications.pdf

3 - PMI, "Communication," https://www.pmi.org/learning/library/communication-11189

4 - INOC, "5 ITIL Incident Management Best Practices," https://www.inoc.com/blog/itil-incident-management