Trial activation nudges by trigger

Use when trials sign up and go quiet before they reach the point where the product proves itself.

trial-activation-nudge-triggers.md

Download .md

You are a product lifecycle email strategist. You are designing behaviour triggered sends, not a fixed drip.

Product and what the trial includes: {{PRODUCT_AND_TRIAL}}
Trial length and what happens at the end: {{TRIAL_TERMS}}
The setup steps that separate an active account from a dormant one, in order: {{ACTIVATION_STEPS}}
Events I can trigger on today, as they exist in my data: {{AVAILABLE_EVENTS}}
Where a person gets help: {{SUPPORT_ROUTE}}

Output a table: Trigger condition | Delay after trigger | Which step of {{ACTIVATION_STEPS}} it unblocks | Subject | Body under 90 words | Call to action pointing at that step | Suppression rule.

Then two numbered lists.
1. Steps in {{ACTIVATION_STEPS}} with no matching event in {{AVAILABLE_EVENTS}}, and the event I would need to add for each.
2. The three sends to build first if I can only build three, given {{TRIAL_TERMS}}.

Rules:
- Every trigger must be expressible with {{AVAILABLE_EVENTS}}. If a send needs an event I do not hold, put it in list 1 rather than in the table.
- No send may reach an account that has already done the step it is about. Write that suppression rule on every row.
- Do not describe capability beyond what {{PRODUCT_AND_TRIAL}} states.
- Anyone still stuck after two nudges on the same step goes to {{SUPPORT_ROUTE}} instead of a third nudge.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{PRODUCT_AND_TRIAL}}
{{TRIAL_TERMS}}
{{ACTIVATION_STEPS}}
{{AVAILABLE_EVENTS}}
{{SUPPORT_ROUTE}}

Getting a better result

List the activation steps in the order the product forces. A nudge about step three is noise to an account stuck on step one.
Write the suppression rules before the copy. Nudging someone to do what they did yesterday is the fastest way to lose a trial.
Anchor the final send to the trial end date, not the signup date, so extensions and pauses do not break the flow.

Questions about this prompt

When is trigger-based better than a scheduled onboarding drip?

When you can trigger on real events and the trial has a defined activation path. A time-based drip sends step three advice to accounts stuck on step one, which is how trials go quiet. If you hold no usable events yet, run it anyway for the list of events you are missing.

What do I need to know about my own event data?

Exactly which events you can trigger on today, as they exist in your data, alongside the activation steps in the order the product forces them. Guessing at the event list produces a table you cannot build. Trial length and end behaviour matter too, since the last sends anchor to the end date.

What does the trigger map return?

A table with trigger condition, delay, the activation step each send unblocks, subject, body under 90 words, call to action and a suppression rule per row, then the steps with no matching event and the three sends to build first. That missing-event list is the engineering ticket the flow depends on.

What loses trials fastest?

Shipping without the suppression rules. Nudging an account to do what it did yesterday reads as proof the product is not watching, which is why a rule sits on every row. The other is anchoring the final send to the signup date, so extensions and pauses break the flow.