Write the Follow-Up Cadence Before You Automate One Reminder

Write the Follow-Up Cadence Before You Automate One Reminder

Write a contact standard for every pipeline stage before automating follow-up. Define the trigger, message, channel, owner, and maximum gap between touches. Send approved routine messages directly, reserve human attention for judgment, and alert when the standard is missed. Test each rule before trusting it with a live customer.

In Vista engagements, an owner has asked for a report when the real need was an alert at the moment follow-up slipped. A report could describe the backlog, but it would still require someone to notice the problem and act. The missing decision was what counted as overdue and who should receive that exception.

Tasks created without due dates sink out of sight. Worse, a reminder that says "log it in the CRM" can send the outcome to the wrong place when the team logs calls elsewhere. The rule never sees the follow-up happen. We also see salespeople resent systems that nag all day without distinguishing routine activity from a missed commitment.

Another pattern concerns deal value: tiered options change the amount before the customer commits, leaving pipeline totals disconnected from signed work. The fix was simple: record the value when the customer signs, using the option they chose. Follow-up design and reporting design belong together because both depend on a shared meaning for each stage.

What you need. Bring pipeline stages, customer messages, the logging destination, and the people responsible for follow-up. Use a shared document for the cadence and a dummy record for testing. Agree who can approve changes and switch the rules off.

Write the cadence in plain language before anyone opens the automation builder. The timings in the table are a starting point; set yours to your buying cycle and staffing. Then have the team explain the standard back to you.

THE STANDARD

What contact should happen at each stage?

Name the event. Define stages around observable customer or team actions, then give each stage a contact standard with a defined next checkpoint. A stage name alone cannot tell someone when to act. The cadence should answer that question without requiring the salesperson to reconstruct the deal from memory.

1. Map the stages and their exit conditions

Why it matters: automation fires on events. "Warm lead" is not an event.

Write what puts a deal into each stage and what moves it out. An inquiry received, a proposal sent, and a customer signature are observable events with different meanings. Separate waiting for customer information from waiting for an internal decision if the required next action differs. Otherwise, the same reminder will reach people facing entirely different blockers.

• Identify the record that carries the stage and the place staff must log the outcome.
• If the cadence names one system while the team uses another, settle that mismatch before configuring a reminder.
• Staff should be able to follow the written instruction successfully without translating it into a different workflow.

2. Write the cadence table before choosing the rules

Why it matters: the table exposes missing owners, vague timing, and unnecessary tasks while changes are still easy to make.

Use one row for each required touch, adding rows when a stage needs more than one checkpoint. Specify the event that starts the clock and the event that resets it. Sending a proposal may start the follow-up clock; receiving a substantive reply may reset it. An internal note should not silently count as customer contact.

Stage	Trigger	Touch	Channel	Owner	Max gap
New inquiry	Inquiry received	Confirm receipt and explain the next step	Customer's agreed channel	Intake owner	Immediate acknowledgment
Qualification	Receipt confirmed	Ask for missing information or offer a conversation	Agreed email or phone	Assigned salesperson	One business day
Proposal sent	Proposal delivered	Check receipt and answer questions	Agreed email or phone	Assigned salesperson	Three business days
Customer deciding	Follow-up completed	Confirm the customer's agreed next checkpoint	Agreed channel	Assigned salesperson	Three business days unless another date is agreed
Signed	Customer signs	Send confirmation and explain the handoff	Agreed email	Delivery coordinator	One business day
Paused or closed	Pause or closure recorded	Stop the sales cadence and record any agreed return date	Internal record	Assigned salesperson	No recurring sales touch

Define business days, working hours, and what happens when the customer requests a later date. A maximum gap is an operating limit, not a command to contact someone who asked for space. Put the agreed return date in the record so the exception is visible and the rule can respect it.

Give the table a named owner and an approval date before anyone translates it into automation. Ask a salesperson to use it on an example deal without extra coaching. Every question they ask is a decision you have not made yet.

THE HANDOFF

Which touches should the system send directly?

Automate messages with settled content and stopping conditions, and leave negotiation, interpretation, and sensitive customer conversations with a person. Draw the line at context. If the system has the approved facts to complete the touch accurately, let it send. If someone must decide what to say, give it to a person.

3. Assign each touch to automation or a human

Why it matters: creating a task to send a predictable message leaves avoidable work in someone's queue and adds another chance to miss it.

A receipt acknowledgment can explain that the inquiry arrived and identify what happens next without making a new commercial commitment. A signed-work confirmation can carry agreed information into the agreed handoff. When the message is approved and the fields are present, send the message. Do not create a task telling someone to send it.

• For each proposed direct message, specify the required fields and what happens when information is missing.
• If the customer name, agreed channel, or relevant date is unavailable, stop that message and route the exception to its owner.
• An automation should not improvise around a missing fact merely to clear its queue.

Vista's Agent-Does-the-Work framework. Give the agent a complete, bounded job with approved inputs and a clear exception route. For follow-up, that can mean sending a routine confirmation and recording the send. A person remains responsible for the contact standard and the cases that require judgment.

Assign a person when the touch requires deciding what to say or what the business can offer. Disputed scope, unclear replies, and requests for different terms need an accountable owner. Give the task a due time and linked record so that person can act without searching for context.

Apply Vista's task selection approach to decide which work has a stable boundary. Where interpretation is uncertain, gate AI output by confidence and route unresolved cases for review. A confident draft still needs accurate source information, especially when it mentions scope, availability, or commitments.

• Before approving a direct message, read it from the customer's position and remove any claim the system cannot know.
• Say when a person will follow up only if that timing is covered by the cadence.
• Make replies reach a monitored destination with an owner who can change the next action.

EXCEPTIONS

When should the team receive an alert?

Misses deserve alerts. Alert when a required checkpoint is missed and someone needs to act. Give routine activity a quiet record instead of turning each event into another interruption. If you are about to ask for a follow-up report, you probably want this alert instead.

4. Alert on misses and give each exception an owner

Why it matters: a useful alert identifies a broken standard, the affected record, and the action required to restore contact.

Define the alert condition before building it: the proposal was delivered, the allowed gap has passed, and no qualifying contact or pause is recorded. Here is what that looks like. A proposal goes out on Tuesday. The maximum gap passes with no reply, no logged call, and no agreed pause.

The salesperson gets one alert naming the customer and the overdue check-in. If it is still open at the next checkpoint, it goes to the sales manager. Nobody else hears about it. Define qualifying contact carefully so an internal edit cannot disguise a missed follow-up.

Check the record for replies and agreed dates before deciding that the standard was missed. The alert should identify the customer record, the overdue touch, the responsible person, and the due time for acting. It should also direct staff to log the result in the agreed system. A reminder with the wrong destination creates extra work and leaves the rule unable to recognize that the issue was resolved.

• Send the first exception to the person who owns the touch, with a specific action and due time.
• Escalate an unresolved miss by the written standard. Do not alert the whole team.
• Close or suppress the alert after completion, a customer reply, an agreed pause, or a stage change makes it irrelevant.

Keep one active exception and update its status instead of creating another task each time the rule checks an unchanged record. Record the alert history, but send new interruptions only for a changed condition or an escalation that requires someone else.

A report still has a role in reviewing patterns, including stages where misses recur and owners carrying more work than they can handle. It does not replace a timely alert with a clear action. Use the approach to reducing CRM typing to improve the activity record without making every update a manual chore.

COMMITTED VALUE

When should a deal become a signed revenue commitment?

Signature sets committed value. Capture committed value when the customer signs the chosen scope, and show earlier estimates separately so the report's labels make the distinction explicit. A proposal containing several tiers has possible values until the customer chooses. Treating a draft amount as committed work makes the report answer a different question from the one the owner expects.

5. Record value at signature and preserve the earlier context

Why it matters: the signed option supplies a clear value and event for committed-work reporting, while drafts can change during the sale.

Write down which report represents possible work and which represents signed commitments. Keep an estimated value if it helps the team manage open opportunities, but label it accordingly. At signature, capture the selected option and its agreed value from the approved record without assuming the first proposal amount remained correct.

Record	What it means	What should update it
Draft estimate	A working view of possible scope	A reviewed scope or option change
Proposal options	Offers awaiting customer selection	An approved revision to the offer
Signed commitment	The scope and value the customer accepted	The signature event and confirmed chosen option
Later agreed change	A documented change to signed work	The approved change record

Link the customer signature, chosen option, and captured value so someone can explain the number without guessing. If a later approved change affects value, handle it through the agreed change process. This is a sales-reporting rule. Leave revenue recognition to your bookkeeper.

Before switching the rule on, confirm with the people using the totals whether they need possible work, signed work, or both. When totals disagree, inspect stage and value definitions before changing the dashboard.

BEFORE GO-LIVE

How do you test the cadence and keep it working?

Test the failure path. Test each rule against a dummy record and review the whole cadence monthly. Include the cases that should stop a message as well as those that should send one. A rule is ready when its owner understands the outcome, can explain the exceptions, and knows how to stop it.

6. Test every rule before switching it on

Why it matters: a rule can recognize the right trigger while sending the wrong message, creating duplicate work, or recording an outcome incorrectly.

Use an internal test contact and dummy deal, with customer sends disabled until the test route is confirmed. Move the record through each stage and inspect the message, task, alert, due time, and activity log. Confirm that completing the required touch closes the exception and that a customer reply changes the next checkpoint appropriately.

• Test a missing field and check that the rule routes it to the named owner instead of inventing a value.
• Test an agreed pause and stage change, confirming that the original message or reminder stops when it should.
• Run the same event again and verify that it does not create duplicate messages, tasks, or committed value.

Test the signed option against captured value and check that instructions name the correct logging destination. Write expected and observed results side by side. Fix every mismatch before enabling live contact, then retain the test record and instructions for the maintainer.

7. Review the cadence monthly with its owner

Why it matters: staffing, customer expectations, and pipeline stages change, so a once-useful rule can become a source of avoidable noise.

Review missed checkpoints, repeated alerts, unresolved tasks, and customer replies that the current rules do not handle well. Ask the team which messages help and which instructions require interpretation. Change the written standard first, then update and retest the affected rules so the document remains an accurate operating reference.

For practical help turning that standard into bounded automation, work with Vista through the AI Collective. Bring the cadence table and a real exception the team struggles to resolve. Aim for one checkpoint that fires predictably, with an owner and a tested path when it breaks.

COMMON QUESTIONS

Frequently asked questions

The cadence is the operating standard. These answers help you assign routine messages, distinguish alerts from reports, and check that signed value means what the owner expects. Use them to settle the workflow before building rules, then test those rules against the written decisions.

What is a follow-up cadence?

A follow-up cadence is the written contact standard for each pipeline stage. It defines the trigger, required touch, channel, owner, and maximum gap before another action is due. It also explains what counts as completion and when replies, pauses, or stage changes stop or reset the next checkpoint.

Should automation send messages or create tasks?

Send approved routine messages directly when the required information and stopping conditions are clear. Create a human task when the touch needs judgment, interpretation, negotiation, or a new commitment. Give that task an owner, due time, and linked record, instead of asking someone to retype a predictable message.

How is an alert different from a follow-up report?

An alert identifies a missed checkpoint while someone can still act on it. It names the affected record, responsible person, and next action. A report supports periodic review of activity and patterns. Use both when needed, but do not expect a report to perform the alert's immediate operating job.

When should we record committed deal value?

Record committed deal value when the customer signs the selected scope, using the confirmed option and agreed amount. Keep draft estimates and unsigned options separately labeled for pipeline planning. Handle later approved changes through a defined process, and keep sales commitment reporting distinct from the business's bookkeeping and recognition policies.

What should a dummy-record test include?

Test the expected trigger, message, owner, due time, alert, and activity record. Include missing information, customer replies, agreed pauses, stage changes, and repeated events. Confirm the rule stops irrelevant follow-up and avoids duplicates. Use an internal test contact, document expected results, and resolve mismatches before enabling live customer sends.

How often should we review follow-up rules?

Review the cadence monthly with its named owner and update it whenever the underlying process changes. Inspect recurring misses, noisy alerts, unresolved tasks, and replies the rules handle poorly. Revise the written standard first, then update and retest the affected automation so staff instructions and system behavior remain aligned.