Per-Client Sending Capacity Allocation and Escalation

Capacity planning is an allocation and escalation exercise, not a promise of a fixed send quota. Record the provider constraints, sender identity, client attribution, observed demand, reserve, and stop conditions before assigning capacity.

Capacity ledger

Calculate planned demand from the actual schedule and recipient eligibility snapshot. Keep attempted, accepted, bounced, and suppressed counts separate. A campaign can look under capacity while producing a high error or complaint signal.

Allocation sequence

1. Inventory identities, providers, account limits, mailbox status, and client contracts.
2. Estimate demand by client and period, including follow-ups and retries.
3. Deduct known exclusions and preserve a reserve for approved operations.
4. Allocate only within the provider’s current documented and observed constraints.
5. Attach every send to client, campaign, identity, and audience version.
6. Review feedback by identity and client before increasing allocation.

Google’s sender guidance is provider-specific and can change, so recheck it at publication and when an account receives a notice. Use pre-send checks and observability guidance alongside the ledger.

Escalation rules

Pause a stream when authentication is failing, the audience or suppression snapshot is missing, provider feedback implicates the identity, or the client requests a stop. Escalate when demand exceeds available attributable capacity, reserve is consumed, the same error repeats, or one client’s activity could affect another tenant. Do not shift volume to a new identity as a substitute for root-cause review.

Capacity decision procedure

The capacity owner prepares one ledger per client and sending identity. Required fields are provider and account, identity, client and campaign, period and time zone, planned attempts, retries, accepted and rejected counts, suppression count, observed constraint, current provider notice, reserve, pause threshold, escalation owner, and review date. The delivery lead approves allocation; the infrastructure owner confirms the account and identity boundary; the data owner confirms eligible volume; and the incident owner decides whether feedback requires a pause. Do not turn an observed limit into a universal quota or promise.

Run the calculation in order: (1) freeze the audience snapshot and schedule; (2) estimate first sends and follow-ups separately; (3) subtract suppressions and known exclusions; (4) compare attempted demand with current documented and observed constraints; (5) reserve capacity for approved retries or operational changes; and (6) allocate by client, identity, and stream so events remain attributable. Reconcile sending observability with pre-send checks before an increase.

Stop allocation when the eligible count is unknown, event attribution is missing, authentication fails, provider feedback is unresolved, reserve is exhausted, or a client requests a stop. Never move volume to a fresh identity to evade a signal. Roll back by cancelling the incremental schedule, restoring the last approved allocation, preserving the ledger and provider evidence, and notifying affected owners. Resume only after root-cause review, a new capacity calculation, a controlled test, and explicit approval. A reserve supports continuity; it is not a bypass for policy, suppression, or complaint controls.

Sources