Envoy Emergency Notifications
The Problem
When Envoy prepared to launch Envoy Workplace — a new product tier bundling its physical office tools — the initial plan was straightforward: repackage existing products into a single SKU. My PM and I pushed back on that.
In regular calls with enterprise admins, we kept hearing the same thing: a repackaging meant workflow disruption without meaningful new value. Admins weren't excited. So instead of designing for the bundle, we listened for the unmet need underneath it.
It surfaced quickly. Nearly every admin had a cobbled-together workaround for emergency communication — mass emails, PA systems, chain-texting team leads. None of it worked reliably. And none of those tools knew what Envoy knew: exactly who was on-site, at which location, right now.
I proposed we build a net-new Emergency Notifications feature to anchor the Workplace launch — something genuinely valuable that admins didn't already have, made possible by Envoy's unique presence data. The PM aligned, leadership greenlit it, and we shipped it across 8 milestone releases in 3.5 months.
It became the reason admins said yes to Envoy Workplace.
My Role
Sole Product Designer
Worked with a team of ~6 engineers to implement
Project Timeline
3.5 months
Responsibilities
User Research
User Story Mapping
Interaction Design (mobile & web)
Usability testing
Cross-team collaboration with Visitors team
Research + Discovery
I ran monthly feedback calls with enterprise admins — a standing cadence I maintained throughout my time at Envoy. Emergency communication came up repeatedly and unprompted. The pattern was consistent: admins had cobbled together workarounds (mass emails, PA systems, manually texting team leads), but none gave them confidence that the right people were actually reached.
Three insights shaped the entire design direction:
1. Speed and reach matter more than richness. In an emergency, admins don't need formatting options or threading. They need to know a message went out immediately, to everyone who needs it.
2. "Who's actually here" is the hard part. Other tools require admins to manually maintain distribution lists. With Envoy's check-in data, we could make that automatic and accurate.
3. Trust is fragile. Early in testing, employees were suspicious of unknown SMS senders. If people don't recognize or trust the source, they ignore it — exactly the failure mode we were trying to prevent.
Planning: User Story Mapping Across 8
To scope the feature and deliver value quickly, I created a user story map based on the most urgent needs we heard from enterprise admins. I broke the work into five milestone releases, starting with the simplest version: sending SMS alerts to employees. Each milestone added meaningful functionality while minimizing risk—such as support for visitors, delivery logs, alternate delivery methods like push and email, and ways to ensure admins had complete contact info for all recipients.
Milestone 1 - SMS to Employees Only
The first release was intentionally minimal: one message type (SMS), one audience (on-site employees), two entry points. I added a send trigger via the "+" in the mobile home header and a secondary link under "More to Explore" — both low-friction, accessible in a high-stress moment.
The web admin side surfaced as a new rail item with a simple compose flow. Critically, the confirmation step showed a live count of employees who would receive the message, drawn from real-time check-in data — this was a key differentiator from any existing tool.
Milestone 2 - Extended to Visitors
Adding visitors introduced cross-team complexity. Visitor data lived in a separate product domain, which meant I had to collaborate closely with the Visitors team to surface visitor counts in the send flow and ensure the experience was consistent across both employee and visitor-facing surfaces.
This milestone also introduced the first version of audience segmentation UI — letting admins choose to send to employees, visitors, or both.
Milestone 3 - Sent Log
Admins needed to know: did it work? Who got it? The sent log was the answer — but it had nuance. On initial release, we shipped a basic log as a temporary solution while we planned the more robust version. Within one release cycle, feedback made clear that search and filter were table-stakes.
I also recognized early that this log would need to scale as we added more delivery channels — so I started asking admins forward-looking questions about what they'd need to see once push, email, and two-way comms were in the mix. That foresight shaped the log's data model before it got complicated.
Two edge cases required dedicated design attention: the empty state (no notifications sent yet) and the error state (sent to no one — e.g. if no employees were checked in). Both needed to communicate clearly without causing panic.
Milestone 4 - Push Notifications + Email
This milestone significantly expanded the feature's reach — adding in-app push and email alongside SMS. It also introduced one of the more interesting technical constraints of the project: we couldn't reliably calculate recipient counts for all channels in real time, which had been a key part of the send confirmation UX.
Rather than block the milestone, we made a deliberate tradeoff: show counts where we could, remove them from the send button where we couldn't, and document it as a known gap to revisit. I also designed the settings surface in the Envoy admin dashboard, where admins could configure which channels were enabled.
We also added a "sent by" signature to messages at this milestone — a direct response to the trust problem surfaced in early research. Employees receiving an unexpected SMS needed to immediately recognize it as legitimate.
Milestone 5 - Banner Improvements + Bottom Sheet
Two refinements that sound minor but had real impact on admin confidence. The emergency banner that appeared on the employee-facing homepage had gone through multiple iterations — we'd gotten feedback that it wasn't urgent-feeling enough, and that admins wanted a clearer visual signal that something was active.
The bottom sheet on the sent log was a UX improvement that gave admins quick-access detail without navigating away from the list — useful when monitoring an ongoing situation.
Milestone 6 - Phone Number Prompting
SMS only works if you have phone numbers — and we didn't have them for most employees. This milestone was about closing that gap without creating a bad employee experience.
I designed a lightweight prompting system: a configurable banner on the Envoy homepage and app that nudged employees to add their number, plus updates to the employee profile screen on both mobile and web. The admin side got a new dashboard view showing coverage — what percentage of employees had phone numbers on file — so admins could see their exposure before an emergency happened.
This required close coordination with the Envoy app team and careful attention to the prompting tone: urgent enough to drive action, but not alarming in a way that would cause confusion about whether something was already happening.
Milestone 7 - Two Way Comms + Custom Audiences
This was the most complex milestone. Two-way communication meant employees could now reply to an emergency notification — enabling admins to get real-time status updates ("I'm safe," "I need help") rather than just broadcasting outward.
Custom audiences let admins define and save specific groups — by location, team, or other attributes — rather than always sending to everyone on-site. This was a significant UX challenge: audience creation had to be fast enough to use in a real emergency, while powerful enough to be worth the added complexity.
I also explored resending to previous groups, which addressed a real use case: a multi-stage emergency where you want to follow up with the same audience without recreating the selection.
Milestone 8 - Templates + Phone Number Collection at Check-In
The final milestone addressed two gaps that had emerged across all the previous releases. Templates let admins pre-write common emergency messages (evacuation instructions, shelter-in-place language, all-clear notices), reducing cognitive load in a high-stress moment when composing a message from scratch is the last thing you want to do.
Phone number collection at check-in — built in collaboration with the Visitors team — extended coverage to visitors, asking for a phone number as part of the standard sign-in flow rather than relying on admins to prompt separately.
Impact
Envoy Workplace hit $4M ARR with 350 paid customers within 6 months of launch, and grew to $10M in the first year. It became Envoy's most widely-used product SKU almost immediately after release.
Emergency Notifications was the feature that made the launch compelling. We surpassed our activation KPI — 10% of enterprise customers onboarded — before the formal launch even went out. Admins who had been lukewarm on the Workplace rebundle signed on specifically because of this feature.
The project also validated a broader principle: that the most valuable thing a designer can do at a repackaging moment isn't polish the container — it's listen hard enough to find what should go inside it.
What I learned
Real-time data is only valuable if it's trusted. The "sent by" signature felt like a small detail — it wasn't. User trust in the source of an emergency message is load-bearing. I would have designed for that explicitly from M0 rather than retrofitting it.
Designing for high-stress moments requires a different standard. Every interaction — the entry point, the confirm screen, the send button — had to work for someone who is panicking. That raised the bar on clarity and reduced my tolerance for anything clever or non-obvious.
Scope decisions are design decisions. Choosing to remove recipient counts from the send button rather than block M0.75 was as much a design call as any screen I produced. Knowing when not to build something is part of the job.
