Ops Rules That Run Themselves

"How long is too long to leave a guest waiting?" and "how long do we keep a resolved chat on file?" are both policy questions — and both should have one clear answer a system enforces, not a rule each shift interprets differently. Ops Settings let a manager set both once.

This is manager territory, not admin territory — Ops Settings covers conversation SLA defaults and chat data retention, the two policies that decide how the desk actually behaves day to day, separate from staff roles and sign-in configuration.

The whole configuration is four numbers a manager sets directly: guest waiting threshold (minutes before a message counts as "guest waiting"), overdue threshold (minutes without a staff reply before it's overdue), notification deduplication (how long before a repeat alert is allowed), and — separately — how many days a completed chat stays read-only before it's permanently deleted. No code, no ticket to engineering.

Here's what that threshold actually does: Priya Shah's towel request starts a timer the moment she sends it. At 8 minutes elapsed, it crosses into "guest waiting" — not an alert yet, just a status the desk can see, so a slow reply gets flagged well before it becomes a real problem.

If nobody replies by 20 minutes, the same conversation crosses into overdue — the point where managers can actually get alerted. Notification deduplication matters here: it stops the same overdue conversation from buzzing a manager's phone every single minute it stays open, while still keeping the alert live.

Data retention runs on its own separate, equally explicit timeline. A resolved chat stays fully editable history at first — staff can still open and reference it in full — then, per the policy window a manager set, it becomes read-only, and eventually it's permanently deleted: messages and attachments removed, unrecoverable, aligned to your actual compliance requirements rather than an indefinite default.

Set once, and the desk stays honest — response thresholds enforced consistently across every shift, and guest data retained on a real compliance timeline instead of forever by default. See how it fits your hotel's policies at heybutler.io.