Picture the engineer these tools were first drawn for. Fresh, well rested, sitting at a wide monitor, fluent in the vendor’s English, reading colours without effort. Now picture who is actually on the rota at 3 a.m.: someone squinting at a phone in a dark kitchen, someone whose first language is not English, someone who is colour-blind, someone who relies on a screen reader. For a long time AIOps products treated those people as edge cases. That is changing, and it is the most interesting quiet shift in the field right now.

The story I keep hearing from operations leads goes like this. A team adopts a smart platform that groups related signals and proposes a probable cause. It looks great in the demo. Then a new colleague who reads English as a second language joins the rota and stumbles over idioms in the incident summaries. Another teammate cannot tell the amber state from the red one on the status panel. Nobody complained loudly, but the tool was quietly working for only part of the team.

The imagined average operator

Every product is designed against a mental picture of a user. When that picture is narrow, the gaps are predictable. Status is shown by colour alone. Summaries are written in dense, clever phrasing. Key actions hide behind hover menus that a keyboard cannot reach. Notifications assume a large screen and a quiet room. None of this is malicious; it is simply what happens when nobody asks who is missing from the picture.

The people who get shut out are not rare. Colour-vision differences are common. Many teams are spread across countries and languages. Tired people read worse at night, and everyone is tired at night. Anyone can be on a slow mobile connection from a train, a hospital corridor or a rural site. Design that accounts for these situations is not charity work; it is a description of ordinary working life.

What inclusive AIOps looks like in practice

The teams doing this well start small and concrete. They rewrite automated incident summaries in plain words: what broke, what it affects, what to try first. They pair every colour with a word or a shape, so “degraded” is readable without hue. They make every action reachable from a keyboard and check that a screen reader announces it sensibly. They test the on-call phone view with one hand and a bad signal. These are modest changes, and each one pays off for the whole rota.

A useful rule of thumb is to offer more than one route to the same outcome. A person might acknowledge an incident from a chat message, a phone notification, or the console. A runbook might exist as short text and as a numbered list with screenshots described in words. Redundancy sounds wasteful until the one route you built fails for someone, and then it is the only thing that matters.

Plain language is a reliability feature

It is tempting to file readability under “nice to have”. Experienced responders disagree. When a summary can be understood on the first read, the first action happens sooner and mistakes are fewer. We have written before about how a team can put AI to work behind IT decisions, and the same principle applies to the words the system produces: if a human cannot parse the recommendation quickly, the clever model behind it has not helped anyone.

Plain language also keeps multilingual teams honest. Translating a sentence full of metaphors rarely goes well, while a short sentence with a clear subject and verb survives translation tools and tired eyes alike. Teams that adopt a house style for automated messages, with short sentences, consistent names for services and no jokes, report fewer clarification pings in the incident channel. That anecdote matches common sense even if nobody has a tidy number for it.

Bringing the whole team in

Rolling this out is as much about people as about software. If you are still deciding how to introduce automation to your group, our guide on getting AIOps into an IT team smoothly covers the adoption side. Add one more step to it: ask the quietest members of the rota what slows them down. They often know exactly which screen, wording or colour choice has been costing them minutes for months.

A short, regular review works well. Once a quarter, take one real incident and replay it through the eyes of three different operators: someone on a phone, someone using keyboard only, someone reading in a second language. Note every hesitation. You will leave with a list of fixes that are small, cheap and obviously useful, which is rare in tooling work.

The same thinking outside the console

The idea is not limited to operations tools. Anything a business publishes, from a status page to a documentation site to a customer portal, benefits from being built for a wider range of people than the first mock-up assumed. Even web builders hold themselves to it: cmsGalaxy, a team that designs websites and handles search optimisation, lays out its own commitments in a public accessibility statement, a fair reminder that the standard deserves to be written down where visitors can read it.

Where this is heading

Expect the next generation of AIOps platforms to compete less on the cleverness of their correlation and more on how clearly they communicate. Vendors are slowly adding text alternatives for visual states, adjustable density, and message templates that read well aloud. Procurement checklists are starting to include questions about keyboard access and language support, which would have sounded odd five years ago.

For a team without a big budget, the practical takeaway is encouraging. Nothing here depends on your vendor’s roadmap. Audit your own alert wording, add words beside colours, write runbook steps as plain short sentences, and keep two ways to do the important things. Then watch what happens at the next 3 a.m. page. The engineer on the receiving end will not write you a thank-you note, but they will fix the problem faster, and that is the whole point.