agent's sequence sent 7 emails in 9 days because the wait step was configured in hours instead of days

TL;DR

Validate every wait step's unit before a sequence goes live, and add a pacing guardrail that caps sends per lead per week regardless of what the steps say. A unit mismatch turns a 9-day nurture into a 9-hour blast; the guardrail catches it even when the config is wrong.

agent's sequence sent 7 emails in 9 days because the wait step was configured in hours instead of days

Steps

1. Audit every wait step in the sequence: read the number AND the unit out loud in review ("wait 72 - hours or days?"), and fix any mismatches. Expected: a reviewed list of all wait steps with explicit units, signed off before launch.

2. Add a pacing guardrail above the sequence logic: no lead gets more than N touches in any rolling 7 days, enforced at send time no matter what the steps request. Expected: a test sequence with hourly waits gets throttled by the guardrail, and the throttle events are logged.

3. Make wait-step units unambiguous in the builder - a dropdown of hours/days/weeks rather than a bare number field, with days as the default for nurture sequences. Expected: new wait steps cannot be saved without an explicit unit, and the default is the safe one.

4. Dry-run the sequence on test leads and check the actual send timestamps before launching to real leads. Expected: the dry run's timestamps show the intended spacing, verified against the plan.

5. For leads already over-contacted, pause the sequence, give them a rest period, and have the next touch acknowledge the burst briefly rather than pretending it did not happen. Expected: affected leads are paused, and the resume plan includes a cooling-off gap.

Use this when

• a sequence sends much faster than intended due to unit or config errors
• wait steps use hours where days were meant (or similar mismatches)
• you need a backstop against pacing misconfiguration

Not for this skill when

• the fast pace was intentional - that is a strategy choice, not a bug
• sends are throttled by the provider's rate limits - see the rate-limit skills
• leads get too many touches from overlapping sequences - that is a cool-down problem

Variant phrasings

• wait step configured in hours instead of days
• sequence sent 7 emails in 9 days
• pacing unit mismatch caused an email burst
• nurture sequence fired all steps in hours

Why it happens

Sequence builders accept a number and a unit separately, and the unit defaults to whatever the last person used - often hours, from testing. "Wait 3" means three days in the builder's head and three hours in the config. Nobody notices until the leads do, because the sequence "works" - it just works far too fast.

Edge cases

• Business days vs calendar days: a "wait 2 days" over a weekend lands differently - decide which one your steps mean and document it.
• Timezone differences compress perceived spacing - the guardrail counts actual sends, not intended ones.
• A lead replying mid-burst should pause the sequence - the guardrail limits sends, but replies should stop them entirely; see the stop-on-reply skills.
• Reused sequence templates carry old wait configs - re-validate units every time a template is cloned for a new campaign.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ujTO3m792gHWpahliD7dBQ