> ## Documentation Index
> Fetch the complete documentation index at: https://notifizz.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Campaign Copilot — From a Sentence to a Reviewable Draft
> Describe the campaign you want; the copilot interviews you, proposes one flow, and materialises a draft with the copy already written. It stops at the draft — publishing stays human.
# Campaign copilot
Notifizz has two AIs, and they do not overlap. The **[orchestrator](/docs/concepts/orchestrator)** is the technical one: it writes the code that resolves recipients and pulls in live data. The **copilot** sits upstream of it and speaks only business — what the campaign is trying to achieve, who receives it, when, and in what words.
You open it with a sentence. It comes back with a flow: a trigger, an audience, an objective, and an ordered list of notifications, each one written. Then it stops, and a human takes over.
**Written for Marketing** — the copilot's whole design is to be usable without knowing what an enricher is. Developers get the same journey from their IDE; there is a section for that below.
## TL;DR
* **It interviews before it proposes.** The first turn is questions, never a plan — guessing is the failure mode it is built to avoid.
* **It proposes exactly one flow**, not three options: name, trigger, audience, objective, and the ordered steps with their channels and delays.
* **On your approval it materialises a draft** in `Editing` and hands each notification to a per-channel agent that writes the actual copy.
* **It stops there.** It never writes orchestrator code, never advances a status, never publishes.
* **It cannot invent.** Every event and audience it names has to exist already; when one is missing it proposes creating it and waits for you.
* **Approving costs no AI credit** — the approve path is deterministic. Each chat turn costs one credit from your organisation's daily pool.
## Where to open it
| From | What happens |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **Create with AI**, in the campaign creation wizard | Opens the copilot on a fresh draft. The campaign is only created on your first real message, so abandoning the panel leaves nothing behind. |
| The copilot panel on an existing campaign | Same copilot, with the campaign's current notifications already in view — it reads them before proposing a change. |
The panel is split: the conversation on the left, the live workflow on the right. While a flow is being proposed and designed the right side shows the steps with their per-step status; once every notification is written it switches to the real campaign workflow, the same view the campaign panel uses.
## How a session goes
Two to four concrete business questions: the outcome you want, the exact audience and the condition that defines it, what the message must say, the timing and the number of steps, the tone. Questions arrive as cards you answer inline — pick an option, type an answer, or attach an image. It keeps asking whenever something new turns out to be ambiguous.
A single tight proposal, rendered on the right with its own **Approve** button, plus a short explanation of the choices it made. Push back in the conversation — a different audience, one step fewer, another channel — and it revises.
Approving materialises the campaign: it sets the name, binds the trigger event, finds or creates the audience, sets the objective and creates one notification per step.
Each notification goes to an agent specialised in its channel. They may each come back with one quick clarifying question before writing — an image to use, a detail to confirm. Design in progress is tracked by Notifizz, so a reload or a closed tab does not lose it.
The draft is in `Editing`, with the copy written and the workflow assembled. From here it is the normal [campaign lifecycle](/docs/concepts/campaigns): a human sends it to implementation, to review, and eventually live.
## What a flow contains
Everything the copilot proposes maps onto real campaign configuration — there is no separate "AI object" that later has to be translated.
| Part | What it is |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| **Name** and funnel stage | The campaign's identity, plus an optional label placing it in the funnel — acquisition, activation, retention, referral, revenue. |
| **Trigger** | One real [event](/docs/concepts/events) that starts the campaign. |
| **Recipient** | A short audience name and description, reusing an existing one when it fits, plus an optional plain-language **only-if** condition. |
| **Objective** | What counts as success — see below. |
| **Steps** | An ordered list of 1..N notifications, each with a channel, a delay, a name, and a design brief. |
### Channels and delays
A step is a notification center message, an email, or a [web push](/docs/sdks/web-push/overview). Its **delay is relative to the step before it** — the trigger, for step one.
Web push is enabled per organisation. If it is not switched on for yours, a proposal containing a push step is refused when it is materialised, with a message saying so — ask your Notifizz contact to enable it, or drop the step.
One rule is worth knowing because it changes how a timeline reads: when two steps are meant to fire at the *same moment* in different channels — an in-app message and an email for the same nudge — the gap sits on the first of them and the second is immediate. Repeating the same gap on both would make the second one land twice as late. The copilot applies this itself; it matters when you review a proposal and are counting days.
Steps are kept inside a 30-day horizon.
### Objectives
The copilot picks the [objective](/docs/concepts/objectives) rather than asking, most of the time:
* **`click`** when the flow has a call-to-action button, **`read`** when it does not. That covers the large majority of campaigns.
* **A business event** only when success is a specific conversion — a purchase, a subscription. In that case it asks you which event marks the goal rather than guessing.
* It never reuses the trigger as the objective, and never invents an objective event.
It also sets whether reaching the objective **stops the sequence** for that recipient. The default is that everyone receives the whole sequence: a tracked click only proves someone opened a page, not that they finished anything. It switches to stopping early only when hitting the objective genuinely means the recipient is done — a real conversion — so the follow-ups would be noise.
## What it can create for you
**A missing event.** When the campaign needs a trigger or an objective that does not exist yet, the copilot does not just report the gap: it surfaces a pre-filled form with a name and a one-line description, and stops. You confirm the form to create the event. It pre-fills nothing else on purpose — Notifizz works the event's properties out from how the campaign uses it. Until you confirm, the copilot will not reference the event or move on.
This is also where the copilot recognises triggers that no single user action emits — *nobody did anything for three days*, *a count reached five*, *a weekly recap* — and proposes the matching [synthetic event](/docs/concepts/synthetic-events) in business terms.
**A vocabulary entry.** When you explain an unfamiliar term during the interview, it offers to remember it — as a proposal you edit and approve, never as a silent write. See [knowledge base](/docs/concepts/knowledge-base).
## Where it stops
The boundaries are not politeness; each one exists because crossing it would produce damage that is hard to see.
| It never | Because |
| ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Invents an event or an audience** | Everything it names must already exist in your catalog. A fabricated trigger produces a campaign that silently never fires. |
| **Writes orchestrator code** | Enrichers, event properties and implementation tasks are the technical layer. The copilot does not know about them and will not mention them — the [orchestrator](/docs/concepts/orchestrator) reconciles business intent down to them afterwards. |
| **Advances a status** | It leaves the campaign in `Editing`. Implementation, review and publishing to `Live` are human decisions, in the dashboard. |
| **Rewrites a published version** | On a `Live` campaign, the write is refused. Open a pending update from the dashboard first; the copilot then works on that editing copy, and the live version keeps serving untouched. |
| **Removes content silently** | A destructive change — removing a notification's visual, today the only one — surfaces a confirmation you must click. The change is applied by your click, not by the model's decision. |
| **Builds a broadcast** | A `marketing` campaign sends to a CRM segment rather than reacting to an event. Create it plainly and configure it in its panel — see [broadcasts](/docs/concepts/broadcasts). |
It is also explicitly told not to ask you about click tracking, redirect URLs or link routes. Button clicks are tracked automatically and the real destination is bound later; a button in a proposal only needs a clear intent in plain words.
## Editing an existing campaign with it
Once the flow exists, the copilot can see what has already been designed and change it: *make step two shorter*, *add an email after three days*, *swap the subject*, *drop the last reminder*.
The save is a **reconciliation, not a re-creation**. Steps are matched by position: existing ones are updated in place, new ones appended, removed ones dropped. Nothing is duplicated. Only the steps whose copy must change are re-written — the others keep their content, **including edits you made by hand in the editor**. A purely structural change, like reordering or changing a delay, rewrites no copy at all.
## Working on one email directly
The campaign copilot briefs the channel agents; it does not write the final copy itself. When the thing you want to change is one email, you do not have to go back up to the campaign conversation: the email editor has its own AI panel that talks to *that* email's design agent. It keeps the current layout and sections unless you ask for a different structure, saves in place, and the editor reloads its preview when it is done. That conversation is the email's own history and survives reloads.
## From your IDE
The same journey is drivable from an AI coding tool over [MCP](/docs/ai/connect-your-ai-tool), which is how a developer takes a campaign from a brief to a sandbox test without leaving the editor:
| Tool | What it does |
| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `campaign_create` | Starts a campaign from a one-line brief and runs the first interview turn. |
| `campaign_answer` | Relays your answers. While the campaign is being built these reach the copilot; once it is in implementation or review the same tool routes them to the orchestrator instead. |
| `campaign_approve` | Materialises a proposal the user approved, and designs the notifications. |
| `campaign_get_status` | The compass: current phase, what is blocking, open questions to relay, and which tool to call next. |
| `campaign_implement` | Sends a designed campaign to implementation and runs the orchestrator; also the way to re-run it after resolving tasks. |
| `campaign_list_tasks` | The implementation tasks, each with a ready-to-run prompt for your codebase. |
| `campaign_send_to_review` | Promotes it to review so it can be test-triggered. |
| `campaign_send_test_event` | Fires the trigger event on a non-production environment, through the real pipeline. |
| `campaign_get_test_activity` | What the test run actually did: triggers, per-step delivery, why messages were dropped, objective hits. |
| `campaign_archive` | Abandons a campaign — and refuses to run without an explicit confirmation. |
Two safeguards worth knowing about, because they are not in the dashboard flow:
* **Duplicate guard.** Creating a campaign from a brief that resembles existing ones returns those campaigns instead of creating anything. The agent shows you the list — name, status, link — and only creates a new campaign if you say so. Two campaigns on one event is a legitimate thing to want; it just should not happen by accident.
* **Publishing stays out.** There is no tool that sets a campaign `Live`. That transition is deliberately dashboard-only and human-only.
These tools need the campaign-write permission on the credential you connected; read-only ones such as `campaign_get_status` need only the read permission. See [scopes & audit](/docs/ai/scopes-and-audit) for how a credential is bounded, and the [MCP tools reference](/docs/ai/mcp-tools) for the full surface.
## The conversation itself
* **One [AI credit](/docs/plans/ai-credits) per chat turn**, from your organisation's daily pool. A turn that fails before producing anything is refunded; once the pool is empty, turns are refused until it resets.
* **Approving is free.** The Approve button materialises and designs deterministically, without an extra model turn — so re-reading a proposal before you commit costs nothing.
* **The thread lives in your browser**, per campaign, and **New conversation** clears it. Design work already under way is tracked by Notifizz, not by the tab, so clearing a thread or reloading never strands a half-designed notification.
* **It writes in your organisation's working language**, not the language of the interface and not the language you typed in. That is a [knowledge base](/docs/concepts/knowledge-base) setting.
## Getting a better draft
The copilot's output quality is mostly not about prompting. Three things move it, in this order:
1. **Fill the [business context](/docs/concepts/knowledge-base).** Without a description of what your company sells, the AI reasons from your event names and produces a generic version of your industry. This is the single biggest lever.
2. **Answer its questions properly.** It asks because guessing is the failure it was tuned against. A one-word answer to *who exactly receives this* buys you a one-word-quality audience.
3. **Name your things.** A filled vocabulary — with the words that matter starred — is what makes the copy sound like your product rather than a competitor's.
## FAQ
No — that is the first turn working as designed. It is instructed never to propose on the first turn and to interview instead, because a plausible-looking flow built on a guessed audience is far more expensive to unpick than one extra round of questions. Answer the cards and the proposal comes on the next turn.
No, and deliberately. It proposes one tight flow where every step earns its place, then iterates on your feedback. Three variants would mostly differ in ways you cannot evaluate before seeing real copy — and you would still end up editing one of them.
Approval materialises the structure; the per-channel agents write the copy right after, and one of them may ask a clarifying question first. The right-hand column shows a status per step. If a step fails, retry it from there — the others keep what they have.
The campaign is published. A live version is never rewritten in place, because doing so would rebind its trigger and swap its audience under traffic that is already running. Open a pending update from the campaign — the copilot then works on that editing copy, and you publish it when it is ready.
Because it does not know about them. The split is intentional: the copilot works at the level you can see in the campaign panel, and the orchestrator reconciles that business intent down to the technical primitives afterwards — raising [implementation tasks](/docs/concepts/orchestrator) for anything missing. An AI that discussed both layers at once would produce briefs that read like tickets.
Not today. The copilot builds event-triggered campaigns; a mailing to a segment is a [broadcast](/docs/concepts/broadcasts), which is created plainly and configured in its own panel. The Create with AI button is hidden for that category rather than offering something it cannot finish.
Not unless the change you ask for requires it. On a save it only re-writes the steps whose copy must change; everything else — including your manual edits — is kept exactly as it is. Reordering steps or changing a delay rewrites nothing.
No. It reads your event catalog by name, your audiences, your existing campaigns, your section catalog and your [knowledge base](/docs/concepts/knowledge-base) — names and descriptions, never records. Customer data flows at runtime through your enrichers, long after the copilot's work is done.
## See also
The language, context and vocabulary the copilot writes from.
The lifecycle the draft enters — statuses, review, send scope.
The technical half that takes over after the draft.
What the copilot sets as the campaign's target, and why.