Follow-up delay calculation: verify the interval from the actual send

Define the decision

Timing disputes often begin with a spreadsheet that assumes every first touch went out at launch. Capacity restrictions or a connection problem can delay individual contacts. If later steps follow actual progression, their schedules also differ. Start with one contact's history rather than averaging across the entire campaign.

Work through the procedure

1. Record the prior step's observed send outcome and timestamp, the next step's configured delay and the stored next due time when available.
2. Calculate the nominal interval using the application's documented unit. Do not translate 'two days' into 'two business days' without evidence.
3. Apply the campaign's allowed window and days to explain why an eligible send may happen after the nominal due time.
4. If the timestamps still disagree, preserve the example with timezone labels and ask the operator to inspect progression logic before editing the sequence.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Timing comparison
Planned launch: Monday morning
Contact's first message accepted: Tuesday afternoon
Worksheet assumption: follow-up based on Monday
Observed enrollment: later due time
Investigation: compare configured delay with Tuesday's accepted event, then apply the window

Read the result

A later date is not automatically a scheduler defect. The comparison must use the same event and clock as the implementation. Conversely, if the next step predates the accepted event or ignores the intended unit, that is a concrete discrepancy worth investigating. Preserve the evidence instead of repeatedly rescheduling the contact.

Check before moving on

1. Label every recorded timestamp with its timezone or UTC designation.
2. Check one ordinary interval and one interval crossing an excluded day.
3. Review whether a delayed follow-up still contains a truthful relative-date reference.

Limits and next action

This procedure avoids promising an exact delay formula for every sequence editor state. Zintara's due work remains subject to sending windows and delivery controls. Verify the current saved sequence and contact progression when changing delays in an existing campaign; a visual preview is not a historical send ledger.

Source: Zintara sequence product context