Enneo
Enneo documentation

Tickets

Reminders

Purposefully pause tickets and automatically return them for further processing.

Tip

Reminders are not a manual note – they are a systemic control mechanism. A ticket under the status "Waiting" disappears from the active processing flow and returns automatically at a defined point in time.

Not every ticket can be instantly completed. Sometimes information from the customer is missing, an external procedure has to be completed, or processing is intentionally to be given at a later point in time. Reminders systematically represent exactly this fact: A ticket is temporarily paused and automatically ready for processing again at a set point in time.

Status and Due Date

Reminders are based on the interaction of two ticket attributes:

  • Status "Waiting" – The ticket is active, but not intended for immediate processing. It is not distributed by Smart Routing.
  • Due Date (dueBy) – The point in time when the ticket is automatically reset to "open". Specifying a due date when setting the status to "Waiting" is mandatory and must be in the future.

Both fields directly correspond: Without a due date, no ticket can be set to "Waiting". This prevents tickets from permanently falling out of the processing flow.

System Behavior

As soon as a ticket is set to "Waiting", the following happens in the system:

  • The ticket is removed from the active distribution of Smart Routing - it does not receive an assignment as long as the status is "Waiting".
  • A reminder is internally created that references the due date.
  • At the due date, an automatic process resets the status to "open" and releases the ticket again for processing and Smart Routing.
  • The system generates a ticketUpdated event with the flag autoOpenedDueToDueDate: true, which can be evaluated for external integrations.

If a ticket is manually set to "Waiting", the system marks the due date as manually set (dueByWasSetManually). Automatically calculated due dates – for example, through tag configurations – remain separately traceable.

Hold Reasons

The "Waiting" status can come with a hold reason. This makes it clear at any time why a ticket is paused, and waiting times can be analysed by reason. The selected reason is stored on the ticket and in the processing history.

Setup

Path: Settings → Advanced settings → General → Hold reasons

Add hold reasons

Under Hold reasons ("Wartegründe"), enter the reasons your team should be able to choose from, for example "Customer's reply", "Third party's reply" or "Internal clarification".

Entries are shown exactly as entered, in every UI language. Empty or duplicate entries are rejected, and each entry can be up to 255 characters long.

Make the reason mandatory (optional)

Hold reason required ("Wartegrund erforderlich") makes the reason mandatory. A ticket can then only be set to "Waiting" with one of the listed reasons – in the UI, via the API, by bulk update and by AI agents.

The switch is off by default and only takes effect when at least one hold reason exists.

Note

On production instances the list starts empty. As long as no reason exists, the dialog shows no selection and tickets are set to "Waiting" without a reason. Test and development instances start with two examples: "Warten auf Rückmeldung eines Dritten" (waiting for a third party's reply) and "Interne Klärung" (internal clarification).

Selecting a reason

Follow-up with hold reason

In the due date for reopening dialog, the agent first picks the date and then, below it under Hold reason, one of the listed reasons. The search field filters longer lists quickly.


When Hold reason required is on, the field is marked as mandatory with an asterisk (*).

The Hold reason field is also available in the bulk update as soon as the status is set to "Waiting".

If only the due date of a ticket that is already waiting is moved, the current reason is kept and not asked for again.

A waiting ticket shows its current hold reason. When the ticket leaves the "Waiting" status – for example through a reply, closing, or the due date being reached – the reason is cleared. If a reason is later removed from the list, it remains visible on tickets and in reports that carry it.

Use Cases

Waiting for customer feedback Information is required from the customer. Until the response, the ticket should not appear in the active inventory. With a due date - e.g. in five working days - it automatically returns if there is no response.

Dependency on an external process A downstream process (e.g. system processing, inquiry to a specialist team) must be completed before the ticket can be further processed. The reminder ensures that it reappears at the right time.

Targeted scheduling A ticket should not be processed immediately, but on a specific date – for example, because a tariff applies only from the following month or a contract term should be waited out.

Impact on Analytics and Time Recording

Changing the status to "Waiting" is recorded in the processing export as processing type statusAction - even if no response has been sent to the customer. This accurately depicts the activity of the processor in the AHT.

Tickets under the status of "Waiting" appear in the ticket overview and can be specifically viewed through the status filter. This keeps the overall inventory transparent, even if tickets are not actively processed temporarily.

API Integration

Reminders can be set and controlled via the enneo-API.

Requirement: dueBy must be specified and lie in the future. The reset to "open" happens either automatically through the time-controlled process or manually via the same endpoint with "status": "open".

PATCH /api/mind/ticket/{id}
{
"status": "pending",
"dueBy": "2027-01-15 08:00:00"
}

Optionally, a hold reason can be passed in the same call. The ticket field pendingReason (string or null) is sent together with "status": "pending" and must exactly match one of the configured hold reasons. The API answers with 400 when:

  • the reason is not in the list – the response names the allowed reasons;
  • Hold reason required is on and the reason is missing – the response names the allowed reasons;
  • a reason is sent although no hold reasons are configured.
PATCH /api/mind/ticket/{id}
{
"status": "pending",
"dueBy": "2027-01-15 08:00:00",
"pendingReason": "Interne Klärung"
}

The pendingReason field is also accepted by the bulk update (PATCH /api/mind/ticket).