Skip to content
Philip Hussein
← All work

Alarm Inbox · Schneider Electric

340 alarms a day, and the one that mattered was number 212.

Turning hundreds of building alarms a day into a short list of incidents. Related alarms are grouped, ranked with a reason, and muted only with an expiry date and a note.

Role
Digital Product Lead
Company
Schneider Electric
Timeline
2024 to 2025
Team
1 designer, 1 PM, 5 engineers, 1 data scientist
Platforms
Web app, Microsoft Teams, Mobile push

123 downstream alarms collapse into one incident

2Every priority shows the reasons behind it

3Snoozes end on their own, with a logged reason

340 → 41

Alarms a day, now grouped into incidents

−62%

Time to acknowledge a critical incident

0

Critical alarms missed during the pilot

100%

Muted rules with an expiry date and a reason

The problem

Operators received about 340 alarms a day per site, and roughly 80% of them were noise. They muted alarms permanently to cope, and critical ones got lost in the list.

What I did

Picking up where Atlas Copilot left off, I redesigned the alarm list around incidents: related alarms grouped under a root cause, ranked by a model that has to explain itself, with mute rules that always expire and a handover between shifts.

What changed

The same alarms now arrive as about 41 incidents a day. Time to acknowledge a critical incident fell by 62%, and no critical alarm was missed during the six-month pilot.

01 · Context

The problem operators kept telling us about.

During the Atlas Copilot research, operators told us again and again that their biggest problem wasn't finding answers. It was alarms. A large site produced about 340 a day, and most of them were consequences of the same few events. One chiller trip at 2 a.m. could cause two dozen alarms across pumps, air handlers and every floor it cools.

After Atlas launched, I proposed Alarm Inbox as the next bet. It used the same data, the same team and the same answer pattern, pointed at the problem operators had ranked first.

00
04
08
12
16
20
Mon
Tue
Wed
Thu
Fri
Sat
Sun
Few alarmsMany alarms
Fig. 1Alarms per two hours at one hospital site over four weeks. Morning start-up and evening setback produce most of the noise.

02 · Problem

Everything was urgent, so nothing was.

The alarm list sorted by time, and every alarm looked the same. Operators coped by muting whole categories, often permanently, and by keeping a paper list of 'alarms we ignore'. In one review, a site had 140 permanent mutes, some older than the operators who created them.

Fig. 2The same chiller event, before and after: 24 alarms in time order, then one incident with the root cause and three groups of related alarms.

The question we worked on

How might we show operators the few events that need them, while making sure nothing important can be hidden by accident?

03 · Research

What happens on a night shift.

I spent two night shifts in hospital control rooms, interviewed 16 operators and shift leads, and analysed 1.8 million alarm events with our data scientist to understand which alarms belonged together.

Insight 1

Alarms come in families

In the event data, 74% of alarms happened within ten minutes of a related alarm on connected equipment. Grouping them was possible with plain rules plus the building's equipment model.

“When the chiller goes, I know the next twenty alarms already.”

RuudNight operator, hospital
Insight 2

Muting is how people survive

Operators weren't careless. They muted because the system gave them no other way to cope. Mutes just never came back.

“I mute it to get through the night. Then I forget I muted it.”

YvonneShift lead, office campus
Insight 3

Handover is where things get lost

Night and day shifts swapped notes verbally or on paper. Half of the incidents we traced had been seen by someone who didn't pass it on.

“Did anyone tell you about AHU-3? No? It's been doing that since midnight.”

MehmetDay operator, hospital
Alarms per day
340
After grouping into incidents
88−74%
After expiring mutes and known faults
41−53%
Needing action within an hour
6−85%
Fig. 3What happens to a typical day's alarms in the new model, measured on four pilot sites.

04 · Process

Same team, same pattern, new problem.

Month 024681012
Night shifts, interviews
Grouping rules with data
Priority model
Inbox and incident design
Mute rules and handover
Pilot, 4 sites
◆ Bet approved◆ Pilot starts◆ Rollout decision
Fig. 4Twelve months, mid 2024 to mid 2025.
Option ARejected

Smarter filters on the old list

Quick to build, but operators still had to recognise that 23 alarms were one event.

Option BRejected

Fully automatic suppression

Safety and compliance teams wouldn't accept a system that hides alarms on its own in hospitals.

Option CChosen

Incidents with reasons, mutes that expire

Groups and ranks alarms, explains the ranking, and only hides something when a person says so, for a set time.

Fig. 5Three directions reviewed with operators and the hospital safety team.

05 · Design decisions

Incidents, reasons and expiry dates.

One incident per event, with the root cause on top

Related alarms collapse into an incident. The first alarm in the chain sits on top as the likely cause, and the rest are grouped by type. Operators can always expand to see every raw alarm, which was important for trust and for compliance.

  1. 01Raw alarms24 in 9 minutes
  2. 02Equipment modelWhich assets are connected
  3. 03GroupSame event, same chain
  4. 04RankModel plus building rules
  5. 05Incident1 card with root cause

The two steps operators used to do in their heads

Fig. 6How raw alarms become an incident.

The ranking always shows its reasons

A priority without a reason is just another number to ignore. Each incident lists why it's ranked where it is: what the equipment serves, how many zones are affected, and whether something similar happened before. If an operator thinks the ranking is wrong, one click records that for the data team.

Critical

Act now

Serves an operating theatre and 3 zones are above 26 °C.

High

Within the hour

Supply temperature drifting, comfort complaints likely by 10:00.

Normal

Today

Meter offline. Data will backfill when it reconnects.

Known

Muted until Fri

Filter replacement ordered, WO-22191.

Fig. 7Priority levels with the kind of reason each one shows.

Mute rules always expire and always have a note

We didn't take muting away. We made it safer. Every mute needs a reason and an end time, with quick presets for 'one hour', 'end of shift' and 'until Friday'. The rule shows how many alarms it will hide before you save it, and every rule is kept in an audit log.

Fig. 8Creating a mute rule. The preview says how many alarms it would hide.

Handover is part of the product

At the end of a shift, the inbox builds a handover: open incidents with the operator's notes, what was resolved overnight and which mutes expire today. The next shift starts by reading it, and the incoming operator's acknowledgement is logged.

Fig. 9The night-to-day handover at a hospital pilot site.

06 · Outcome

Fewer things to look at, faster response to the ones that matter.

Median time to acknowledge a critical incident
0 min8 min15 min23 min30 min
Pilot starts
M1M3M5M7M9M11M12
Fig. 10Median time from a critical alarm to acknowledgement across the four pilot sites.
Before the pilot After 6 monthsLower is better
Items in the list per day
340
41(-88%)
Permanent mutes per site
140
0(-100%)
Incidents not handed over
31%
4%(-87%)
Fig. 11Averages across the four pilot sites.

“It finally looks like what actually happened last night.”

RuudNight operator, hospital

“I can see every mute, who made it and when it ends. That's what we needed for the audit.”

IngridFacilities safety manager
Fig. 12From the pilot review.

07 · Reflection

What I learned.

Good AI features are often about taking things away. The model behind Alarm Inbox is simple, and most of the value came from grouping, explaining and expiring, which are design decisions as much as data ones.

I'd bring the safety team in even earlier. Their 'no automatic hiding' rule shaped the whole product, and it made it better.

Tools on this project

Figma, FigJam, Python notebooks, Jira, Dovetail

Names of the people quoted have been changed to protect their privacy.

Next projectSchneider Electric

Commissioning Assistant →