> ## Documentation Index
> Fetch the complete documentation index at: https://notifizz.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Notification Platform for the Whole Team
> Notifications need three jobs done together — Marketing intent + Dev events/enrichers + Product QA/measure. Marketing-only platforms hide the dev half and ship an AI blind to it.
# Why the whole team
Most notification platforms are built for one team. Customer.io, Braze, Iterable — Marketing's tools, with engineering as the data-pipe operator. Knock, Novu, Courier — engineering's tools, with marketing as the ticket originator. Both work; both create a wall between the two halves of the work.
The wall is wrong, and it's wrong in a particular way that AI makes visible.
## What we believe
Building a good notification requires three jobs done together — Marketing decides intent and copy, Dev wires events and enrichers, Product decides what success looks like. Splitting them across two platforms (or two teams who don't see each other's work) costs every campaign a translation tax. Putting them on one platform isn't just nicer to use — it's the only way the AI gets enough signal to actually help.
## The status quo
| Platform | Audience | What gets hidden |
| ------------------------------ | ----------- | ----------------------------------------------------------------------------------------------------------------------- |
| Customer.io / Braze / Iterable | Marketing | The events, the enrichers, the actual delivery code — all "engineering's problem", visible only as a sync configuration |
| Knock / Novu / Courier | Engineering | The campaign's intent, the copy variants, the success criteria — all "marketing's problem", visible only as a ticket |
The wall between the camps is implicit but consequential. Marketing-only tools assume engineering is a service provider; engineering-only tools assume marketing is a requirements provider. The platform's UI reflects the assumption; the team's coordination cost reflects the assumption back.
When AI lands in either camp, it inherits the partial view. AI in Customer.io can see segments and copy; it can't see the orchestrator code. AI in Knock can see types and APIs; it can't see the campaign's intent. Either way, the AI is **blind to the other half** — which is the half it would need to actually unblock the team.
## The Notifizz alternative
One platform. Marketing, Dev, and Product all author and review here:
* **Marketing** sees the campaign editor — description, channels, copy, preview.
* **Dev** sees the orchestrator code, the events catalog, the enrichers, the activity log of who proposed what.
* **Product** sees the funnel, the deliveries, the dev tasks, the activity feed.
The AI sees all of it. That's the point.
When Marketing describes a campaign, the AI reads:
* Marketing's description.
* The event catalog Dev has registered.
* The enricher catalog Dev has registered.
* The variable catalog Marketing has defined.
* The brand and the templates.
It produces an orchestrator that's grounded in *this* organisation's primitives. Not a generic "what would a reasonable orchestrator look like" — but "here's what your orchestrator looks like, given what you've registered". The first is fluffy; the second is actionable.
## Honest scoping
The platform doesn't pretend the dev half doesn't exist. When the AI proposes orchestrator code that needs a primitive nobody's registered, the dashboard surfaces a **dev task** — explicitly, with names attached. "This campaign needs an enricher called `fetchSubscriptionPlan`. Marketing tagged Dev. Dev: please register or push back."
That's the trade Notifizz makes against the marketing-only narrative. Customer.io would never tell Marketing "this needs Engineering". Notifizz does — when it does, and only when it does. Marketing's autonomy is genuine *because* the gate appears only on the work that genuinely requires Dev. For the 90% of campaign work that doesn't, the AI ships the orchestrator and Marketing reviews. For the 10% that does, the dev task names the gap and the work happens visibly, in the same platform.
The alternative — pretending the 10% doesn't exist — sets Marketing up to discover at QA time that the platform can't do what they wanted, and then the four-week ticket loop reopens. Worse: it's been hidden until the schedule is at risk. Notifizz makes the 10% visible upfront; the cost shows up early, when it's cheap to address.
## Shared review surface
Every campaign change goes through one place: the campaign detail's [activity log](/docs/concepts/activity-log) tab. Edits, AI proposals, comments, status promotions, dev-task resolutions — all in one feed, all with actor names and timestamps.
This unifies the audit trail. Marketing can see "Dev approved my campaign at 3pm Tuesday". Dev can see "Marketing changed the copy after I shipped the orchestrator". Product can see "this campaign was promoted to Live by X without QA's signoff" — and intervene before customers see the result.
Other platforms have audit logs. Notifizz's is per-campaign, with all three jobs feeding into it, because the three jobs happen on the same surface. That coherence is what the AI consumes when it generates the next iteration.
## The AI argument from team visibility
The strongest case for whole-team is functional, not philosophical: **AI quality scales with the data it can read**. AI on a marketing-only tool sees marketing intent and synced data. AI on an engineering-only tool sees code structure and types. AI on Notifizz sees both — plus the activity log, plus the dev tasks, plus the variable catalog.
The output difference is large. Marketing-only AI proposes copy and segments; engineering-only AI proposes types and signatures. Notifizz AI proposes complete campaigns that ground in your team's actual primitives — because it can read those primitives.
This isn't an aesthetic preference for unification. It's the precondition for AI that actually changes who does what.
## But what about…
They don't have to. The Marketing-facing surface — campaign editor, preview, copy, channel choice — doesn't expose orchestrator code by default. Marketing sees the campaign at the level they care about. The orchestrator code is one tab away if they want to read it; it's read-only for non-engineering members of the team. The AI handles the translation; Marketing reviews the outcome, not the code.
Notifizz isn't a tool *engineers spend their day in*. It's a place engineers occasionally show up — to register a new event, register a new enricher, review an AI-proposed orchestrator change. The activity log sends notifications to engineers when their attention is needed; otherwise it doesn't. The "tools tax" is low because the engagement model is event-driven, not session-driven.
The QA surface is the campaign detail page Product already uses to review the campaign. Delivery history is a click away. The funnel is a click away. The dev tasks Product needs to know about are surfaced in the same view as the campaign itself. There isn't a separate QA tool — the platform is the QA surface, because the audit data lives where the work does.
The platform doesn't decide; it makes the disagreement visible. Comments on the activity log, dev-task statuses, version history — all the artefacts of the disagreement live on the campaign detail. The decision happens off-platform (in a meeting, in Slack, in a doc); the platform records what was decided and who decided it. That's the right scope — process belongs to the team.
Most days, yes. The campaign editor, the preview, the dashboard analytics — all Marketing-native. Dev tasks only surface when something genuinely new is needed (event, enricher, branch). When a dev task appears, the platform tags Dev; Marketing doesn't need to read code, just needs to know "Dev is on this". The "open the dev side" moments are rare and explicit.
Compliance is its own role, and Notifizz fits it the same way. Templates, variables, and brand all live in the dashboard with version history; Legal can review templates and request changes. The privacy story is genuinely simpler because Notifizz doesn't sync customer data ([why enrichers](/docs/why/enrichers)) — DPO has less to audit, not more.
Yes, in a different way. A solo founder is Marketing + Dev + Product simultaneously; the cost of context-switching across three different tools is exactly the cost a small team can least afford. One platform with three views compresses the switching cost. The AI's full visibility helps proportionally more — there's no "other team" to coordinate with, but there's still a need for the AI to see the full picture.
## Where to go next
The hero pillar — whole-team is the fourth ingredient.
The AI argument that depends on whole-team visibility.
Where Marketing intent and Dev primitives meet.
The shared review surface for the three jobs.