Follow-up Sequence Templates (post-demo, post-proposal)
Deals rarely die on the call. They die in the silence after it. This page covers the two follow-up moments with the highest leverage per email - after the demo and after the proposal - with six templates, the rules that keep follow-up from becoming spam, and two copy-paste sequence JSONs triggered by stage changes.
Who this is for
Anyone who runs demos and sends proposals: founders selling their own product, the first AE, agencies quoting projects, and AI agents that own pipeline hygiene. Use these sequences after the meeting happens - they assume a live conversation already exists. For getting the meeting in the first place, start with the cold outbound cadence; for deals that went dark months ago, use the re-engagement sequence instead of these.
The premise: follow-up fails on timing, not copy. Reps remember to follow up when the pipeline is quiet and forget when it is busy - which is exactly backwards. So the calendar gets automated and scoped to a pipeline stage, and the copy stays short enough that personalizing two variables per email is realistic.
Three rules before any template
- One question per email. Every send ends with exactly one question the reader can answer in one line. Two questions get zero answers.
- A reply moves the stage, and the stage kills the sequence. Each sequence is scoped to one pipeline stage and exits the instant the deal leaves it. Nobody who answered ever gets the next automated touch.
- Never send "just checking in." Every touch has a job: recap, give, or force a decision. If an email has no job, delete it - the follow-up that adds nothing subtracts trust.
Post-demo: 24h recap, 3d value, 7d nudge
The window after a demo is short. The prospect's memory of the call decays within days, and whoever writes the summary owns the narrative that gets forwarded internally. Three touches over seven days:
| Touch | Sends | Job | The one question |
|---|---|---|---|
| Recap | +24 hours | Prove you listened. Replay their priority in their words, not your feature list. This email is what gets forwarded to the boss. | "Did I get the priority right?" |
| Value | +3 days | Give, do not ask. Answer the question that got parked on the call, or show a peer who bought for the same reason. | "Useful enough to share with the team?" |
| Nudge | +7 days | Force a decision. Name the next step and explicitly invite a no. | "Next step, or not the right quarter?" |
The recap uses one merge field that does the heavy lifting: {{demo_priority}}, the prospect's stated priority captured as a CRM field the moment the deal moves into the demo stage. A follow-up that cannot name the prospect's priority is not worth automating - fill the field or do not move the stage. An agent can extract it from the call transcript and write it to the contact automatically.
Post-proposal: 48h check, 5d urgency, 10d close-or-close
Post-proposal silence means something different than post-demo silence: the prospect now has everything they need to decide, so every touch should surface the blocker or force the decision. The cadence stretches longer because proposals circulate internally.
| Touch | Sends | Job | The one question |
|---|---|---|---|
| Check | +48 hours | Surface the objection. Nearly every proposal needs one edit before it can be signed - scope, start date, or terms. Ask which. | "Which section would you change first?" |
| Urgency | +5 days | Make silence expensive. Anchor to their deadline, not your quarter: work backwards from their go-live date and show what slips. | "Is that date still real?" |
| Close-or-close | +10 days | Take it off the table. A clean no beats a dead maybe - say you are closing the file and make reopening one reply cheap. | "Should I close this out?" |
The close-or-close breakup owes its logic to Jim Camp's Start with No school of negotiation: a no is easier to give than a yes, so asking for one produces decisions where yes-oriented nudges produce silence. When the breakup lands and the answer really is no, move the deal out and let the re-engagement track pick it up next quarter.
The artifact: two fields + two sequences
This kit assumes two stage keys: demo and proposal. Relm's default pipeline ships with proposal; if you do not have a demo stage, add one or start from the B2B SaaS pipeline template, which defines it. Apply the kit by POSTing each fields row to /v1/fields and each sequences row to /v1/sequences:
{
"fields": [
{ "object": "contact", "key": "demo_priority", "label": "Demo - stated priority", "data_type": "text" },
{ "object": "contact", "key": "proposal_deadline", "label": "Proposal - their deadline", "data_type": "text" }
],
"sequences": [
{
"name": "Post-demo follow-up (24h / 3d / 7d)",
"channel": "email",
"enabled": true,
"enroll_existing": false,
"trigger": {
"event": "deal.stage_changed",
"filter": [{ "field": "stage", "op": "eq", "value": "demo" }]
},
"exit_when": [{ "field": "stage", "op": "neq", "value": "demo" }],
"steps": [
{
"wait_hours": 24,
"subject": "{{first_name}}, your notes from yesterday",
"body": "<p>Hi {{first_name}},</p><p>Writing down what I heard so we work from the same page. Your priority: {{demo_priority}}. That is the yardstick for everything I send from here.</p><p>Two things we agreed: I owe you answers to the questions we parked, and you wanted to loop in the people closest to the problem.</p><p>Did I get the priority right, or would you state it differently?</p>"
},
{
"wait_days": 2,
"subject": "The question we parked on the call",
"body": "<p>Hi {{first_name}},</p><p>Promised follow-through: the answer to the question we parked, plus a two-minute example of a team that bought for the same reason - {{demo_priority}}.</p><p>[Replace this paragraph with your real asset: the answer, a case study link, or a three-line customer story. Generic value emails get deleted; specific ones get forwarded.]</p><p>Useful enough to share with the rest of the team?</p>"
},
{
"wait_days": 4,
"subject": "Next step, or not the right quarter?",
"body": "<p>Hi {{first_name}},</p><p>I would rather have a clear no than keep guessing. If {{demo_priority}} is still on the roadmap, the next step is a 20-minute working session with the people who would use this. If it has slipped, tell me and I stop nudging.</p><p>Which is it?</p>"
}
]
},
{
"name": "Post-proposal follow-up (48h / 5d / 10d)",
"channel": "email",
"enabled": true,
"enroll_existing": false,
"trigger": {
"event": "deal.stage_changed",
"filter": [{ "field": "stage", "op": "eq", "value": "proposal" }]
},
"exit_when": [{ "field": "stage", "op": "neq", "value": "proposal" }],
"steps": [
{
"wait_hours": 48,
"subject": "Does the proposal hold up?",
"body": "<p>Hi {{first_name}},</p><p>You have had the proposal for two days - long enough to spot what is off. Most proposals need one adjustment before they can be signed: scope, start date, or terms.</p><p>Which section would you change first?</p>"
},
{
"wait_days": 3,
"subject": "Working backwards from {{proposal_deadline}}",
"body": "<p>Hi {{first_name}},</p><p>You said this needs to be live by {{proposal_deadline}}. Working backwards: signature this week, kickoff next week, and your buffer stays intact. Every week of silence eats the buffer, not the go-live date.</p><p>Is that date still real, or has it moved?</p>"
},
{
"wait_days": 5,
"subject": "Closing the file on this proposal",
"body": "<p>Hi {{first_name}},</p><p>No response usually means no, and that is a perfectly good answer - it lets both of us stop spending attention here. I am marking this closed on my side this week.</p><p>If I am wrong and this is still live, reply with one line and I will reopen it. Fair?</p>"
}
]
}
]
}Mechanics worth knowing, all verified against how the Relm API executes sequences:
- Waits are per-step, relative to the previous send.
wait_hours: 24thenwait_days: 2thenwait_days: 4lands at 24h, day 3, and day 7 after the stage change. - Exits are instant.
exit_whenis re-checked before every send and the moment the deal changes - a deal moved out ofdemonever gets the next demo email. Movingdemo → proposalexits sequence one and enrolls the contact in sequence two: the stages chain the sequences. - Enrollment is idempotent per sequence and contact - a deal that bounces back into a stage does not restart the emails for the same person.
- The recipient is the deal's
primary_contact_id. Deals without a primary contact do not enroll, and merge fields resolve against that contact and its custom fields. Empty fields render as empty strings, so filldemo_priorityandproposal_deadlinewhen you move the stage - not after. - Sending needs a connected channel (
POST /v1/connectionswith your Resend key). In test mode sends are simulated, never delivered - rehearse there first.
Apply it with your agent
If your agent is connected to Relm over MCP (see how to give your AI agent a CRM), paste this prompt with the kit JSON above:
Set up my follow-up sequences in Relm:
1. Call relm_list_pipelines. Confirm my pipeline has "demo" and
"proposal" stages; if my keys differ, use the closest match in
every trigger.filter and exit_when below.
2. Create the two contact fields from the kit JSON I pasted
(demo_priority, proposal_deadline).
3. Create both sequences exactly as pasted, substituting the stage
keys from step 1 if needed.
4. Call relm_preview_sequence for each and show me the send
schedule plus how many contacts would enroll right now.
5. Use my test key for all of this. I will say "go live" after I
review one simulated send.Over REST, creating a sequence is one call - here is a compact version of the post-proposal one:
curl https://api.relmcrm.com/v1/sequences \
-H "Authorization: Bearer relm_test_..." \
-H "Content-Type: application/json" \
-d '{
"name": "Post-proposal follow-up",
"trigger": { "event": "deal.stage_changed",
"filter": [{ "field": "stage", "op": "eq", "value": "proposal" }] },
"exit_when": [{ "field": "stage", "op": "neq", "value": "proposal" }],
"steps": [
{ "wait_hours": 48, "subject": "Does the proposal hold up?",
"body": "<p>Which section would you change first?</p>" },
{ "wait_days": 3, "subject": "Working backwards from your deadline",
"body": "<p>Is that date still real?</p>" },
{ "wait_days": 5, "subject": "Closing the file",
"body": "<p>Should I close this out?</p>" }
]
}'FAQ
When should a follow-up sequence stop?
The instant the deal moves. A reply means the rep or agent moves the deal to the next stage, and a stage-scoped exit condition kills the sequence immediately - before the next send, not after it. Sequences that keep mailing people who already answered are how trust dies; scope every sequence to exactly one stage and exit on any move out of it.
How many follow-up emails should I send after a demo?
Three over seven days: a recap at 24 hours, a value-add at day 3, and a direct nudge at day 7. If three purposeful emails in a week get silence, more emails will not fix it - the deal is not dead, but it is dormant. Move it out of the active stage and hand it to a slower re-engagement track instead of touch four, five, and six.
Should follow-up emails be automated or written by hand?
Automate the calendar, personalize the variables. Deals are lost to timing slips, not to imperfect prose - so let the sequence own when emails go out, and make personalization structural: merge fields like the prospect's stated priority and their deadline, filled in at the moment the stage changes. The one email worth extra hand-crafting is the 24-hour recap, which an agent can draft from call notes.
Does the break-up email actually work?
Yes, because it forces a decision instead of requesting attention. Asking for a clear no - the logic of Jim Camp's Start with No school of negotiation - is easier to answer than another yes-oriented ask, so close-or-close emails routinely get replies where nudges got silence. Even when the answer is no, you win: the deal leaves the pipeline honestly instead of rotting in it.
Do these templates require Relm?
No. The timings, the one-question rule, and all six email templates work in any sequencer - Outreach, Salesloft, Instantly, or a shared inbox and a calendar. The JSON artifact is shaped for Relm's POST /v1/sequences endpoint, which makes the whole setup a single agent instruction: stage-change triggers, per-step waits, and instant stage-based exits are first-class API objects there.