Trust-Centered Alerts for Platform Reliability

Context

System issues on Cordial's marketing platform disrupted client communication, leading to missed engagement opportunities and real revenue risk for marketers. Without proactive alerting, users had no visibility into workflow disruptions until it was too late to act. The objective was a system that notified users of upstream issues early enough to actually do something about them, not just log that something went wrong.

Problem

Users had stopped trusting the thing meant to warn them, so they turned it off. Three failures compounded into that: excessive false alarms trained users to disable notifications entirely; a manual check process for the metrics that mattered was tedious and time-consuming; and users overwhelmingly preferred Slack over email, which had become unmanageable as an alert channel.

Process

Research: I ran a short survey through Pendo to understand how important different platform alerts were to users. 9 of 86 users took the survey, and 3 confirmed to meet for more discussion.

Automations, Integrations, and Data Jobs came back as the highest alerting priorities. On the use-case side, Defaults, AI Anomaly detection, and KPIs led.

A few things stood out enough to shape the direction directly. Automations and Integrations scoring high wasn't a surprise, it validated that users want to know when something silently turns off. Audiences scoring as high as it did was more interesting, and worth understanding further in the follow-up interviews. Defaults and KPIs scored lower, but low enough that I still wanted to validate them directly rather than assume.

Strategy: I aligned product and UX around one set of goals instead of letting them drift apart. Product needed faster awareness for clients, higher feature adoption, and a fix for the blank-slate problem. Users needed to understand and act on alerts, set them up once, and loop in coworkers. From there I sorted every requirement into must-have (a central place to monitor alerts, sensible defaults for high-traffic areas), nice-to-have (daily report vs. immediate send, sending to a list of internal users instead of typing emails manually), and delightful but not required (a webhook channel, alert priority, AI detection before an asset hits a critical state).

Design: Five alignment principles anchored the solution: a central location for all alerts organized by channel, control over when and who receives them, straightforward rule comprehension, a history tab for previously triggered alerts, and a custom alert-rules tab for asset-specific rules.

Feedback: I walked the design through with real clients to pressure-test it against actual, conflicting needs. Bootbarn wanted the ability to set alerts on specific KPIs. Virgin Voyages wanted custom alert rules placed at the individual asset level instead of globally. Planet Art didn't want a reminder or an immediate ping at all, they wanted a daily alert summary.

Three different asks, and the answer wasn't three different features. It was one system with defaults and per-asset overrides, so every client could get what they actually needed without forking the design.

Solution

Two primary pieces. A notification feed tracking triggered events with error badges on critical assets and direct navigation to the problem:

And global alerts, letting users set defaults per asset type, route alerts to internal groups, choose immediate or daily delivery, and see history beyond the feed's window:

Outcome

Shifting priorities meant the project didn't ship end to end, but it established a scalable alerting framework that outlived the deadline. I built the feed and rule-building components deliberately lightweight, so they'd be easy to iterate on and extend, and they became the foundation the next version of alerting was built on.