Why It Matters to Me
Opt-in and opt-out management sounds simple until you're actually responsible for it. As a PM for Workday's messaging platform, consent and quiet hours were problems I dealt with constantly — and they were harder to solve than most people expect. When does a user's opt-out apply to all messages, or just a category? What happens when quiet hours overlap with an urgent notification? How do you show customers what the logic actually looks like before they build against it?
I explored how competitors handle consent collection and Courier's approach really stood out — it was one of the few products treating notification preferences as a first-class product problem. ChannelIQ is partly inspired by that, but I wanted to go further: not just collect preferences, but simulate exactly how those preferences change what a user receives across every channel.
This is the tool I would have wanted to show customers when they asked how opt-in logic works. Now it exists.
Problem It Solves
Notification preference management is a genuinely hard product problem that most platforms underinvest in. Companies collect consent without fully thinking through the downstream logic — what happens when preferences conflict, when channels are unavailable, or when regulatory requirements override user settings.
Opt-in and opt-out logic is complex but rarely made visible to the teams building against it
Quiet hours, channel availability, and regulatory rules all interact in ways that are hard to reason about
Most consent UIs collect preferences without simulating what those preferences actually produce
Teams building notification systems need a reference model for how this logic should work
What I Built
Preference engine — configurable opt-in and opt-out settings per channel (SMS, email, push, in-app) with quiet hours and frequency controls
Real-time routing simulation — shows exactly how a message would be delivered based on the user's current preferences, channel availability, and routing logic
Multi-user profiles — switch between different user profiles to see how preferences change routing outcomes
8-preset scenario system — pre-built scenarios including TCPA and GDPR regulatory presets to demonstrate compliance-aware routing
Decision tree animation — visual walkthrough of how the routing logic evaluates each channel in sequence
Channel-specific previews — see what the message looks like on each channel before it routes
What I Learned
A great demo idea isn't always a standalone product
ChannelIQ works well as a demonstration of how notification preference logic should function. But the more I thought about it, the more I realized the real version of this isn't a product — it's an API. The preferences and routing logic need to live inside whatever platform holds the user's profile. ChannelIQ on its own has nowhere to persist that data. That's a meaningful product architecture insight.
Showing the logic is more valuable than hiding it
Most notification systems treat routing logic as an implementation detail. What I learned from building this is that making the logic visible — through simulation and animation — is actually a better product experience for the teams building against it. Transparency in infrastructure products builds trust.
Inspiration is a starting point, not a destination
Courier's consent UI was the spark. But building my own version forced me to think through edge cases and interaction patterns that go well beyond what inspired it. The act of building always reveals things the reference product didn't need to solve.
Where It's Going
NOW
Maintained as a live demo — no active feature developmentLATER
The real version of this is an API, not a UI — if this concept grows, that's the direction