Washington's panic button law is not a hotel law, and most people are reading it wrong

Washington's panic button requirement gets written up as hotel legislation. It is not. Read the opening of RCW 49.60.515:

"Every hotel, motel, retail, or security guard entity, or property services contractor, who employs an isolated employee…"

A "property services contractor" is a commercial janitorial employer. A "security guard entity" employs guards. So this is a lone worker statute that happens to include hotels, and two of the industries inside it are generally unaware of that.

Who counts as an isolated employee

WAC 296-137-010 defines it with an and, which is where most summaries lose the thread:

"An employee who: (a)(i) Performs work in an area where two or more coworkers, supervisors, or a combination thereof are unable to immediately respond to an emergency without being summoned by the employee; or (ii) Spends at least 50 percent of their working hours without a supervisor or another coworker present; and (b) Is employed by an employer as a janitor, security guard, hotel or motel housekeeper, or room service attendant."

Both halves have to be true. Four job roles, and nothing else. Labor and Industries says the same in plain words: the provision covers workers employed as janitors, some security guards, hotel and motel housekeepers, and room service attendants.

Two consequences people get wrong in both directions:

A retail cashier closing a store alone is not covered, however isolated they genuinely are. Retail appears in the employer list, but only its in-house janitors and guards are covered workers. The employer is in scope; most of its staff are not.

The employer list is closed. A hospital, mall, port or university that employs its own guards is not one of the five employer types named in the statute. If you have been told otherwise, ask where in the text that reading comes from.

The exemption that surprises the industry it exempts

WAC 296-137-050(10):

"(10) This section does not apply to contracted security guard companies licensed under chapter 18.170 RCW."

L&I's guidance repeats it in a footnote. So a contract guard firm, which is what most of this industry is, is exempt from the panic button provision. The chapter's harassment policy, training and resource list duties still apply. The button does not.

What remains squarely covered, with no exemption anywhere near it, is commercial janitorial. The named role is the entire business, every field employee is plausibly isolated, and there is no carve-out. If you run a janitorial contractor in Washington, this is your rule and it is not ambiguous.

We would add that the boundary between a "security guard entity" and a contracted licensed company is doing a great deal of work in that sentence, and it is a question for your counsel rather than for a vendor.

The location requirement is far more permissive than you have been told

This is where the vendor market has done the most damage. WAC 296-137-050(2), verbatim:

"Panic buttons must accurately identify the isolated employee's specific location. The location must be as specific as the work location necessitates to allow immediate assistance to be provided when an alarm is triggered. Employers may use different methods in order to pinpoint an employee's specific location including, but not limited to: (a) A schedule of where the isolated employee would be at a certain time; (b) An auditory alarm that also produces a signal to a responder; (c) An isolated employee providing status updates of their specific location as it changes; or (d) An isolated employee working in the presence of another worker."

Read (a) and (c) again. The location does not have to come from the device at all. A schedule satisfies it. A worker telling the system where they are, as it changes, satisfies it.

If you have been quoted a hardware package on the basis that the rule demands continuous positioning, the rule does not say that. It says the location has to be specific enough for help to arrive, and then lists four acceptable ways to get there, two of which are a roster and a schedule.

The signal rule is about coverage, not about technology

Subsection (4) is the one quoted at phone-based systems to disqualify them:

"(4) Effective signals must allow responders to accurately detect the isolated employee's location and distinguish it from other audible or visual alarms or noise without physical or electronic barriers such as poor cellular service or WiFi signals. The activation of one panic button must not obscure the activation of others."

That is an outcome requirement on the deployed system, not a ban on a transport. It does not say do not use Wi-Fi. It says poor Wi-Fi must not be the thing that stops the signal getting through. An employer with reliable coverage everywhere the employee works, on every shift, has no barrier.

L&I's own guidance confirms the reading by solving the coverage gap procedurally rather than technologically. Among acceptable ways to pinpoint an employee it lists:

"An employee working with a partner when there is a poor signal (parking garage, no WiFi available, etc.)"

If a technology were disqualified by poor signal, the remedy would not be "send two people".

The real constraint on a phone is activation

Subsection (6) is the one that should worry you, and it rarely gets quoted:

"A panic button will not be considered 'simple to activate' if it requires continued effort by the isolated employee to sustain a signal or if activation is delayed as in situations where the isolated employee must enter passwords, click through multiple screens or applications, or wait for the system to turn on."

A locked phone that has to be unlocked, with an app then found and opened, does not clear that. L&I says it again in the guidance: many off-the-shelf or consumer grade devices may not meet the effectiveness criteria for simple activation and reliability.

So the honest summary of Washington's device bar is: a phone alone is a weak answer to subsection (6), and a schedule is a perfectly good answer to subsection (2). The gap is activation, not location, and it is filled by something already in the worker's hand rather than by a positioning system.

What else the chapter wants

The button is not the whole obligation. The chapter also carries a sexual harassment policy, training, a resource list, and recordkeeping. That last one tends to be underweighted. Nobody audits intentions; they audit the log of who was alerted, when, and who responded.

On penalties, the amended rules have been in force since 1 January 2026, with the button requirement itself dating to 2020 and 2021. Willful violations run up to $1,000 each, rising for repeat violations within three years.

How AlertRoster maps onto this, and where it does not

Plainly, because an employer who finds out the limits after an incident is worse off than one who heard them first.

Where we fit. The escalation roster and the record are the parts of this rule that software is actually for: an alert that keeps working down an ordered list until a person acknowledges, and a log of exactly that. On subsection (2), our model is the schedule and status-update method the rule names. On subsection (6), a physical button press is the answer to "simple to activate", not a phone app.

Where we are a good fit, and where we are not. A guard post, a gatehouse, a leasing office, a single building or a care agency's premises are environments where the responding party knows the location because the location is the post. A large multi-floor hotel where the question is which of forty rooms is a harder problem, and one that needs room-level positioning we do not supply.

Where our limits are. There is no staffed centre at our company. Nobody here is watching your people. Alerts go to the roster you configure and escalate through your own team. We are not an emergency service. We contact one on your behalf only through automatic SOS on a Garmin inReach, which Garmin Response receives, and outside that we contact nobody but your own roster. We hold no life-safety certification. If a requirement obliges the device to summon police directly, we cannot serve it and we will say so in the first conversation.

And the sentence that ought to be on every vendor's page in this market: whether a given deployment satisfies "specific location" for your particular sites is a question for your counsel and your L&I contact, not for a salesperson. We can tell you exactly what our system does. We cannot tell you that it makes you compliant.

Working out whether this reaches your operation

The covered roles are narrower than the headlines and the device bar is more permissive than the brochures. If you employ janitors or in-house guards in Washington, it is worth half an hour to establish which side of the line you are on.

Book a call — 20 minutes, and you will leave knowing whether this fits, including if the answer is no.

Not legal advice

This article describes what a published statute or rule says. It is not legal advice, and it is not a compliance opinion about your operation. Read the cited text, and take your own counsel's view before you rely on any of it.

What AlertRoster is, and is not

AlertRoster is a call-out notification and escalation tool. It notifies people who have agreed in advance to be notified, and records what happened. It is not an emergency service. It contacts one on your behalf only when your organization has turned on automatic SOS for a Garmin inReach registered to you: if you miss a check-in while your phone has no signal, the AlertRoster app declares an SOS on that inReach, and Garmin Response, Garmin's emergency coordination service, receives it under your organization's Garmin plan. It is not a fire alarm, a security alarm, or an alarm monitoring service, and it holds no life-safety certification. It is not a replacement for your team's official paging arrangements, and it should not be the only way a call-out can reach your people.

Sources reviewed October 2026. Statutes and rules change; if you are reading this long after that date, check the current text.

About the author

Jim Hankins is the founder and CEO of Cloud Bedrock, LLC and the developer of AlertRoster, which he first launched in 2009. A US Army combat veteran and a 42-year veteran of IT and software development, he has spent much of his career building emergency communications platforms, including as CTO of GEOS, the international emergency response coordination service later acquired by Garmin.