ServiceNow Event Management for Hospitality

Guest Experience Monitoring

Event Management in a hotel group deals with the signals a property’s systems and facilities emit: equipment failures, temperature control and utility alerts, network and property-system availability alerts, and security system alerts. The sections below cover how guest-experience, facility and safety events are classified and routed, who is notified and how escalation works, what preventive insight the event stream offers, and then the working decisions: which facility signals become events, how raw alerts become one actionable alert, how to bring a property’s signals under control, and when event management is the wrong place for a problem.

The systems that emit signals in a property estate

A hotel group runs far more monitored equipment than its guests ever see. Building management systems report on chillers, boilers, air handling units and pumps. Leak sensors sit in plant rooms and under guest bathrooms. Door and access control panels log faults as well as openings. The network and guest Wi-Fi are monitored for availability and load, and the property management system, point-of-sale terminals and payment gateways are monitored for response and uptime. Each of these sources already produces events; the work of Event Management is to receive them in one place, decide which deserve attention, and attach them to the systems and services they affect so that the people on duty understand what a signal means for the property.

How a signal becomes an alert

Events arrive through connectors or listeners from the monitoring tools and controllers, carrying the source, the metric, its value and a timestamp. Event rules read those fields and bind each event to a configuration item: a named chiller, a switch stack, the property management server. Rules also set the severity and decide whether an event is informational, worth an alert, or part of an alert that is already open. The alert is the unit people act on. A guest complaint about a cold room is not an event in this sense; it is a case or an incident raised by a person. The link between the two is made when the duty engineer sees that the alert on the air handling unit serving that floor was open before the complaint arrived.

Classifying alerts by the service they threaten

Classification in a hospitality estate works best by the guest-facing service behind the equipment rather than by the equipment alone. A chiller alert matters more when it serves guest floors than when it serves a storeroom. A network alert matters more during check-in hours. Map each monitored item to the services it supports (guest rooms, food and beverage, events space, back office, payment) in the configuration management database, so that an alert inherits a service context and a priority from that mapping instead of from a guess. Alerts on items with no service mapping are a sign that the model is incomplete, and the engineering lead should treat them as a backlog.

Routing alerts to the people on duty

Properties run through the night with thin staffing, so routing has to be explicit. Alert management rules assign each alert to a group: engineering for plant and water, IT for network and property systems, security for access control faults. An on-call schedule kept in the platform decides who in that group receives the alert out of hours, and the schedule changes when the rota changes, not when someone remembers to update a whiteboard. Acknowledgement is part of the route: an alert that is not acknowledged within the agreed time moves to the next person in the chain and then to the duty manager, and the record shows each hand-off.

Connecting alerts to the guest impact they cause

The value of the event stream to the front of house is advance notice. When an alert on the hot water system opens, the duty manager can expect complaints from the floors it serves and brief reception before the first call. When the payment gateway alert opens, the restaurant can switch to its fallback before a guest is left waiting at the till. Build that link deliberately: give the duty manager a view of open alerts by service and property, and let a case raised by a guest reference the alert that explains it, so the engineering team sees how many guests one fault reached.

What the event stream teaches over time

A season of alert history shows which assets fail most, which thresholds produce noise and which properties generate more alerts than their size explains. A chiller that trips every warm afternoon is a maintenance or sizing question, not a monitoring one. Repeated network alerts at the same time each day point at a scheduled job or a backup window. Review the history with the engineering lead each cycle and turn the recurring patterns into planned work, so that the stream shrinks because the faults were fixed rather than because the thresholds were loosened.

Challenges particular to hospitality estates

Volume is the first challenge, because building controllers report continuously and a group with many properties can produce far more events than a small operations team can read. Ownership is the second, because the systems belong to different teams and often to different vendors, and a vendor’s own monitoring console is rarely the place the night engineer looks. Variety is the third, because each property has its own mix of equipment, controllers and integration methods, so a rule that works at one site does not transfer unchanged. The sections that follow set out how to decide which signals earn an event, how repeated events become one alert, and how to bring one property under control before extending to the next.

Deciding which facility signals become events

Hospitality building systems produce far more signals than anyone can act on. A chiller reports a temperature drift every few minutes, a door sensor logs every opening, and a meter reports consumption continuously. Turning all of that into events can bury the operations team. The useful question for each source is whether a person or a system will act on the signal, and how fast. The table sets out a working split.

Turning raw alerts into one actionable alert

A flapping sensor can generate many events in an hour. Event rules and alert correlation exist to collapse those into a single alert per problem. Group events by the configuration item they describe and by the metric that changed, so a repeated temperature reading on one chiller updates one open alert rather than opening many. Use a time window to decide when a new reading belongs to an existing alert and when it is a fresh fault. Suppression is useful during planned maintenance, but every suppression needs an owner and an expiry, or it becomes a blind spot.

Bringing a property’s signals under control

1. Inventory the building signals at one property with the engineering lead, and mark which ones have a named response owner.
2. Remove signals that nobody will act on, and send them to a report instead of the event stream.
3. Set the threshold for each remaining signal with the engineer who maintains it, and record why that threshold was chosen.
4. Group related events by configuration item so one fault produces one alert.
5. Test the on-call route with a planned event out of hours, and confirm the right person receives it.
6. Review the alert volume after a full operating cycle and adjust the rules before extending to another property.

Quiet hours and the on-call chain

Guest-facing properties run through the night, but night staffing is thin. Define which alerts may wake a person and which wait until the morning. A failed water heater serving guest showers is a night alert. A monthly energy variance is not. Make sure the on-call rota is kept in the platform rather than on a whiteboard, so a change of engineer updates routing automatically.

Comparing the ways an alert can be treated

Signs the event stream is under control

• Many alerts are acknowledged by the person who owns the asset, not by whoever is nearest a screen.
• Each open alert has an age, and the team can explain any that have been open for longer than expected.
• Suppressions list their owner and expiry date, and none have passed the expiry without a review.
• Engineers recognize the alert volume at each property as normal for that building.

When event management is the wrong place

Life safety signals must follow their own procedure. A fire alarm panel and its detection devices are governed by the building’s fire safety arrangements, and the response is set by that procedure, not by a platform event rule. The platform can record a mirrored event for the record, and it can show the duty manager that an alarm occurred, but it should not be the path that decides whether the fire service is called. Likewise, a building that has no monitored signals at all gains little from an event platform until the sensors are installed.

Should every building sensor create an event?

No. A sensor earns an event when a named person can act on its signal within a stated time. Everything else is better as a trend report, because events that nobody acts on can train people to ignore the stream.

How do we handle a sensor that keeps flapping?

Treat the flapping as a fault in its own right. Open an alert for the sensor, let the grouping rule collapse its repeats, and have the engineer check the sensor’s mounting, its power and its threshold before the reading is trusted again.

Who owns the suppression rules?

The engineering owner of the asset should approve each suppression, and the operations lead should be able to see every active one. A suppression created by a vendor during commissioning should be reviewed before handover, because vendors often do not remove their own temporary rules.

For the platform side, see the event management page. Related pages: the event management implementation page and the note on reducing alert noise.