Implementation worksheet · 6 min read
A Usage-Triggered Expansion Campaign Specification
Specify five things: the trigger (the exact event and threshold, with the window it is measured over), the debounce (how long the condition must hold before the campaign fires, so a single spike does not trigger it), the cooldown (how long before the same account can trigger again, which is the rule that separates helpful from nagging), the exclusions (who never receives this regardless of usage), and the exit (what stops the journey — upgrade, reply, opt-out, or usage falling back). Write the cooldown and the exit before the copy. Those two decide whether the campaign reads as attentive or as automated pestering.
Usage-triggered expansion is the most defensible marketing email a product company sends: it arrives because the recipient is actually running into something. It is also the easiest to get wrong, because the trigger fires on a metric that fluctuates. An account that crosses a threshold on Monday, drops below on Tuesday and crosses again on Wednesday will receive three emails unless something prevents it, and nothing prevents it by default.
Put it into practice
1. Write the trigger as an event, threshold and window
'Approaching a plan limit' is an intention. 'Used 80% or more of the monthly quota, measured over the current billing period' is a trigger. If you cannot express it as a query against your event data, the campaign cannot be built correctly and will be approximated instead.
2. Add a debounce so a spike does not fire the campaign
The condition must hold for a stated period — a day, three data points, whatever suits your metric — before the journey starts. Without this, a batch import or a one-off test pushes an account over the line and triggers an upgrade email to someone who is not growing.
3. Set the cooldown explicitly, in days
How long before this account can enter this campaign again. Thirty to ninety days is common. This single number is the difference between a message that feels attentive and one that feels like the system is watching and will not stop. Write it down; do not leave it to whatever the platform defaults to.
4. List the exclusions and apply them at send time, not at entry
Active support escalation, open billing dispute, contract already covering the capacity, account flagged as at-risk, anyone who opted out of commercial email. Applying them at send time matters because an account's state can change between entering a journey and receiving the third message in it.
5. Define every exit condition
Upgraded (obviously), replied to the email, contacted support about the same thing, usage fell back below the threshold, opted out. Each should stop the journey immediately. The 'replied' exit is the one most often missing, and it produces the worst outcome: someone answers a helpful email and the automation keeps going regardless.
6. Decide what evidence the message shows
Expansion email is far more effective when it shows the usage rather than asserting it — the number, the period, and what happens at the limit. It also keeps the team honest: a message that must display the evidence cannot fire on a signal too vague to display.
The trigger contract
Copy this structure into your review document and record your observed result for each row.
| Element | Your value | Why it is there | Set |
|---|---|---|---|
| Event and threshold | the observable condition | ||
| Measurement window | separates trend from spike | ||
| Debounce period | stops one-off triggers | ||
| Cooldown (days) | stops repeat nagging | ||
| Exclusion: support escalation | credibility | ||
| Exclusion: billing dispute | credibility | ||
| Exclusion: already covered by contract | accuracy | ||
| Exit: upgraded | obvious | ||
| Exit: replied to the email | most often missing | ||
| Exit: usage fell back | condition no longer true | ||
| Evidence shown in message | earns the send |
A failure worth checking
The oscillating trigger. An account hovers either side of 80% of quota, and with no debounce and no cooldown the journey re-enters every time the condition flips true. The recipient gets four near-identical emails in ten days about the same limit. They do not read this as helpful automation; they read it as a company that cannot see they are already aware. The debounce and cooldown rows exist to make this impossible rather than unlikely.
Common questions
Should expansion email come from a person or the product?
Whichever can honestly answer a reply. A message from a named person that bounces into an unmonitored mailbox is worse than an obviously automated one, because it invites a response the system cannot receive. Decide the reply path first, then decide the from name.
How do I know the campaign is working?
Not from its conversion rate alone — the accounts triggering it were already growing, so some would have upgraded regardless. Hold out a share of eligible accounts and compare. Without a holdout you are measuring the trigger's quality, not the campaign's effect.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.