CASE STUDY · PAYPAL · 2019-2024
The Notification Overload Problem
How I made a diffuse, ownerless trust problem visible, then built the governance that kept it solved after I left.
How do you fix chaos, information fatigue, and mistrust on an ephemeral and rogue surface?
We heard a user research participant complain that a new package tracking feature released during Covid wasn’t great, so far. Being forced to log in to the app and seek out the info wasn’t providing her value. She was surprised to see she was opted into these alerts from PayPal, but wasn’t tracking them because they disappeared in a cloud of competing messages from every app on her phone. We had myriad teams simultaneously competing to talk to customers in every channel we had: red dots everywhere via push notifications, in-app messages, email, badges, lifecycle marketing, credit alerts, fraud alerts, promotional offers. Each team owned a single communication stream and answered for a single set of metrics, yet no one was watching what one customer received across all of them.
The effect was hard to see, but predictable in hindsight. Customers, especially in the early life window where trust is still forming, were getting overlapping outreach from sources that never coordinated, at a volume no single team felt responsible for.
THIS WAS A SHARED SURFACE WITH NO OWNER
The PayPal Home/Dashboard team I owned was used to calculating how the accumulation of multiple products defined the customer gestalt experience. "All of the communications sent to a customer" was not owned by a single team, it had a tangible effect on customer trust. This was a problem I could solve.
The work came together in three parts, built in order: first the evidence, then a council to set the rules, then an engine to run them.
1 · The audit
A few of us could see the issue, but funding real research took money no one had set aside, and without evidence there was no case for change. Evidence isn't always free, so I got scrappy. I did an informal audit and cobbled together what info I could, then with no budget and no team to spare, I worked outside my lane to pull together about $100k by shaking the sofa cushions for scraps from product leads who had come to trust me. With it I brought in an outside research firm to run a secret-shopper audit of the product's full blended communication footprint. They moved through the product the way a new customer would and logged every notification, every email, and every in-app prompt across onboarding and early life.
That report did what design intuition never could on its own. Once the evidence came from outside and sat on paper, it stopped reading as a design preference and started reading as a shared risk that leadership across functions had to answer for.
2 · The Communications Council
With evidence in hand, I proposed and convened a cross-functional Communications Council drawn from product, marketing, legal, and content strategy to create the rules normalizing how each type of message was treated. They worked through every kind of communication and typed it along a few axes: urgency, regulatory, priority, actionability. and others. They mapped the output channels, push, SMS, email, and various app badges (on page, alert bell, app icon), then wrote the routing rules, including fallbacks for when a chosen channel was blocked, since a customer who had declined push still needed a regulatory notice to reach them somehow. Any new message type was checked against the existing rules or given new ones, and over time anything a team wanted to send was routed through the council first.
3 · The routing engine
The engine ran those rules. It handled timing, holding most messages in a per-customer queue and releasing them gradually, while letting a higher-priority type jump the queue and go out sooner.
It also kept the system open to oversight. The council could sample a single anonymized customer's stream to see how the rules were landing in practice. No PII, but enough account context to judge it: balance positive or owed, account age, number of products in active use, login frequency.
The most useful output was organizational structure and process improvements, not pixels.
After seeing evidence and proposal, the organization bought into the structure and committed resources to build the rules based routing engine. The committee was enthusiastic about the framework which held because it lived in process rather than in any one person. After I moved on, the intake funnel and the committee kept running.
Centralized intake
One process for every notification request across the platform, built from nothing.
Centralized Cross-functional reviews
A committee that weighed each request against the customer's total communication load, with no team approving its own channel alone.
Customer attention and trust
Qualitative research evaluating how PayPal communicated with it's customers showed almost 30% improvemement. This translated into fewer unsubscribes and notification opt-outs.
Keep the evidence fresh.
It isn’t clear that the rules-based prioritization is still happening. I left a functioning committee, rules, and an engine, but the full organization must be all in to stay vigilant. In uncertain economic times with lower staffing levels, it may be attractive to “bend” the rules to goose revenue short term where needed, but this will damage customer trust long term.
THE LESSON
Building the governance was the right move. Pairing it with a standing external re-audit would have made it more durable, because external evidence is what gave it authority in the first place.
WHAT IT PROVED
Credibly surfacing a diffuse, ownerless problem enough for an organization to restructure and engineer around it is doable, but not easy. Unorthodox methods work well when deployed with precision.