Follow-ups still chasing a client who already paid: the state gap

The email is correct according to the system that sent it. The sequencing tool believes the quote is outstanding because nothing ever told it otherwise, and it has no way to know that money arrived in a different system 3 days ago. That is the whole fault: quote state exists in 2 places, and the copy that drives outbound messages is the one nobody updates.

How often to chase, and on what schedule, is a different question with a different answer — it belongs with departure dates rather than with days since the quote, as booking lead time and chase cadence sets out. This page assumes the cadence is fine and asks why it does not stop.

The check: ask every system what state it believes the trip is in

Three booked enquiries is enough. Pick ones where the deposit landed at least a week ago, and interrogate each system in the chain separately rather than trusting any single dashboard.

1. Record what each system says, in its own words, with the timestamp of its last write to that record.
2. Note the key each system matched on. Where 2 systems match on different keys, you have found the join that will fail on the awkward bookings.
3. Trace the event that should have moved the sequencer. Look for it in the integration log, then in the provider's webhook delivery log, then in the failed-delivery queue.
4. Check whether the exit condition exists at all. In a large share of these cases, the sequence has entry criteria and no exit criteria, which is a configuration nobody ever revisited.
5. Look at the messages already scheduled for that client. If any are queued for a future date, find out whether the tool re-checks anything before sending them.
6. Repeat for a client who cancelled and a client who went quiet, because those 2 states usually reveal a second gap the booked case hides.

Six causes, ranked by frequency

The state vocabulary, and why it must be an allow-list

Write down every state a trip enquiry can be in, once, in one place: received, qualified, quoted, revised, awaiting client, awaiting supplier, deposit paid, confirmed, departed, returned, cancelled, lost. That list is the contract every other system reads.

Then express the chase rule as an allow-list — a sequence may run only while the enquiry is in quoted, revised or awaiting client — rather than as a deny-list of states that stop it. Deny-lists fail the first time somebody adds a state. Awaiting supplier is the usual casualty: a consultant is waiting on a lodge to confirm, the enquiry is not in any of the stop states, and the client receives a nudge about a quote that is currently unbookable.

Automation does not create a split brain between your systems. It just forwards it to your clients, on a schedule, in writing.

Evaluate the exit at send time, not at enqueue

This is the cause that survives every other fix, because the wiring looks correct when you inspect it. A sequencing tool that schedules step 3 for next Tuesday has already decided to send it. If the client pays on Sunday, the exit fires, the sequence is marked complete, and the message still goes out on Tuesday because it was handed to the mail provider days earlier.

• Re-evaluate the condition at dispatch. Nothing should leave the system without one final read of current state, however cheap the check looks to skip.
• Schedule only the next step, never the whole sequence. A queue holding 5 future messages per client is 5 decisions made on stale information.
• Make queued messages cancellable and prove it. Book a test enquiry, pay a deposit, then confirm the pending send disappears rather than assuming it did.
• Watch the send window. A message released at 09:00 in the client's local morning was decided the previous evening, and deposits land overnight — the timing reality worked through in an enquiry arrives at two in the morning.
• Check what the message renders. A chase that embeds the quote from a saved template rather than from live components will restate a price that has since changed, which is the drift argued in templates or a component library.

The booker, the traveller and the payer are often three people

Matching on email address works until it does not, and the cases where it fails are exactly the high-value ones: a couple sharing an address, an assistant booking for an executive, a parent paying for an adult child's honeymoon, a trade agent booking on behalf of a client. The deposit arrives under a name the sequencer has never seen, so nothing matches and the chase continues to the person who thought they had just booked a holiday.

• Key everything on the enquiry id. Email, phone and name are attributes of a person, not identifiers of a deal.
• Record the payer separately from the lead traveller and the booker. All 3 roles can be different people on the same trip, and only 1 of them made the commercial commitment.
• Do not suppress at person level. Someone planning 2 trips genuinely has 1 live quote and 1 booked trip, and a person-wide stop silences a chase that should still be running.
• Reconcile unmatched payments daily. A deposit that matched no enquiry is both a chase you are about to send wrongly and an operations problem nobody has noticed yet.
• Send from the current owner. After a reassignment the sequence should adopt the new consultant's identity, which is why ownership has to be a field on the enquiry rather than a setting in the sequencer — the model set out in assigning enquiries by destination and load.

One enquiry, one sequence — however many quotes it produced

A tailor-made trip often generates 3 priced options and 2 revisions of the one the client liked. Where a sequence is attached to each quote, accepting a quote exits that quote's sequence and leaves the others running, so the client who has just paid for the Kenya itinerary receives a nudge about the Tanzania alternative they declined 3 weeks ago. The fix is structural rather than clever: the conversation belongs to the enquiry, the priced options belong to the itinerary, and only 1 of those objects is allowed to talk to the client.

Decision tree

1. Sequencer state is weeks stale. There is no exit condition. Emit a booking event from the system that holds the money and wire the exit to it. This is the fix in most of these cases.
2. Chases stop, but only near departure. The exit is on the final balance. Move it to the first payment or the signed confirmation, whichever is earlier.
3. Exactly 1 extra message arrives after the state changed. The condition is evaluated at enqueue. Re-check at dispatch and stop scheduling more than 1 step ahead.
4. Only unusual bookings are affected. The join is on email address. Re-key on the enquiry id and add a daily unmatched-payment report.
5. The client receives chases for options they declined. Sequences are attached to quotes. Collapse to 1 sequence per enquiry.
6. Everything is wired and it still happens. Two systems still hold state. Make the booking record authoritative, give the sequencer read-only access, and delete its own state field so it cannot drift again.

The work is small and it is mostly plumbing with alarms on it: one event, one authoritative record, a dispatch-time check and a reconciliation report — the kind of automation that runs on data the operation already emits rather than a new tool. Where the chase itself needs to become smarter than a fixed cadence, that is bounded AI agents and automation work, and it should sit on top of a state model that is already correct. The rest of the funnel sits under from enquiry to confirmed booking, inside our travel and tourism practice.

• follow-up automation
• quote state
• integration
• sales operations