> For the complete documentation index, see [llms.txt](https://limechatai.gitbook.io/limechat-product-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://limechatai.gitbook.io/limechat-product-guide/helpdesk/settings/waiting-state-and-automated-reminder-setup.md).
# Waiting State and Automated Reminder Setup
### Overview
The **Waiting** state is used when an agent is waiting for the customer to come back with some information before the ticket can move forward.
Example cases:
* Agent is waiting for the customer to share order details
* Agent is waiting for an image/video of the issue
* Agent is waiting for address confirmation
* Agent is waiting for payment or delivery confirmation
* Agent is waiting for any additional information required to resolve the ticket
In these cases, the ticket should not remain in the open queue unnecessarily, but the customer still needs to be followed up with at regular intervals.
To support this, LimeChat now supports **automated reminder messages** for tickets placed in the Waiting state.
***
### Why This Matters
When a ticket is moved to Waiting, the resolution is blocked because the customer has not shared the required information yet.
Without regular follow-ups:
* Customers may forget to respond
* Tickets may remain unresolved for longer
* Agents may need to manually track and follow up
* Closure rates may drop
* Customer experience may become inconsistent
Automated reminders help teams re-engage customers at defined intervals and improve the probability of closing the ticket successfully.
***
### How It Works
When an agent moves a ticket to the **Waiting** state, the system can automatically send reminder messages to the customer based on the configured setup.
The reminders are controlled by three key settings:
1. **Number of reminders**
* Defines how many reminder messages should be sent while the ticket is in the Waiting state.
2. **Reminder interval / time window**
* Defines after how much time each reminder should be sent.
3. **Canned response**
* Defines the message that should be sent as the reminder.
This ensures agents do not have to manually create and send follow-up messages every time.
***
### Example
A ticket is moved to Waiting because the agent needs the customer to share an image of the damaged product.
The reminder setup is configured as:
* Number of reminders: 3
* Reminder interval: Every 24 hours
* Canned response: “Hi, we’re still waiting for the requested details to help resolve your issue. Please share them whenever possible.”
In this case, the system will automatically send the selected canned response at the defined interval while the ticket remains in the Waiting state.
***
### Steps to Set Up Waiting Reminder Follow-Up
#### Step 1: Go to Inbox Settings
Navigate to:
**Settings → Inbox Settings**
Select the relevant inbox where you want to configure waiting reminders.
***
#### Step 2: Scroll to Waiting Reminder Follow-Up
Scroll to the bottom of the inbox settings page.
Look for the section:
**Waiting Reminder Follow-Up**
***
#### Step 3: Set the Number of Reminders
Define how many times the reminder should be sent when a ticket is in the Waiting state.
Example:
* 1 reminder
* 2 reminders
* 3 reminders
This controls the maximum number of automated follow-ups that can be sent for a waiting ticket.
***
#### Step 4: Set the Reminder Time Window
Define the time gap after which each reminder should be sent.
Example:
* Every 6 hours
* Every 12 hours
* Every 24 hours
This controls how frequently the customer will be reminded while the ticket remains in the Waiting state.
***
#### Step 5: Select a Canned Response
Select the canned response that should be sent as the reminder message.
This helps maintain message consistency and avoids agents having to manually write follow-up messages every time.
Before configuring this, make sure the required canned response has already been created.
***
#### Step 6: Save and Test
After saving the setup, test it by moving a ticket to the Waiting state.
Check that:
* The ticket moves to Waiting correctly
* The selected canned response is used for the reminder
* The reminder is sent after the configured time window
* The reminders stop after the configured number of attempts
* The setup works correctly for the selected inbox
***
### Best Practices
* Use the Waiting state only when the agent is genuinely waiting for customer input.
* Keep reminder messages polite, short, and action-oriented.
* Clearly mention what information is needed from the customer.
* Avoid sending too many reminders in a short time window.
* Use different canned responses for different inboxes or use cases if needed.
* Review reminder performance to understand if customers are responding after follow-ups.
* Ensure agents are trained on when to move tickets to Waiting.
***
### Key Notes
* Waiting state should be used when the ticket is blocked due to missing customer information.
* Automated reminders are configured at the inbox level.
* Reminder frequency and number of attempts can be configured.
* A canned response must be selected for sending reminder messages.
* The reminder message is sent automatically while the ticket remains in Waiting.
* This reduces manual follow-up effort for agents and improves ticket closure chances.
***
### Summary
The Waiting state helps teams separate tickets where action is pending from the customer.
Automated waiting reminders make this flow more effective by following up with customers at configured intervals without requiring manual agent effort.
The core principle is simple:
When a ticket is waiting on the customer, the system should automatically remind the customer using a predefined message until the configured reminder limit is reached.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://limechatai.gitbook.io/limechat-product-guide/helpdesk/settings/waiting-state-and-automated-reminder-setup.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.