Add Buying Signals to Sequences Already in Flight
TL;DR: Add a buying signal to an active sequence as a state transition, not as an extra email. Resolve the event, check contact and account eligibility, read the current sequence state, and choose one action: continue, change the next unsent step, pause for a rep, or suppress. Store an idempotency key so retries cannot create duplicate touches.
How do you add signal data without restarting an active sequence?
Keep the existing enrollment and delivered-message history. A new signal should change only future work. The orchestration layer first evaluates the event against the current record, then writes a single transition. It should never create a second active sequence merely because a buyer generated another event.
Unify Intent signals provides examples of signals that can enter an outbound workflow, and Automated plays is the workflow layer used to qualify and route actions. The decision rules below are a policy template: teams should set their own freshness windows, ownership rules, and suppression conditions.
| Signal | Interpretation | Confidence caveat | Sequence stage | Action | Suppression or stop rule |
|---|---|---|---|---|---|
| Pricing or high-intent page visit | The account may be evaluating a category or vendor | Account-level activity does not prove that a named contact visited | Not contacted or step 1 pending | Prioritize research, then enroll only an eligible person | Stop if no qualified person or if the account is already a customer |
| Repeated product-page activity | Interest may be strengthening | Shared networks, bots, and multiple visitors can blur identity | Early active sequence | Change the next unsent step to the relevant use case | Do not resend an earlier step or increase daily touch volume |
| Known contact attends an event | The person engaged with a declared topic | Attendance does not prove purchase authority | Mid-sequence | Pause automated copy and give the owner a context-rich task | Stop automation if the rep starts a live conversation |
| New executive or role change | Priorities and ownership may be changing | Title data can lag and scope cannot be inferred from title alone | Any active stage | Requalify persona and account ownership before continuing | Suppress if the record cannot be verified or territory is disputed |
| Funding, hiring, or expansion event | The account context may have changed | Company news is not proof of an active project | Early or mid-sequence | Update the account hypothesis, then continue only if the message still fits | Do not claim the event created budget or urgency |
| Reply, meeting, open opportunity, or opt-out | A higher-priority state now exists | The CRM and conversation owner must be current | Any stage | Hand control to the owner or compliance rule | Immediately stop overlapping automated outreach |
Use a six-step transition routine
- 1. Normalize the event: store signal type, source, observed time, ingestion time, account match, person match, and source event ID.
- 2. Re-read current state: fetch lifecycle stage, opportunity status, owner, suppression, active sequence, last delivered step, reply state, and next scheduled action.
- 3. Evaluate eligibility: apply customer, opportunity, territory, consent, recent-contact, and cooldown rules before changing anything.
- 4. Select one transition: continue unchanged, replace only the next unsent step, pause and create a task, or suppress.
- 5. Commit atomically: write the transition and its idempotency key before creating downstream tasks or enrollment changes.
- 6. Record the reason: save the event, policy version, prior state, chosen action, owner, and timestamps for review.
A safe implementation pattern
Use the following pseudo-logic as an implementation contract. Variables in square brackets are team-defined values, not universal benchmarks.
- If [SUPPRESSION_STATE] is active, return SUPPRESSED and do not schedule work.
- If [REPLY_STATE], [MEETING_STATE], or [OPPORTUNITY_STATE] is active, return OWNER_NOTIFY.
- If event observed time is older than [FRESHNESS_WINDOW], return STALE_NO_ACTION.
- If [EVENT_ID + CONTACT_ID + POLICY_VERSION] already exists, return the stored result.
- If the active sequence hypothesis still matches, return CONTINUE and update only internal context.
- If the hypothesis changed and no step is currently sending, return REPLACE_NEXT_UNSENT_STEP.
- If identity or ownership is ambiguous, return REVIEW_QUEUE.
The retry design follows the general principle described in Making retries safe with idempotent APIs: a stable request identifier lets the receiver recognize the same intended operation. For an outbound workflow, record terminal no-action outcomes as well as successful actions so a replay does not reopen suppressed work.
Roll out without over-messaging contacts
| Phase | Scope | Records to test | Success check | Failure check | Promotion rule |
|---|---|---|---|---|---|
| 1. Shadow evaluation | No sends or sequence changes | Known active, replied, opportunity, customer, opted-out, stale, and duplicate cases | Every event produces one explainable proposed transition | Any proposed touch violates ownership or suppression | Promote only after policy owners approve all expected outcomes |
| 2. Notify only | Create internal tasks or alerts | One controlled segment and one signal type | One owner receives one useful alert with source and time | Duplicate, unowned, or context-free alerts appear | Promote after duplicates and routing errors are resolved |
| 3. Next-step edits | Modify only unsent content | Eligible early-stage sequences | Delivered history stays intact and the next step reflects the new hypothesis | A contact receives an extra touch or prior content is rewritten | Promote after audit logs match actual changes |
| 4. Governed branching | Allow approved pause, continue, or replace transitions | Broader eligible segment | Each event follows the current policy version | Two branches or two enrollments exist for one event | Promote only with idempotency and rollback verified |
| 5. Ongoing audit | Review exceptions and policy drift | Sampled production events and every conflict | Suppression, owner, and state precedence remain correct | Unknown transitions or unexplained sends appear | Pause the affected path and investigate |
What to change in the message
Use the signal to refine relevance, not to reveal surveillance. Replace a generic next step with the business problem suggested by the event. Do not say that a particular person visited a page unless person-level identity is both verified and appropriate to use. Do not turn a weak account event into certainty about budget, authority, or timing.
- Use: "Teams revisiting [WORKFLOW] often need to decide [DECISION]. Is that relevant to your group?"
- Avoid: "I saw you visited our pricing page three times."
- Use: "Your team's public [HIRING OR PRODUCT CHANGE] suggests [HYPOTHESIS]. Is [ROLE] responsible for this?"
- Avoid: "The new funding means you now have budget for us."
Incident stop rules
- A contact receives two active enrollments after one signal.
- A reply, opt-out, customer state, or open opportunity fails to suppress the transition.
- The workflow cannot distinguish event time from ingestion time.
- The account or person match is ambiguous.
- The audit log does not show the prior state, policy version, and chosen action.
- A retry creates a second task, alert, or sequence change.
How Unify fits
Teams can connect signals, qualification, owner routing, and Multi-channel Sequencing in a Play. The useful operating design is explicit: signals supply evidence, policy determines eligibility, and the current sequence state determines whether the system continues, changes, pauses, or stops.
Start using Unify to coordinate signals, Plays, sequencing, and CRM context in one governed workflow.
Frequently asked questions
Should a new signal start a second sequence?
No. Read the current enrollment first and change only future work. Create a new sequence only after the existing motion is closed and policy explicitly permits a new enrollment.
What should happen after a reply?
The human owner takes precedence. Stop automated transitions and route useful signal context to that owner.
How do you prevent a retried signal from sending twice?
Create a deterministic idempotency key, store the result before downstream actions, and return the stored result on a retry.
Can account-level intent identify the right person?
No. Use account-level intent to prioritize research, then qualify the appropriate people separately.
Which timestamps matter?
Store observed time, ingestion time, evaluation time, and action completion time.
What is the safest first rollout?
Run in shadow mode, then notify only. Allow sequence changes only after ownership, suppression, duplicate handling, and rollback are verified.
Sources
- Unenroll contacts from a sequence, HubSpot Knowledge Base, accessed September 2026.
- Making retries safe with idempotent APIs, Amazon Web Services, accessed September 2026.
- Intent signals, Unify, accessed September 2026.
- Automated plays, Unify, accessed September 2026.
- Multi-channel Sequencing, Unify, accessed September 2026.
