Automations

Products › Lodgestory CRM › Settings › Automations

All plans (limits vary) New

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, reply to Instagram comments (publicly or by DM) or hide them, open tickets (filling the ticket workflow's capture fields — Room No., Invoice #… — from the run), 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: 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, an Instagram comment on one of your posts, reels or ads, 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, calls that arrived after hours, survey score in the detractor band, chat has the VIP label, only on the Sales WhatsApp number.
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 — a call missed while you were open → 2 min → "sorry we missed you" + a callback reminder for the agent
• After-hours call catch — someone called while the phones were closed (outside business hours, on a holiday, or while closed with Close now) → 2 min → "we are closed right now — reply here" + a callback reminder waiting for the team when they are back
• 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
• Comment keyword → DM the link — an Instagram comment containing a keyword (price, say) on any of your posts → reply publicly "Sent you a DM 📩" and send the commenter a private reply with your link, instantly (replies to comments are skipped)
• Route new comment threads to the social team — a comment lands on a post whose thread has no team yet → route the thread to your social team's queue
• New lead: alert the sales team — a lead lands in any Track (a Meta Instant Form from Meta Lead Ads, an import, the API, a missed call…) → push-alert the team you pick with the contact's name and phone, so someone claims it at once
• Meta lead → WhatsApp template at once, then alert the owner — a lead lands from a Facebook or Instagram Instant Form → an approved WhatsApp template goes out immediately on the number you pick (a returning customer gets it in their existing chat; a brand-new lead gets a new conversation) and the lead's owner is push-alerted with the form and campaign

Leads from Meta ads and other sources

Every Lead trigger (created, assigned, stage changed, SLA breached, moved, outcome captured) exposes the lead itself alongside the contact: source (Meta lead ad, conversation, web form, import…), source detail (for a Meta lead, the Instant Form's name), status, stage, priority, score, owner, lead type, the UTM values and — for Meta leads — the form, platform (Facebook or Instagram), ad and campaign, plus the Track. So a rule can say Lead source is Meta lead ad, Meta form name is Diwali villas or Track is Resale buyers, and a message can read {{lead.sourceDetail}} or {{lead.utm.campaign}}.

A brand-new lead has no conversation yet, so Send message on a lead trigger takes two extra things: an approved WhatsApp template (the first message to someone who never wrote to you is always outside the 24-hour window) and a WhatsApp number for brand-new leads. With both, the run opens the chat on that number and sends the template; a returning customer is messaged in their existing WhatsApp chat instead. Without them the step is skipped for new leads, and the editor warns you at publish time. Notify agent → Primary assignee reaches the lead's owner; use Team or All admins for leads still in the pool. A Create follow-up step needs a chat to attach to — place it after a Send message step that opened one, or rely on the Track's own SLA and retry cadence.

Capacity & queues

Automations share the inbox's routing rules, so it helps to know them:

• Caps. Under Settings → Chat routing & queues an admin can set an organisation-wide max open chats per advisor (and override it per person on Team Members) (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". Assigning never messages the customer, in any mode — the hand-over is silent, and only your team sees a note in the conversation; add a Send message step if the customer should be told. 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.
• Send push notification (SEND_PUSH) sends a notification to the devices registered to the contact's app on one of your push apps — a title and body with {{tokens}}, optionally an image and a deep link. Transactional reaches every device; promotional only devices opted in to marketing, outside the app's quiet hours and within its daily cap. The opt-out list and the per-customer daily message cap apply as for Send message. A person without a registered device is skipped (SKIPPED_NO_DEVICE), never a failure, so the same rule can run for everyone and only app users get the push; so is a person whose devices are kept out right now — no marketing opt-in for a promotional push, the app's quiet hours or its daily cap (SKIPPED_PUSH_NOT_ELIGIBLE; a promotional push is not held for later). With one push app connected the action uses it; with several, pick the app — publishing refuses the rule without one, and without any push app at all. A text that comes out longer than the limits (a long name in the title) is shortened, and a step that hits a temporary problem is retried without ever sending the push twice. The Missed-call app nudge recipe is a ready-made example: callers who rang while you were open, 2 minutes later, once per caller in 4 hours, and not if they got through on a second call.
• 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 created via (MANUAL, DISPOSITION or PUSH) lets a welcome rule skip contacts that were auto-created while an advisor captured a disposition mid-conversation, or treat guests who first appeared by signing in on your own app (push notifications) differently.
• 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.

Run on specific channels

An automation listens to every connected channel. Two conditions under Only if… narrow that:

• Channel — one or more particular channels, picked from your connected numbers, inboxes and accounts. Each shows its label from Channel Runtime Config, or else its number, Instagram @handle, Facebook page name, website or email address. Use is for one channel, is any of / is none of for several: only on the Sales number, every channel except the support inbox.
• Channel type — every channel of one kind: all WhatsApp numbers, all Instagram accounts.

A Channel condition is false when the moment has no conversation (a call that isn't linked to a chat), and a channel you delete never matches again — the picker marks it Deleted channel so you can remove it. Steps and Cancel the run if… can use the same conditions.

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.
• Connect calls are left alone — a connect call joins two outside numbers for your own system, with no agent, so it never starts a call completed or call missed rule: the message would go to the second person, who never spoke to you. Your webhooks still receive these calls.

Calls in and out of hours

A call on a Lodgestory Voice number that passed a business-hours schedule says how it stood against that schedule, on call completed and call missed rules:

A caller who only heard your closed or holiday message is a missed call with call.afterHours yes, so a missed-call rule fires for them. The two recipes split the work: Missed-call catch takes calls missed while you were open, After-hours call catch the ones that arrived while you were closed. An automation made from Missed-call catch before October 2026 has no such condition and answers both; add Call → after hours → is false to it if you switch the after-hours recipe on, so that a caller is not messaged twice.

This is the calling schedule. The business hours a Wait can shift to are the chat away hours of the channel — a different schedule.

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.

Instagram comments

Comments on your Instagram posts, reels and ads arrive in the inbox as one thread per post once Comments in inbox is on for the account (Connections). Automations can answer them.

Trigger — Instagram comment received. Fires once per comment on your posts, reels and ads — top-level comments and replies alike — and never for comments your own account posts. The run's chat is the post's comment thread, so chat conditions and actions (labels, assignment, tickets, notes) apply to the thread. Conditions can use:

• Comment — text, username, is a reply, comment time.
• Post — the post itself (picked from your recent posts, reels and ads), post type (Post, Reel, Ad), caption, is an ad, post link.
• Chat — the thread's usual fields (labels, teams, owner, workflow…).

Actions (available on this trigger only):

• Reply to comment (public) — posts a reply under the comment on Instagram, visible to everyone. Text only, up to 2,200 characters, tokens allowed ({{comment.username}}). Skipped when the comment is hidden.
• Send private reply (DM) — sends the commenter one Instagram DM about their comment. Text only, up to 1,000 characters; Instagram appends a link to the post. The DM lands in the commenter's Instagram chat in the inbox. Instagram allows one private reply per comment, within 7 days of the comment — a rule can never send a second one — and caps private replies at 750 per hour per account.
• Hide comment — hides the comment on Instagram. Safe to repeat; already-hidden comments are skipped.

Rules worth knowing:

• Instant replies are fine. Unlike message-triggered rules, a comment rule doesn't need a wait before it answers — commenters expect a reply straight away.
• Send message and Send survey aren't available on this trigger: a comment thread isn't a customer's chat, and the editor won't publish them there. To message the commenter, use Send private reply.
• Commenters aren't contacts. The suppression list and the per-customer daily cap don't apply to comment actions; the per-automation hourly ceiling still does. The two reply actions are customer-facing, so they need the service account under Automations › Settings, and quiet hours apply to them as to any customer-facing send — set the rule to ignore quiet hours if comments should be answered at night (the prebuilt recipe does).
• The run log explains itself. Outcomes read COMMENT_REPLIED and PRIVATE_REPLY_SENT when actions land, and skips are typed — for example SKIPPED_PRIVATE_REPLY_UNAVAILABLE when Instagram won't accept a private reply to that comment (already replied, older than 7 days, or the commenter doesn't accept it).
• Filter replies. A commenter's reply to your public reply is itself a comment and fires the trigger again. Add Comment → is a reply → is false unless you want rules to answer replies too — the prebuilt recipes do.

Ask Kaylee for "DM everyone who comments price on my latest reel" and she'll draft the rule against your real posts; ask her to "WhatsApp every commenter" and she'll explain there's no number to message and offer a private reply instead.

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, ticket queues and connected channels (so "only on the Sales number" becomes a real Channel condition) — and your Instagram posts, reels and ads when drafting comment rules — 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, survey response or Instagram comment thread) 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 run on only one of my numbers?
Yes. Add a Channel condition under Only if… and pick the number (or several, with is any of). Channel type is for every channel of one kind. See Run on specific channels.

Does assigning a chat tell the customer?
No. Assign chat changes who owns the conversation and leaves a note for your team; the customer receives nothing unless the automation also has a Send message step. In a Bot Journey, the Agent Transfer step has its own Message the customer switch — turn it off for a silent transfer.

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.

Can an automation answer Instagram comments straight away?
Yes. The Instagram comment received trigger is the exception to the one-minute rule: a public reply or a private reply (DM) can go out the moment the comment lands. Instagram's own limits still hold — one private reply per comment, within 7 days, text only.

Can an automation fill a ticket's custom fields?

Yes. When the Create ticket action points at a ticket workflow that defines Details to capture (Settings → Ticket Workflows), a Ticket details section appears with one input per field. Each value is a template over the run — {{call.callerNumber}} into a "Callback number" field, {{survey.primaryScore}} into a "Score" field, plain text into a dropdown (option chips fill it for you). Required fields are not enforced for automation tickets; a value whose token is missing or that doesn't fit the field's rule is skipped and listed as fieldErrors on the step in the run log — the ticket is still created. On ticket triggers (created / resolved / assigned) the captured values are readable as {{ticket.fields.<field_id>}} in messages and conditions; Kaylee knows each workflow's field ids from its lookups.