By Siddharth GangalA SaaS sales cadence is a controlled state machine that decides whether an account-contact pair is eligible, which entry path applies, what action is authorized, how replies and exceptions change state, and when the motion must pause or stop. It is not a universal number of touches or a fixed calendar. Timing and channel choice follow buyer state, consent, suppression, platform rules, sender health, account ownership, and the decision the next action is meant to support.
What a SaaS sales cadence must control
The cadence control plane should answer six questions for any proposed action: Why did this contact enter? What buyer state is currently supported by evidence? Which system and owner have authority? Is the action permitted now? Which event advances or stops the motion? What happens if the event arrives twice, late, or in conflict?
SaaS-specific design matters because one company can enter through several product and commercial paths: a cold account hypothesis, an inbound request, product or owned-property behavior, a referral, reactivation, or an active opportunity. Those paths carry different evidence and expectations. Combining them into one “prospect” queue makes a hand raiser receive cold messaging or a current opportunity receive an automated breakup message.
Do not define success as sending every planned step. A cadence succeeds operationally when it respects authority and preferences, produces a correctly classified state, and hands the buyer to the right human or next workflow. A stop, suppression, deferment, or no-fit state can be correct.
Separate orchestration from messages and channels
This page owns SaaS cadence orchestration by buyer state. The generic sales cadence guide owns foundational construction. The cold email sequence guide owns email content, while the multichannel cadence guide owns channel-mix execution. The follow-up sequence owns cold, warm, post-meeting, and demo message patterns.
Detailed testing belongs in sales cadence A/B testing; detailed channel obligations and infrastructure belong in cold email compliance and cold email deliverability. Measurement belongs in sales cadence metrics, and platform exit in the cold email platform migration checklist.
The orchestration layer references those artifacts but does not duplicate them. It decides when a message or channel action is eligible, which state it can produce, and which invariant controls must hold.
Choose the entry path before the steps
Entry evidence determines the first useful decision. Do not treat a public event, website event, form submission, product event, referral, and prior relationship as interchangeable “intent.” Record source, as-of time, identity confidence, scope, permission, owner, and what the event does not prove.
| Entry path | Evidence available | First decision | Hard boundary |
|---|---|---|---|
| Cold account selection | Documented fit hypothesis and approved contact source | Is a relevant, permitted first contact justified? | Public facts do not prove need or consent |
| Inbound hand raise | Specific request, form, channel, and timestamp | Who owns a response to the stated request? | Do not replace the request with a generic nurture |
| Product or owned-property event | Event name, actor mapping, context, permissions | Is human outreach appropriate for this event? | Behavior does not prove identity, intent, or purchase authority |
| Referral or introduction | Introducer, wording, parties, permission | What contact did the recipient agree to? | Do not expand beyond the introduction's scope |
| Reactivation | Prior state, last interaction, preference, reason closed | What new evidence warrants reconsideration? | Prior conversation does not erase suppression |
| Active opportunity | Buyer-owned next step, participants, open decision | Which human-owned action advances that decision? | Exit prospecting automation before opportunity follow-up |
Entry rules should be deterministic enough to test. “High intent” is not a rule. “Submitted the named demo form, identity matched to the CRM contact, no global or channel suppression, no active opportunity, routed to the territory owner” can be replayed against known cases.
Build the account-contact state machine
Track both account and contact state. One contact's reply can affect the whole account; one account's active opportunity can suppress every prospecting sequence. Define state, allowed actions, transition event, evidence, owner, and exit.
| State | Allowed behavior | Example transition evidence |
|---|---|---|
| Ineligible | No enrollment | Missing fit, identity, owner, permission, or required field |
| Eligible | Queue after all gates pass | Approved entry record and current suppression check |
| Queued | Await authorized action | Owner, channel, template version, and scheduled event |
| Active | Run one controlled path | Action accepted by channel plus current state version |
| Engaged | Stop automation; route human review | Verified reply, connect, booking, or buyer interaction |
| Deferred | No action until a named condition | Buyer timing, out-of-office return, owner task, or approved event |
| Suppressed | No prohibited action | Opt-out, do-not-contact, channel restriction, account conflict |
| Closed | No automatic restart | No fit, exhausted hypothesis, duplicate, invalid identity, or handoff |
Give transitions unique event IDs and state versions. An action should verify that the expected prior state is still current. If a reply and scheduled send race, suppression or engagement wins. If the same webhook is replayed, the action should not happen twice. If an old event arrives after a newer state, quarantine it rather than moving backward silently.
Set authority, consent, and suppression precedence
Choose one orchestration authority for enrollment and state change. Email, dialer, LinkedIn task, CRM workflow, and rep calendar can execute actions, but they should not independently decide that the contact is eligible. Define the CRM or another named store as the authority for owner, account conflict, opportunity, and global suppression fields.
Evaluate permission and suppression before enrollment and immediately before every action. Use precedence: legal or policy prohibition, recipient opt-out or do-not-contact, channel suppression, active customer or opportunity conflict, account-owner hold, invalid identity, then cadence eligibility. A lower-priority trigger must never override a higher-priority stop.
For US commercial email, the FTC's CAN-SPAM compliance guide says the law covers commercial messages, including business-to-business email, and gives recipients the right to stop commercial email. That is a US boundary, not a global permission model. Build a jurisdiction and message-purpose review with qualified owners.
Provider and platform rules are separate gates. Google's current Gmail sender guidelines define requirements and guidance for mail to personal Gmail accounts, including authentication and unsubscribe requirements that depend on volume and message type. They can change and do not guarantee delivery. LinkedIn's current User Agreement prohibits bots and other unauthorized automated methods to access the service, add contacts, send or redirect messages, or drive engagement. Keep LinkedIn actions human and within currently approved product behavior unless the platform expressly authorizes another method.
Calling applicability also varies. The FTC Telemarketing Sales Rule guide describes scope, exemptions, disclosures, prohibitions, privacy protections, and records for covered US telemarketing. Many B2B calls are exempt from parts of the TSR, while other federal, state, or jurisdictional requirements may still apply. Do not encode “B2B” as a universal permission flag.
Route replies and exceptions without duplicate actions
A reply is a state-changing event, not merely a positive or negative metric. Preserve the original message, sender, recipient, thread, timestamp, identity match, automated classification, reviewer, final label, and resulting action. A model can propose a label; a human should review ambiguous or consequential branches.
Useful reply branches include:
- Interested or question: stop automation, assign owner, preserve context, respond to the actual request.
- Referral: stop the original path, verify permission and identity for the introduced person, create a new entry record.
- Timing or out of office: defer to the buyer-stated condition; do not invent a generic restart date.
- Not relevant or no fit: close the hypothesis and record reason without manufacturing another angle.
- Opt-out or do not contact: apply the appropriate suppression atomically before acknowledgment or future actions.
- Automated, bounce, or invalid identity: stop the channel, investigate source and relationship, do not reroute blindly.
- Existing customer or active opportunity: stop prospecting and transfer to the authorized owner.
Exception queues need service ownership, not just alerts. Cover missing owner, conflicting CRM records, duplicate account, reply without a thread match, suppressed contact in a scheduled batch, provider rejection, expired token, CRM outage, channel permission change, and manual rep action outside the sequencer.
Experiment on states, not vanity touch counts
Write an experiment card before changing the cadence. State the buyer-state hypothesis, eligible population, assignment unit, variant, invariant controls, primary decision measure, guardrails, observation window, exclusions, analysis plan, and rollback condition.
Assign at the account level when contacts within an account can influence one another or when an opportunity state suppresses all contacts. Prevent the same person, domain, or account from entering both variants through another list or platform. Record template, wait-rule, channel, eligibility, and routing versions so the treatment is reproducible.
Consent, suppression, account conflicts, identity checks, and provider/platform rules are invariants, never experimental relaxations. Measure branch accuracy, duplicate-action rate, suppression latency, reply routing, human workload, delivery or connect signals appropriate to the channel, and the downstream buyer decision. Do not interpret an open event as proof of reading or a reply as proof of purchase intent.
The detailed statistical design belongs in the A/B testing canonical. This page's role is to ensure the experiment cannot corrupt the state machine or silently expose the same buyer to competing treatments.
Test, release, monitor, and roll back
Create a synthetic QA corpus with expected states and actions. Include duplicate enrollment, shared email, multiple contacts at one account, owner change, new opportunity, late opt-out, reply/send race, out-of-office, referral, bounce, wrong identity, provider deferral, platform permission failure, expired credential, CRM outage, replayed webhook, and rollback during an active batch.
For each case verify:
- one authoritative state and one current owner;
- correct eligibility and suppression precedence;
- idempotent event handling and no duplicate action;
- correct message, channel, sender, timezone, and template version;
- reply classification, human-review route, and account-level effect;
- CRM write, audit event, error state, retry, and recovery;
- rollback that stops future actions without losing evidence.
Release to a bounded population with named owners and a one-authority rule. Shadow-evaluate enrollment before enabling sends. Monitor provider responses, suppressions, conflicts, duplicate actions, routing latency, exceptions, manual overrides, and state reconciliation. A kill switch should pause queued actions without erasing the audit trail.
Review cadence health as a control system
Review the state distribution and transition integrity before discussing conversion. How many records are ineligible, queued, active, engaged, deferred, suppressed, closed, or stuck? Which transitions lack evidence? Where do CRM and sequencer disagree? Which reply branches wait for an owner?
Segment by entry path, buyer state, source, owner, account cohort, channel permission, and experiment version. A blended rate can hide that inbound requests are routed correctly while reactivation contacts are duplicated. Reconcile state counts to source records and investigate missing or impossible transitions.
Gangly's first-party boundary is limited: Gangly offers sales workflow software, but this article does not assert a reply, conversion, time, deliverability, or revenue outcome; product superiority; or universal platform behavior. Any Gangly-assisted cadence should pass the same permission, authority, state, QA, and rollback controls.
Printable SaaS cadence state specification
The durable cadence is not the one with the most steps. It is the one that can explain why each action was allowed, which buyer state it addressed, what event changed that state, and how the team stopped safely when the evidence changed.