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

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, 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.

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 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.