You sent three messages. The reminder was not the real problem.

When a guest has not completed a required pre-arrival step, the problem is not always a missing reminder. Sometimes the sequence keeps moving regardless of what the guest has actually done.

A host sends the conditions and asks for confirmation. Silence. A second message goes out. Then a third. Check-in keeps getting closer and the work stays the same: check, remember, chase.

A fourth message, even when automated, does not change the logic. It is simply a more punctual reminder.

Chronological and conditional are not the same

Many stay communications work perfectly on time: confirmation, practical information, arrival guidance, checkout reminders.

But when a step requires a guest action — such as a signature, check-in data, an explicit confirmation or documents required by the process — time alone is no longer enough.

A chronological sequence says: **one day has passed, send the next message**.

A conditional sequence says: **the previous step is complete, so the next one can become available**.

That is a small logic change with a large operational effect.

This is not about blocking the guest

The boundary matters.

Conditional logic makes sense only for steps with a verifiable state: complete / incomplete. It should not be used to withhold useful information, create pressure or turn the stay into a series of obstacles.

Information needed to understand the property, orient oneself or ask for help should remain available.

Where sensitive or operational information can appropriately be shown only after a genuinely required and clearly disclosed step is complete, visibility can follow the process state — provided the requirement was communicated in advance and a human fallback exists for technical failures or exceptional cases.

What the guest should see

A badly designed conditional sequence feels like a wall.

A good one shows the real status:

Some check-in details are still missing. As soon as this step is completed, the next information will appear here.

No threat. No punitive tone. No last-minute surprise.

The guest needs to understand three things: **what is missing, why it is needed and what happens next**.

The real benefit: less chasing, not more automation

The point is not to automate the relationship. It is to remove from the human relationship the things that can be represented as a state.

Signature completed. Data received. Conditions confirmed. Step closed.

Those are operational events. Tone, welcome, exceptions and real problems remain human. The same boundary appears in Automate the repetitive, not the relationship with your guest and You write house rules for the 10%. The other 90% are the ones who read them..

How this applies to StayFast

StayFast starts from a different idea than simply sending messages: the Stay Hub is a space the guest opens during the stay, so the question is not only **when to send something**, but **what should be visible right now**.

In the Flow path, where structured check-in, document or confirmation steps are used, this principle can be applied to requirements: clearly show what is still incomplete and make later steps available when the process state allows it.

This does not mean arbitrarily withholding access or claiming automation that is not active. It means designing the flow so the system can distinguish what is complete from what still requires attention.

If a specific gating feature is not available in a property's current setup, StayFast still provides an important advantage: one place where status, instructions and stay steps are not scattered across chats and separate reminders.

Where to start

• **List the steps that require a guest action.** Signature, data, documents, confirmations.
• **Separate time-based steps from status-based steps.** Not everything should become conditional.
• **Write the status the guest should see.** What is missing, why it matters, what happens next.
• **Keep a human fallback.** A technical error should never leave a guest stranded without assistance.
• **Reduce reminders; do not remove them by principle.** One timely reminder may still help. Three manual chasers do not.

The rule that prevents most mistakes

Before automating a step, ask:

**does this depend on time or on a state?**

If it depends on time, schedule it.

If it depends on a state, show the state.

If it depends on a person, do not turn it into an automation.

Conclusion

The problem with the three messages was not the absence of a fourth.

It was that none of them changed what would happen next.

A good pre-check-in sequence does not simply send more messages. It separates time from state and gives the guest a clear, readable and recoverable path.