Quote follow-up stop rules.
Test the interruption.

The question we tested

Can a queued reminder send twice, or resume after a customer response, when actions arrive in different orders? We tested the deterministic state model used by RevSet’s public customer-journey simulation. This is first-party technical evidence about that model only.

The result

625 complete four-action sequences passed the specified assertions, covering 780 state transitions. The actions were run reminder, customer reply, opt out, owner pause, and owner resume. The test starts from a fresh follow-up state and explores every ordered combination of four actions, including repeated actions.

There are five choices at each step: 5 × 5 × 5 × 5 = 625 complete sequences. The recursive traversal checks 5 + 25 + 125 + 625 = 780 transitions. Those are test counts, not customers, messages delivered, or bookings.

Four rules checked at each transition

1. The send count never decreases and never exceeds one for this one-reminder model.
2. Running a held or already processed reminder does not increase the send count.
3. An opt-out remains a stop condition after every allowed action.
4. An owner resume action does not clear a customer-reply hold.

Walk through the interruption

Reply → run reminder

A customer asks to remove part of the scope. The reply sets a hold. Running the scheduled reminder should leave the send count unchanged. A person handles the scope question before deciding on the next sequence.

Pause → resume → run reminder → run reminder

An owner may release their own temporary pause. The first eligible run can process the reminder; the repeated run should not send it again. This model tracks a single reminder, so a future reminder would require its own identity and eligibility rules.

Opt out → resume → run reminder

A generic resume action must not remove the opt-out. The scheduled reminder remains suppressed. Any change to contact eligibility in a real system needs its own authorized process.

Reproduce the result

Download the two files below into the same folder. Rename customer-model.js to customer-model.mjs, then run the test with Node.js 20 or later. It uses Node’s built-in assertion module and does not call a CRM or messaging service.

Download the tested model · Download the test · Download the result and model SHA-256

node check-followup-rules.mjs

The result file records the tested model hash and execution timestamp. A changed model requires a new run; passing a prior revision does not establish behavior of a later revision.

What this test does not establish

It does not test real provider delivery, webhook timing, simultaneous production workers, database writes, retries across servers, or a customer’s installed CRM. It does not establish that a message already handed to a delivery provider can be recalled. Passing these assertions does not prove every property of the model or guarantee a deployed system will behave the same way.

What to test in an actual implementation

Use the real quote identifier, opportunity state, and message job. Deliver a reply just before the send, replay an event, and simulate an unavailable provider. Confirm which component owns the final eligibility check and how concurrent workers avoid processing the same job twice. Record the actual outcome and any timing window the integration cannot close.

Your acceptance evidence should include expected behavior, observed state, owner alerts, and recovery steps. Keep customer data out of public test reports unless its use is authorized.

Try the public customer-journey simulation ↗ · Read the follow-up design guide ↗

Apply this to your quote process

RevSet scopes quote follow-up implementations around approved messages, record ownership, and stop rules. Bring the point where your current sequence loses track of the customer’s decision.