Chatwoot Automation Rules, Macros, SLAs and Webhooks

Most Chatwoot setups use about 10 percent of the automation built into the product, and the teams that do automate usually build the wrong rules first. The short answer: automate routing, labelling, and out-of-hours behaviour before anything else, use macros for anything an agent still needs to eyeball, and reach for webhooks only when a rule cannot express the logic you need. This guide walks through all four automation systems in Chatwoot, with the mechanics, the costs, and the mistakes that actually break production setups.

Chatwoot positions itself as an open-source, self-hosted alternative to Intercom, Zendesk and Salesforce Service Cloud, and the automation layer is a big part of why teams switch. It is also the part most teams configure once, badly, and never revisit.

The four automation systems and what each one is for

Chatwoot has four separate systems that people casually call "automation". They solve different problems, and confusing them is where most bad setups start.

• Automation rules are the if-this-then-that engine. An event happens (a conversation is created, a message arrives), conditions are checked, and actions run: assign an agent, add a label, send a message, change status. Rules run automatically, with no human in the loop.
• Macros are saved sequences of actions that an agent triggers manually with one click. Think of them as a personal checklist compressed into a button.
• Business hours and auto-assignment are inbox-level plumbing. Business hours control out-of-office replies and SLA clocks; auto-assignment decides which agent gets each new conversation.
• Webhooks push events out of Chatwoot to anything that speaks HTTP, so external systems (an n8n workflow, your CRM, a billing system) can react and call back through the API.

A useful mental model: rules decide what happens to a conversation, macros help agents do repetitive work faster, business hours and auto-assignment set the defaults everything else builds on, and webhooks are the escape hatch for everything the first three cannot express.

Automation rules: events, conditions, actions

Every rule has three parts, and the official user guide documents them well. The short version:

Events. A rule fires on one of four triggers:

• Conversation created — runs once, when the conversation first appears in any channel.
• Conversation updated — runs when something about the conversation changes (status, assignee, labels, custom attributes).
• Message created — runs on every new incoming or outgoing message. Powerful and dangerous, for reasons covered below.
• Conversation opened — runs when a snoozed, resolved, or pending conversation reopens.

Conditions. Filters on inbox, channel, message content, contact attributes, custom attributes, and more. You combine them with AND/OR logic, and they are evaluated in the order you define them. The condition set depends on the event you picked.

Actions. What the rule does when conditions match:

• Assign to an agent or a team
• Add a label
• Send a message or an attachment
• Send an email to the team, or an email transcript
• Mute, snooze, or resolve the conversation
• Send a webhook event
• Run a macro

You create rules under Settings → Automation, and you can pause, clone, edit, or delete them from the same screen. Two behaviours are worth memorising before you build anything:

• Rules run forward only. A rule you create today does nothing to conversations that already exist. It fires on events that happen after you enable it.
• Every matching rule runs, in listed order. If two rules both match and both set the team, the later one wins. Order your rules deliberately.

Three rules worth building first

These cover the routing and triage work that eats agent time at almost every support desk:

• Route by keyword. Event: Conversation created. Condition: message content contains "invoice", "refund", or "charge". Actions: assign the Finance team, add the label billing.
• Flag important customers. Event: Conversation created. Condition: contact custom attribute plan equals enterprise. Actions: set priority high, add label vip, assign your senior team.
• Channel-specific routing. Event: Conversation created. Condition: inbox equals your WhatsApp inbox. Actions: add label whatsapp, assign the team that handles chat. If you run WhatsApp through Chatwoot, our WhatsApp Business API setup guide for Kenya covers the channel side, and what Kenyan support teams now pay for the WhatsApp Business API keeps the per-conversation costs current.

Macros: the manual multiplier

A macro is a saved sequence of actions that runs when an agent clicks it: assign the Sales team, send a standard reply, add a label, snooze the conversation, all in one step. Macros are private to an agent or public to the whole team, and agents run them from the conversation sidebar.

The distinction that matters: macros are manual, rules are automatic. An agent decides to run a macro after reading the conversation. A rule fires on its own. That difference tells you which tool to use:

• If a human needs to judge the conversation first ("is this really a refund request, or someone confused about pricing?"), keep it a macro.
• If you catch yourself running the same macro on every conversation that matches an obvious pattern, convert it into an automation rule.

Macros are also the right tool for destructive or customer-facing actions you want a person to confirm. A rule that auto-resolves conversations is how you end up silently closing real customer issues. A "resolve with thank-you note" macro keeps the agent as the final check.

Business hours and auto-assignment: the boring setup that does the most

Before you write a single rule, configure these two inbox-level settings. They affect every conversation and most teams skip them.

Business hours are set per inbox under Settings → Inboxes → your inbox → Business Hours. They do three jobs: show customers an out-of-office message instead of silence, pause SLA clocks overnight and on weekends so a Friday-evening ticket is not already late on Monday morning, and keep response-time reporting honest by counting working time instead of wall-clock time. Set the timezone correctly; for a Nairobi-based team that is UTC+3, and getting it wrong quietly corrupts every SLA measurement.

Auto-assignment is configured under Settings → Inboxes → your inbox → Configuration, and comes in two strategies:

• Round Robin distributes conversations evenly across all online, available agents in the inbox. Start here.
• Balanced gives the next conversation to the agent with the fewest open conversations. Better when some conversations take far longer than others, such as technical support mixed with quick account questions.

Both strategies respect agent availability (offline and busy agents are skipped) and inbox membership. Capping how many open conversations one agent can hold at once (agent capacity) is a paid feature: per the self-hosted pricing page it is included from the $19 per agent per month Premium Support tier up, but not in the free Community Edition, which matters for the cost discussion below.

SLAs: useful, but check the edition first

Chatwoot SLA policies put a clock on three metrics, documented in the SLA user guide:

• First Response Time (FRT) — time to the first agent reply.
• Next Response Time (NRT) — time to each subsequent reply while the customer waits.
• Resolution Time (RT) — time until the conversation is resolved.

You define an SLA under Settings → SLA with any combination of these timers, choose whether the clock runs on business hours or 24/7, and then apply it to conversations through an automation rule (for example: conversation created, priority equals urgent, apply the "Enterprise P0" SLA). Conversations approaching a breach show a countdown in the conversation list and header, and there is a dedicated SLA report for hit rates and trends.

Two quirks to plan around:

• You cannot edit an SLA after creating it. To change a target, you create a new SLA policy and switch your automation rules to it.
• Once an SLA is applied to a conversation, it cannot be removed. Scope the applying rule tightly or every misfire becomes permanent noise in your breach report.

Now the part the feature pages bury. On the self-hosted pricing page, SLA policies are not included in the free Community Edition or in the $19 per agent per month Premium Support plan. They ship only with the Enterprise Edition at $99 per agent per month, the same tier that includes SSO/SAML. For a 10-agent team, that is $990 per month, largely for SLA tracking and single sign-on.

If SLA targets matter to you but that price does not, there is a workable middle path: use automation rules to approximate the behaviour. A rule can label urgent conversations, email the team when a VIP writes in, and you can track response times in the standard reports even without formal SLA objects. It is not the same as a breach countdown, but it is honest triage at zero licence cost. For the full cost picture of self-hosting, including server sizing, see running Chatwoot in production and our Chatwoot vs Intercom cost comparison.

Webhooks: the escape hatch when rules are not enough

Automation rules cover a surprising amount, but they cannot call an external API, look up an order, or branch on data that lives outside Chatwoot. That is what webhooks are for.

You configure them under Settings → Integrations → Webhooks, subscribing to the events you care about: conversation_created, conversation_updated, conversation_status_changed, message_created, message_updated, contact_created, contact_updated, webwidget_triggered, and the typing events. The webhook documentation lists the full payload structure for each event. There is also a Send webhook event action inside automation rules, so a rule can fire a one-off webhook when its conditions match, which is the cleanest way to connect rule logic to external systems.

Every webhook request is signed so your receiver can verify it genuinely came from your Chatwoot instance. Requests carry an X-Chatwoot-Signature header containing an HMAC-SHA256 of {timestamp}.{raw_body} computed with your webhook secret, plus X-Chatwoot-Timestamp and X-Chatwoot-Delivery headers. Verify the signature before acting on any payload; it takes a few lines of code and rules out forged requests.

The common pattern we recommend is Chatwoot webhook into an n8n workflow: Chatwoot sends conversation_created, n8n enriches it (look up the customer in Twenty or your billing system, classify the intent, check a stock level), then calls the Chatwoot API to set labels, priority, or assignee. Webhook subscriptions themselves can also be managed programmatically through the Chatwoot developer API, authenticating with a user API token from Profile Settings. This is exactly the kind of work our business automation service builds on n8n, and it keeps Chatwoot itself simple.

A worked setup for a 10-agent team

Here is a concrete configuration for a support team handling roughly 150 conversations a day across website chat, email, and WhatsApp, on the free Community Edition.

Step 1: business hours on every inbox. Monday to Friday, 8am to 6pm EAT, Saturday 9am to 1pm, with a short out-of-office message naming the next available window.

Step 2: auto-assignment. Round robin on the chat and WhatsApp inboxes (fast conversations, even spread). Balanced on the email inbox, where threads run long.

Step 3: four automation rules, in this order.

• Rule 1, "VIP triage": Conversation created, contact attribute plan equals enterprise. Actions: set priority high, label vip, assign senior team.
• Rule 2, "Billing router": Conversation created, message content contains "invoice" or "refund" or "receipt". Actions: assign Finance team, label billing.
• Rule 3, "Out-of-hours acknowledgement": Message created, outside business hours, conversation status open. Action: send a message stating the next working window. (Chatwoot does not run automations on messages sent by other automations, so this will not loop, but keep the condition tight anyway.)
• Rule 4, "Stale bot escape": Conversation updated, label bot-failed added by your webhook integration. Action: unassign, assign human team, label needs-human.

Step 4: six macros for the judgement calls: refund approved, refund denied, escalation to engineering, password reset walked through, spam close, and "handover to sales".

Step 5: one webhook pushing conversation_created to n8n for CRM enrichment.

The payoff, with honest arithmetic: if manual triage (read, label, assign, prioritise) takes about 90 seconds per conversation, a 150-conversation day burns about 3.7 agent-hours on routing alone. Rules 1 and 2 plus auto-assignment remove most of that, which is roughly one full-time agent's worth of capacity returned to actual support work. That is the real ROI of this setup, and it costs nothing in licence fees on Community Edition.

Common mistakes that break Chatwoot automation

These are the failure modes worth checking your own setup against right now:

• Message-created loops. A rule listening on Message created that sends a message can re-trigger itself. Chatwoot's own documentation notes that automations do not run on actions triggered by other automations, which is a safety net, but a safety net is not a design. Scope message-created rules with tight conditions (incoming messages only, specific inboxes, specific content).
• Conflicting rules. Two rules match, both assign a team, and the later one silently wins. If agents complain that conversations land in the wrong team, check rule order before blaming routing.
• Silent rules. Nobody remembers why "Legacy router v2" exists, and it has been mislabeling conversations for four months. Chatwoot's own advice is to review rules quarterly, and it is right. Name rules descriptively and delete aggressively.
• Expecting retroactivity. New rules do not touch existing conversations. If you migrate in from Zendesk with thousands of open threads, rules will not tidy them; see our Zendesk to Chatwoot migration guide for how to handle the backlog.
• Automating before the pattern is proven. The Chatwoot team suggests a simple test: have you done this exact thing manually at least ten times in the last two weeks? If not, keep doing it manually until the pattern is real. Bad automation is worse than none because it erodes trust in the whole dashboard.

When automation rules are the wrong tool

Be honest about the boundaries:

• You need external data to decide. Rules can only match on what Chatwoot knows. If routing depends on an order status, an account balance, or inventory, use the webhook-into-n8n pattern instead.
• You need language understanding, not keyword matching. A rule that matches the word "refund" also matches "I do not want a refund". For intent classification, look at Chatwoot's Captain AI (which on cloud plans comes with monthly credits of 300 to 800 depending on tier, with extra credits at $20 per 1,000 per the pricing page) or a custom agent connected over the API.
• You need SLA enforcement on Community Edition. The objects do not exist below the Enterprise tier; approximate with rules and reports, or budget for the upgrade.
• Your volume is tiny. Under 20 conversations a day, manual triage is faster than maintaining rules. Set business hours, write two macros, and stop there.

Frequently asked questions

Do Chatwoot automation rules work on existing conversations? No. Rules fire only on events that happen after the rule is created and enabled. Existing conversations are unaffected, which matters when you migrate from another help desk with an open backlog.

What is the difference between a macro and an automation rule in Chatwoot? A macro is a saved sequence of actions that an agent runs manually with one click. An automation rule fires automatically when its event and conditions match. If you run the same macro on every conversation matching an obvious pattern, convert it to a rule.

Can Chatwoot automation rules send messages to customers? Yes, "send a message" is a standard action. Be careful pairing it with the Message created event, because a rule that sends messages in response to messages is the classic loop risk. Tight conditions (incoming only, specific inbox, specific content) keep it safe.

Are SLAs available on the free self-hosted version of Chatwoot? No. Per Chatwoot's self-hosted pricing page, SLA policies are included only in the Enterprise Edition at $99 per agent per month. Community Edition and the $19 Premium Support tier do not include them. You can approximate SLA behaviour with automation rules and the standard response-time reports.

Can Chatwoot call an external API when a conversation arrives? Not directly from a condition, but two routes exist: the Send webhook event action inside automation rules, and account-level webhooks that push events like conversation_created to any HTTP endpoint. Most teams point these at n8n and call back into Chatwoot through its API.

How do I stop two automation rules from fighting over the same conversation? Every rule whose conditions match will run, in the order they are listed, and later actions overwrite earlier ones. Order rules from most specific to most general, and audit for overlapping conditions whenever routing misbehaves.

Where to go from here

Set business hours and auto-assignment today, build your two most obvious routing rules this week, and only then look at webhooks for anything the rules cannot express. If you would rather have this configured, monitored, and maintained for you, our managed open-source stack service runs Chatwoot alongside Twenty, Listmonk, Plausible and the rest of the self-hosted stack for clients, including the automation layer described in this post.