Skip to main content
Auto-responses send an automatic reply when a new thread is created. Use them to keep customers informed straight away, reduce duplicate follow-ups, and give your team time to respond thoughtfully. To set up auto-responses, go to Settings → Auto-responses.
Auto-responses in Plain

​
When auto-responses are triggered

Auto-responses fire when a new thread is created. You can restrict them to specific conditions. All conditions on a single auto-response must match for it to send. If you have multiple auto-responses configured, they are evaluated in order and the first match wins. Available conditions:
  • Support email address: only applies when the thread comes in via email
  • Inside or outside business hours: matches based on your workspace business hours setting
  • Label: matches threads that have a specific label applied
  • Tier: matches threads belonging to a specific customer tier
  • Priority: matches threads at a specific priority level
If your workspace does not have business hours configured, the outside business hours condition always evaluates as matched (it is treated as always true).

​
When auto-responses are suppressed

Even when an auto-response is enabled, it will not send in the following situations:
  • Thread created by an agent: auto-responses only fire for threads created by a customer or a machine user (e.g. via API). Threads opened manually by a support agent are skipped.
  • Customer is marked as spam: no auto-response is sent to spam customers.
  • Thread has no inbound message: if the thread has no first customer message, the auto-response is skipped.
  • Thread is no longer in Todo when the response is due: if the thread has been resolved, snoozed, or otherwise moved out of Todo before the scheduled send time, the auto-response is canceled.
  • An agent or machine user has already replied: if any non-customer message is sent before the auto-response fires, for example during the response delay window, the auto-response is canceled. This prevents a second reply when a user has already picked the thread up.

​
Response delay

You can configure a delay (up to 15 minutes) between when the thread is created and when the auto-response is sent. The delay is calculated from the timestamp of the first inbound message. The delay window is also a safety net: if an agent replies within the delay, the auto-response is automatically suppressed so the customer does not receive two responses.

​
Supported channels

Auto-responses can be enabled across multiple support channels:
  • Email: for inbound messages to your support inbox
  • Chat: for sessions started in your website widget
  • Slack: for threads started via Slack Connect
  • API: for programmatically created threads
  • Microsoft Teams: for threads started via a Teams channel
  • Discord: for threads started via a Discord server
You can configure separate auto-responses per channel, or share one across multiple channels.

​
Using dynamic fields in automated replies

You can include variables in automated email responses to personalize messages automatically. Supported fields include:
  • {{ customer.fullName }}
  • {{ customer.shortName }}
  • {{ customer.email }}
  • {{ thread.ref }}
  • {{ thread.id }}

​
Basic usage

Place the variable directly in the reply template where you want the value to appear. For example:

​
Advanced use: Custom auto-responses via API

If you need more control, such as dynamic content or conditional logic, you can build interactive auto-responses using Plains API and webhooks. See our Thread auto-responders documentation for more.