> ## Documentation Index
> Fetch the complete documentation index at: https://notifizz.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What Your Plan Includes

> The three things a plan grants — metered volume that renews, stored resources you own, and capabilities that are on or off — and where to read your own numbers.

# What your plan includes

A Notifizz plan grants three different kinds of thing, and they behave differently enough that mixing them up is the usual source of surprise. This page names them, says exactly what is counted, and points at the screen where your own figures live.

Written for **Product/Ops and the decider**, with the counting rules a **Dev** needs when a creation gets refused.

<Warning>
  **Enforcement is rolling out.** Counters are live and visible for every organisation, and **AI credits are enforced today**. Send quotas and stored-resource ceilings are being switched on progressively — until enforcement is active for your organisation, the gauges fill up but nothing is refused. Ask your Notifizz contact where your organisation stands.
</Warning>

<Note>
  This page describes the **mechanics**, never the price list. Plan names and amounts live on [notifizz.com](https://notifizz.com) and are the authority on what your tier grants.
</Note>

## TL;DR

* **Metered volume** — sends and AI runs. It renews on a period and does not roll over.
* **Stored resources** — a ceiling on what your organisation *owns* (campaigns, environments, email components, uploaded assets). No period, no renewal: it frees up when you archive or delete.
* **Capabilities** — on/off switches for a whole feature. Absent means off.
* **Every send costs two credits at once**: one on its channel, one on the cross-channel total. Whichever runs out first caps the batch.
* **Only `Live` campaigns consume send volume.** Editing, Implementation, Review and Offline runs are free, review simulations included.
* Your own figures: the **Billing & usage** page, *Usage* tab — capabilities, current-period gauges, stored resources, credit lots, recent blocked sends.

## The three kinds of grant

| Kind             | Bounds                                  | Renews                                | Freed by                                    |
| ---------------- | --------------------------------------- | ------------------------------------- | ------------------------------------------- |
| Metered volume   | What you *consume* over a period        | Daily or monthly                      | The next period                             |
| Stored resources | What you *own*, right now               | Never — it is a ceiling, not a budget | Archiving or deleting                       |
| Capabilities     | Whether a feature exists for you at all | Not applicable                        | A plan change, or a per-organisation switch |

## Metered volume

Volume is carried by **credit lots**. A plan grant becomes a lot for the current period the first time you consume from it; packs and one-off gestures add their own lots. Lots are consumed in **expiry order**, so the credits that die soonest are spent first.

### The dual decrement

One message costs **one credit on its channel** *and* **one credit on the cross-channel total**. A plan can therefore be generous on a single channel and still bound your overall footprint — and the tighter of the two is what actually caps a send. AI credits are the exception: they never touch the cross-channel total.

### What is metered

| Resource            | Shown as                     | Counts                                                |
| ------------------- | ---------------------------- | ----------------------------------------------------- |
| Cross-channel total | *All channels (total sends)* | Every message on every channel                        |
| Email               | *Email*                      | One email handed off to delivery                      |
| Notification centre | *Notification center*        | One in-app message                                    |
| Web push            | *Web push*                   | One browser notification                              |
| AI credits          | *AI credits*                 | One AI run — see [AI credits](/docs/plans/ai-credits) |

The usage view also lists **Slack**, **Webhooks**, **SMS**, **Postal mail** and **WhatsApp**. These are metered by the platform but are not generally available channels today; on most plans they read *Not included in your plan*. See [channels](/docs/concepts/channels) for what actually ships, and note that [web push](/docs/sdks/web-push/overview) is itself a per-organisation capability.

### When volume renews

| Grant   | Period key         | Renews                        |
| ------- | ------------------ | ----------------------------- |
| Monthly | UTC calendar month | At the start of the UTC month |
| Daily   | UTC day            | At UTC midnight               |

Monthly periods are the **UTC calendar month for everyone** — not an anniversary of the day you subscribed. A plan lot is valid for its period only, so **unused volume does not roll over**.

<Note>
  A plan grant is claimed **lazily**: the lot appears in the *Credit lots* table the first time you consume from it that period. An empty table does not mean you have no credits — it means the grant is still fully intact.
</Note>

### Lots that are not the plan grant

| Source  | Shown as  | Where it comes from                                                |
| ------- | --------- | ------------------------------------------------------------------ |
| Plan    | *Plan*    | Your tier's grant for the current period                           |
| Pack    | *Pack*    | A one-off purchase, where the plan marks a resource as purchasable |
| Granted | *Granted* | A one-off gesture credited to your organisation                    |

Packs and gestures can carry their own expiry date rather than dying with the period, which is why the table shows a *Validity* column: *Current period*, an explicit expiry date, or *No expiry*.

## Stored resources

A stored resource is a ceiling on what your organisation owns at this instant. There is no period and nothing to renew — the count is taken live, every time you create something.

| Resource       | Shown as         | What counts                                                                          | What does not                |
| -------------- | ---------------- | ------------------------------------------------------------------------------------ | ---------------------------- |
| Campaigns      | *Campaigns*      | Every campaign that is not archived — Editing, Implementation, Review, Live, Offline | Archived campaigns           |
| Environments   | *Environments*   | Every environment                                                                    | —                            |
| Layouts        | *Layouts*        | Every email layout you own                                                           | Version history of a layout  |
| Sections       | *Sections*       | Every email section you own                                                          | Version history of a section |
| Assets storage | *Assets storage* | The total size, in MB, of the files in your asset library                            | Files you have deleted       |

Three consequences worth knowing before you plan a migration:

* **Archiving a campaign frees a slot.** The count excludes archived campaigns, so cleaning up an old programme buys room for a new one without asking anyone.
* **A component's history is free.** One layout is one unit no matter how many versions it has been through — editing never costs capacity.
* **A fresh organisation already owns two environments.** Production and a sandbox are provisioned at creation, so the environment ceiling is counted from two, not zero.

## Capabilities

A capability is a boolean: your plan either carries it or it does not. Absent means **off**, and several of them are switched on per organisation rather than by tier — that is how closed betas are run.

| Capability             | What it unlocks                                                                                                                                               |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Web push channel       | Adding a web push step to a campaign. Closed beta, per organisation. See [web push](/docs/sdks/web-push/overview).                                            |
| Marketing broadcasts   | Launching a mailing to a CRM segment. Closed beta, per organisation. See [broadcasts](/docs/concepts/broadcasts).                                             |
| Custom tracking domain | Serving your emails' links and tracking under your own hostname instead of the shared one. Top tier. See [tracking domain](/docs/operations/tracking-domain). |
| Beta connectors        | Connecting the inbound connectors still marked beta. Closed beta, per organisation.                                                                           |
| Subscribe widget       | The public subscribe surface, and with it the **Subscribers** audience provisioned for your organisation. Closed beta.                                        |

Two properties are deliberate and worth relying on:

* **Capabilities gate creation, not what already runs.** Losing the web push capability does not silence a campaign that already has a push step; losing the custom tracking domain capability does not stop your active domain from serving. A plan change never strands live traffic mid-flight.
* **The one exception is beta connectors**, which gate both connecting a source *and* receiving from it. A suspended source stops ingesting — the accepted cost of keeping an unproven integration behind a switch.

The **Billing & usage** page lists every capability your organisation carries, enabled or not — including two that shape presentation rather than access, *custom branding* and *advanced analytics*. The table above covers those that change what you can build.

## Where to read your own numbers

Open your organisation menu and pick **Billing**. The page is titled **Billing & usage** and its *Usage* tab holds, in order:

| Section              | Answers                                                          |
| -------------------- | ---------------------------------------------------------------- |
| Capabilities         | Which features are switched on for us?                           |
| Current period       | How much volume have we used, and how much is left?              |
| Stored resources     | How close are we to a ceiling?                                   |
| Credit lots          | Which credits are backing those gauges, and when do they expire? |
| Recent blocked sends | Did a limit actually cost us a delivery?                         |

A resource with no ceiling reads **Unlimited**, and its gauge reports what you sent this period rather than what remains. A channel your plan does not carry reads **Not included in your plan**.

<Note>
  The **Recent blocked sends** list only ever shows sends that were genuinely blocked. While enforcement is still rolling out, the would-be refusals recorded for calibration are deliberately kept out of it — an entry there always means a real delivery did not happen.
</Note>

## Trials, and what happens after one

A new organisation starts with a **14-day trial**, during which the feature channels are open and the costlier ones are capped. The **Billing & usage** page carries a countdown and an upgrade action while it runs.

When the trial lapses, the organisation moves to the free tier. **Access is never withdrawn**: you keep your campaigns, your environments and your dashboard — what changes is the caps. The billing page itself stays reachable on every plan, including a lapsed one, because it is the way back.

## FAQ

<AccordionGroup>
  <Accordion title="Does a test send eat into our volume?">
    No. Only a campaign in the `Live` status consumes send credits. Everything in Editing, Implementation, Review or Offline is free — review simulations included. That is deliberate: onboarding and verification should not cost you the month's budget.
  </Accordion>

  <Accordion title="We are over a stored-resource ceiling after a plan change. Did we lose anything?">
    Nothing. A ceiling only ever refuses a **new** creation; it never deletes, archives or hides what you already own. You keep editing everything, and the moment you archive a campaign or delete an asset the count drops and creation works again.
  </Accordion>

  <Accordion title="Do unused sends carry over to next month?">
    No. A plan grant is valid for its period and expires with it. Credits from a pack are the exception — they carry their own validity, which the *Credit lots* table shows.
  </Accordion>

  <Accordion title="Our monthly counter reset in the middle of the billing cycle. Why?">
    Monthly volume is keyed on the UTC calendar month, identically for every organisation — it is not anchored to your subscription date. So the counter turns over at the start of the month, whatever day you signed up.
  </Accordion>

  <Accordion title="Why does the Credit lots table say we have no lots?">
    Because you have not consumed anything from that grant yet this period. Lots are claimed on first use; until then the whole grant is intact. The gauge above the table already accounts for it.
  </Accordion>

  <Accordion title="Can a capability be turned on for us alone?">
    Yes — that is how the closed betas work. Capabilities resolve as your plan plus any per-organisation switch, so your Notifizz contact can enable one without moving you to another tier.
  </Accordion>
</AccordionGroup>

## See also

<CardGroup cols={2}>
  <Card title="When you hit a limit" icon="gauge-high" href="/docs/plans/limits-and-quotas">
    What gets refused, which recipients are dropped, and how to unblock.
  </Card>

  <Card title="AI credits" icon="wand-magic-sparkles" href="/docs/plans/ai-credits">
    What burns a credit, when the pool refills, what stops when it is empty.
  </Card>

  <Card title="Channels" icon="bell" href="/docs/concepts/channels">
    What each metered channel actually delivers.
  </Card>

  <Card title="Environments" icon="layer-group" href="/docs/environments/overview">
    Why a fresh organisation already owns two.
  </Card>
</CardGroup>
