--- updatedAt: 2026-08-25T21:38:07.000Z --- Fetch the complete documentation index at: https://docs.lodgestory.com/llms.txt. Use this file to discover all available pages before exploring further. Append .md to any documentation page URL to get its markdown version. # Automations **Products › Lodgestory CRM › Settings › Automations**
# Automations > With Automations, things that used to depend on someone remembering happen by themselves: a call ends and the caller gets a satisfaction survey, a chat closes and feedback is collected, a bad score opens a ticket for your recovery team — each after exactly the delay you choose. > **TL;DR** > > * **What it is:** Rules of the form "when something happens → only if conditions match → wait → then act": send surveys or messages, open tickets, assign chats or route them to a team's queue, pull the next waiting chat to an advisor who just freed up, add labels, set reminders, notify your team, or call your own API. > * **Who it's for:** Admins and owners (automations act on your customers unattended, so setting them up is an admin decision). > * **Top outcome:** Follow-ups that never get forgotten — with a run log that shows exactly what happened, and what deliberately didn't. ## At a glance | | | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Plan tier** | All plans — the number of active automations and monthly runs depends on your plan | | **Who can use it** | Admins and owners (create, edit, enable); all members can view automations and their runs | | **Channels** | Messages go out on the conversation's own channel (WhatsApp, Instagram, Messenger, email, web chat) | | **Integrations** | Surveys & CSAT, Tickets, Chat assignment (capacity-aware, with team queues), Labels, Follow-ups, Notifications, and your own systems via **Call your API** | | **Limits at a glance** | Active-automation and monthly-run quotas per plan; per-customer daily message caps; per-rule hourly run ceilings | | **API available** | Runs are visible in the CRM; the `survey.response_submitted` webhook carries scores for external systems | ## How to get there **Sidebar › Settings › Workflows › Automations** **Direct URL:** `app.lodgestory.com/crm/settings/automations` ## What is Automations? Every automation has the same shape: 1. **When** — the moment that starts it: a call completed or missed, a chat resolved or reopened, **a chat handed to an agent** (a bot transfer or a manual assignment), **a chat routed to a team** (even when nobody picked it up yet — or nobody had capacity to), a workflow attached or moved to a stage, a ticket created/resolved/assigned, a survey response submitted, a customer message with no reply, a channel disconnecting, a template's approval changing — or a daily/weekly schedule for internal digests. 2. **Only if** — conditions on that moment: *inbound calls with more than 30 seconds of talk time*, *survey score in the detractor band*, *chat has the VIP label*. 3. **Wait** — minutes, hours or days. Waits can shift to your business hours, so a survey for a 11:50 pm call goes out next morning, not at midnight. 4. **Then** — one or more actions, each with its own optional condition that is re-checked right before it runs. That re-check is what makes "send a survey 30 minutes after a chat closes — but only if it's still closed" actually mean what it says. Each time the trigger fires for someone, that's a **run**. Runs are listed with a full step-by-step timeline: what ran, what was skipped and why, what was suppressed by a protective cap, what failed. ## Start from a recipe The fastest way in is a **recipe** — a prebuilt automation with safe defaults already set. Pick one, fill in the blanks it can't know (which survey form, which team), publish, switch it on: * **Post-call CSAT** — answered inbound call → 5 min → survey * **Post-chat CSAT** — chat resolved → 30 min → survey (cancels itself if the chat reopens) * **Post-ticket CSAT** — ticket resolved → 1 h → survey * **Post-workflow CSAT** — workflow reaches its final stage → 30 min → survey (stands down when finishing the workflow also resolved the chat — Post-chat CSAT covers that, so the guest never gets two) * **Detractor recovery ticket** — low score → high-priority ticket to your recovery pool + team alert, instantly * **Escalate a floor score** — rock-bottom scores alert leadership directly * **Promoter review request** — happy scores (and only happy scores) get a review link * **Missed-call catch** — missed call → 2 min → "sorry we missed you" + a callback reminder for the agent * **Survey abandonment nudge** — survey unanswered after 24 h → one gentle reminder * **No-reply escalation ladder** — customer waiting 5 min → nudge the assignee; 15 min → hand the chat to a *different* available agent * **Unanswered handover watchdog** — a chat was handed to an agent (bot transfer or manual) and they never replied: nudge the owner at 5 min, send the customer a holding message at 15. The clock starts at the handover itself, so it catches customers who wait silently; it stands down if the agent replies or resolves the chat * **Team routed, nobody picked up** — a chat was routed to a team but no individual owner was selected (off-hours, nobody available): retry the assignment after 10 min and push-alert the whole team if it's still unowned * **Unowned workflow catch** — workflow chat unassigned after 10 min → assign from a team * **Channel disconnected alert** — a channel drops → every admin is alerted immediately * **Pull the next waiting chat when an advisor finishes one** — workflow reaches its final stage → the oldest chat waiting in that advisor's team queue is handed to them, while they're under their cap * **Dispatch waiting chats when a customer writes again** — a message lands on a chat that's routed to a team but has no owner → sweep that team's queue into members with spare capacity * **Dispatch waiting chats every hour** — hourly sweep of every team queue; the safety net after caps were lowered or switched off * **Returning guest, owner unavailable** — a guest writes to a chat whose owner is offline or on a break → rotate it to an available teammate with capacity and tell them * **Returning guest, owner at capacity** — the same, when the owner is at their open-chat cap * **Queue overflow escalation** — a chat routed to a team that nobody could take: after 15 min also route it to a fallback team, after 30 min alert every admin; stands down as soon as someone owns it ## Capacity & queues Automations share the inbox's routing rules, so it helps to know them: * **Caps.** Under **Settings → Team Members** an admin can set an organisation-wide *max open chats* per advisor and override it per person (0 = online but never auto-routed — handy for supervisors). An advisor's load is the chats where they're the primary assignee, not resolved or archived, not on autopilot, not a group, and on a live workflow, with a message inside the organisation's **activity window** (default 14 days, set on the Team Members page). Finishing a workflow or resolving a chat frees a slot — and so does the guest going quiet for longer than the window, so stale chats nobody closed stop counting; the same window bounds team queues. * **Queues.** Automatic routing — team round-robin, the assign-chat action's team modes, bot-journey team transfers — skips advisors at their cap. When nobody on the team is eligible, the chat stays routed to the team with no owner: the **team queue** (*Unowned* in the inbox). "Chat routed to a team" fires either way; "chat handed to an agent" only once someone owns it. Caps govern automatic routing only — an advisor can still claim a queued chat, and admins can assign past a cap. * **Actions.** *Assign chat* has four modes: **Specific** person, **Team round-robin**, **Rotate** (a different available teammate than the current owner) and **Route to team** (`TEAM_ROUTE`) — attach a team so everyone sees the chat and pick a primary if anyone has capacity, else leave it in the queue. The team can be left blank for round-robin and rotate to mean "the chat's own teams". *Pull next chat* (`PULL_NEXT_CHAT`) has two scopes: **Freed agent** hands the trigger chat's owner the oldest chat waiting in their teams' queue while they're under their cap (use it on "workflow reached its final stage" or "chat resolved"); **Team sweep** drains a team's queue (or the trigger chat's teams, or every team) across every available member with spare capacity — from a customer message, a routed-to-team wait, or a schedule. * **Conditions.** *Owner is available* and *Owner is at capacity* (`chat.primaryAssigneeAvailable`, `chat.primaryAssigneeAtCapacity`) let a rule re-route a returning guest only when the owner can't respond; *Contact origin* (`MANUAL` or `DISPOSITION`) lets a welcome rule skip contacts that were auto-created while an advisor captured a disposition mid-conversation. * **Timing.** Rules triggered by "chat handed to an agent" must wait at least a minute before assigning or pulling; pulled assignments are automation-sourced, so a watchdog on that trigger only sees them when its settings allow automation-sourced events. ## Before your first customer-facing automation Two one-time settings under **Automations › Settings**: * **Act as (service account):** the account automated messages are sent as — the name your customers see. You pick it explicitly from your workspace's service accounts; an automation that messages customers cannot be switched on until you have. Create service accounts under Team Members. * **Protective caps:** at most N automated messages per customer per day (across ALL automations — three individually sensible rules reaching one customer in an hour is spam), and a per-automation hourly ceiling that pauses a runaway rule and alerts every admin. There is also a **suppression list**: anyone on it never receives automated messages, whatever any rule says. ## Guardrails you get without asking * **No 3 am messages** — waits can shift into business hours (and quiet-hours releases are spread out, not blasted at 9:00:00). Quiet hours hold back *messages to customers*, not internal work: a late-night missed call still raises its ticket and pings the team straight away. * **No double-sends** — each occurrence enrols exactly once, even if the same event is reported twice. You choose the re-enrolment policy: once per interaction, once per customer (with a cooldown), or every occurrence. * **No loops** — an automation's own actions never trigger other automations by default, and hard depth limits back that up. * **No surveying the same customer repeatedly** — survey sends inherit your workspace's survey-fatigue caps automatically. On top of that, one form goes out at most once per interaction (a chat, ticket or call) per 24 hours, so a chat that is both resolved and finished never gets two invites — the run log shows the second as suppressed (duplicate interaction). * **WhatsApp's 24-hour rule handled** — outside the customer-care window an automation only sends approved templates; the editor tells you when a template is needed. * **Missing details fail safe** — a message that references the customer's name can carry a fallback ("there"); a required detail that's missing stops the send rather than sending "Hi ,". * **Nothing silently stops** — a rule that pauses itself (too many runs, repeated failures) notifies every admin, and every run explains itself in the run log. ## Call your own API **Call your API** is an action like any other, so it inherits the whole rule: conditions decide *whether* to call, waits decide *when*, and the step's own condition is re-checked against live state right before it fires. That's the difference from a plain [webhook subscription](webhooks.md), which delivers every matching event and leaves the filtering to you — here you can say "post to our PMS **only if** the guest still hasn't been answered fifteen minutes after handover." Point it at an endpoint on your systems and we POST a JSON body containing the trigger's record, the automation that fired (rule, run and step ids), and the run's **live context** — the chat, contact, agent, ticket, call and survey values as they were re-read at that moment, not as they were when the rule triggered. * **Verify it's us** — set a signing secret and every delivery carries `X-Webhook-Signature`, verified exactly like a webhook subscription. Add custom headers (an API key, say) if your endpoint needs them. * **Delivered reliably** — the call goes through the same delivery pipeline as webhooks: sent asynchronously and retried with backoff if your endpoint is down. Because it is asynchronous, the automation's run log records that the call was *dispatched*, not the eventual HTTP result — so your endpoint should be the place you watch for failures. * **Handle repeats** — delivery is at-least-once, so use the `X-Automation-Run-Id` + `X-Automation-Step-Id` pair (also in the body) as your idempotency key. * **Public endpoints only** — the URL must resolve to a public address; internal or private addresses are refused, and the URL itself can't contain `{{tokens}}` (everything dynamic travels in the payload). Full payload contract: [Webhooks API reference](../../platform/webhooks.md#automation-api-calls). ## Build it with Kaylee Every automation's editor has an **Ask Kaylee** panel. Describe what you want in plain language — *"survey guests half an hour after their call ends, but never twice a week"* — and Kaylee drafts the whole automation using your actual survey forms, WhatsApp Flows, teams and ticket queues, shows it as a proposal card with exactly what would change, and applies it to the editor only when you click **Apply** (one Undo reverts it). She can also revise what's already there and explain why a rule didn't fire. Kaylee never saves, publishes or switches anything on — those stay your clicks, always. She looks things up rather than guessing. Every id she puts in a draft comes from your organisation's real records — she can list your survey forms, WhatsApp Flows (with each flow's status, categories and how many responses it has collected), teams, users, labels and ticket queues — plus live routing capacity (who's online, their cap and current load) and team queues (how many chats are waiting, the oldest wait, who has room) — and will tell you when something she needs doesn't exist instead of inventing it. For flows specifically, she can also read **what customers actually answered** — the most recent responses for a flow, with the chat and campaign each came from. That means you can ask *"what are people picking in the enquiry flow?"*, or have her write a rule that keys off a real field name and value rather than one she assumed. Only completed submissions are visible to her, the same rows the flow's [Responses panel](whatsapp-flows.md#responses-collected-across-a-flow) shows. ## Test before you trust Every automation has a **Test** panel: point it at a real record (a recent call, chat, ticket or survey response) and it shows whether the rule would fire, which conditions pass or fail, and exactly what every message would say — without sending anything or creating anything. ## The score behind score-based automations Score-triggered rules ("if the score is low…") read each response's **primary score** — the one question that IS the score of the form (set in the survey form's settings; automatic otherwise). Scores also carry a sentiment band — detractor, passive, promoter — so "detractor → recovery ticket" works the same whether the form uses 1–5 stars, NPS or thumbs. ## Limits * **Active automations** and **runs per month** are plan limits; usage shows at the top of the Automations page. * One automation can have up to 20 steps and 30 days of total waiting. * Scheduled automations (daily/weekly) are for internal digests and alerts — they can't message customers. Audience sends belong in Campaigns. ## FAQ **Why didn't my automation send anything?** Open the run: the timeline states the reason — a condition failed (with the exact field), the chat reopened, the customer is on the suppression list, the daily cap was reached, or the survey-fatigue cap suppressed the invite. "Deliberately didn't" and "broke" are always distinguishable. **What happens to runs that are mid-wait when I edit the automation?** They finish on the version they started on. New enrolments use the new version. **What happens when I switch an automation off?** New enrolments stop immediately. Runs already mid-wait finish on their published version — cancel any of them from the Runs view if they shouldn't. **Can an automation reply to every incoming message?** No — instant replies are what Bot Journeys are for. An automation triggered by an incoming message must wait at least a minute before any customer-facing send.