---
id: KB-CD-010
url: https://app.codecontract.io/help/credits-and-billing/planning-a-years-consumption
idioma: en
categoria: creditos
audiencia: administrador
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-CD-003, KB-CD-009]
citadoPor: [KB-CD-014, KB-CD-020]
---

# Planning a year's consumption

_Count actions, not suppliers or users, and anticipate the three peaks._

**Responde a:** budgeting annual consumption · how many credits will i need per year · planning platform spend · estimating credit usage

Estimates nearly always fail for the same reason: they are calculated per supplier or per user, and consumption does not work that way. It follows executed actions, and those cluster at specific moments of the year.

## How to count

1. **Count the recurring actions in a normal month** — Onboardings, signature sends, documents uploaded and read. That is your floor.
2. **Multiply by twelve** — That is the bulk and it tends to be fairly stable.
3. **Add the peaks separately** — That is what throws everyone's estimate off.

## The three peaks almost everyone has

| Peak | When | What triggers it |
| --- | --- | --- |
| Annual supplier renewal | Usually January or the start of your year | One send per supplier, plus reminders |
| Season or peak trading | By sector | Staff onboarding in a few weeks |
| Mass send to all staff | Agreement changes, amendments | One send, even to three hundred |

> [!IMPORTANT]
> The third is the most overestimated and it works in your favour: a bulk send counts as **one** action, not one per recipient. If you are budgeting the annual amendment for three hundred employees as three hundred send credits, the real figure is much lower.

> [!WARNING]
> The most underestimated is the second. Sixty onboardings in one week of season consume more than three normal months, because each onboarding is several actions: creating, sending, uploading and reading documents.

## What to review mid-year

**En corto**

- Whether real consumption runs above your estimated floor, and why.
- Whether one process accounts for more than half.
- And whether SMS is on by default where it was not needed.

> [!NOTE]
> Buying for a whole year at once only makes sense if the licence covers that period: credits do not expire with time, but they cannot be spent if the licence lapses.

**Can I adjust mid-year?**

Yes, topping up is immediate.

**Is it worth buying extra?**

Enough not to stop mid-batch; beyond that it adds nothing.

**Can I see consumption per process?**

Yes, and it is what explains the peaks.

## Ejemplos

**A company budgets the year by multiplying its supplier count.**

- Counts actions in a normal month and adds the three peaks separately
- Checks that a bulk send counts as one action

→ The figure drops substantially and the budget stops being oversized by mid-year.

**The year is estimated from a quiet month's consumption.**

- Separates the peak month from a normal one

→ The forecast holds for the year.

**Expected growth is not accounted for.**

- Adds the growth assumption

→ The estimate does not fall short mid-year.

**Planning happens without knowing what each process consumes.**

- Checks consumption by activity type

→ The forecast rests on your own data.

**A new process is introduced without estimating its consumption.**

- Estimates before rolling it out

→ The impact is known beforehand.

**Management asks for an annual figure.**

- Brings the per-activity calculation and the assumption

→ The figure is explicable.