Wiedervorlagen

Nicht jedes Ticket kann sofort abgeschlossen werden. Manchmal fehlen Informationen vom Kunden, ein externer Vorgang muss abgeschlossen werden, oder eine Bearbeitung soll bewusst zu einem späteren Zeitpunkt erfolgen. Wiedervorlagen bilden genau diesen Sachverhalt systemisch ab: Ein Ticket wird temporär pausiert und zu einem festgelegten Zeitpunkt automatisch wieder zur Bearbeitung bereitgestellt.

Status und Fälligkeit

Wiedervorlagen basieren auf dem Zusammenspiel zweier Ticketattribute:

• Status „Warten" – Das Ticket ist aktiv, aber nicht zur sofortigen Bearbeitung vorgesehen. Es wird vom Smart Routing nicht verteilt.
• Fälligkeit (dueBy) – Der Zeitpunkt, zu dem das Ticket automatisch auf „offen" zurückgesetzt wird. Die Angabe einer Fälligkeit ist beim Setzen des Status „Warten" verpflichtend und muss in der Zukunft liegen.

Beide Felder greifen direkt ineinander: Ohne Fälligkeitsdatum kann kein Ticket auf „Warten" gesetzt werden. Das verhindert Tickets, die dauerhaft aus dem Bearbeitungsfluss herausfallen.

Systemverhalten

Sobald ein Ticket auf „Warten" gesetzt wird, passiert Folgendes im System:

• Das Ticket wird aus der aktiven Verteilung des Smart Routings herausgenommen – es erhält keine Zuweisung, solange der Status „Warten" ist.
• Ein Reminder wird intern angelegt, der auf das Fälligkeitsdatum referenziert.
• Zum Fälligkeitszeitpunkt setzt ein automatischer Prozess den Status auf „offen" und gibt das Ticket wieder für die Bearbeitung und das Smart Routing frei.
• Das System erzeugt ein ticketUpdated-Event mit dem Flag autoOpenedDueToDueDate: true, das für externe Integrationen ausgewertet werden kann.

Wird ein Ticket manuell auf „Warten" gesetzt, markiert das System die Fälligkeit als manuell gesetzt (dueByWasSetManually). Automatisch berechnete Fälligkeiten – etwa durch Tag-Konfigurationen – bleiben davon getrennt nachvollziehbar.

Wartegründe

Zum Status „Warten" kann ein Wartegrund gehören. So ist jederzeit erkennbar, warum ein Ticket pausiert ist, und Wartezeiten lassen sich nach Grund auswerten. Der gewählte Grund wird am Ticket und in der Bearbeitungshistorie gespeichert.

Einrichtung

Pfad: Einstellungen → Erweiterte Einstellungen → Allgemeines → Wartegründe

Auswahl bei der Bearbeitung

Auch in der Massenaktualisierung steht das Feld Wartegrund zur Verfügung, sobald der Status auf „Warten" gesetzt wird.

Wird bei einem Ticket, das bereits wartend ist, nur die Fälligkeit verschoben, bleibt der aktuelle Grund erhalten und wird nicht erneut abgefragt.

Ein wartendes Ticket zeigt seinen aktuellen Wartegrund an. Verlässt das Ticket den Status „Warten" – etwa durch eine Antwort, das Schließen oder das Erreichen der Fälligkeit –, wird der Grund entfernt. Wird ein Grund später aus der Liste gelöscht, bleibt er an Tickets und in Auswertungen, die ihn tragen, weiterhin sichtbar.

Einsatzszenarien

Warten auf Kundenrückmeldung Eine Information wurde beim Kunden angefragt. Bis zur Antwort soll das Ticket nicht im aktiven Bestand erscheinen. Mit einer Fälligkeit – z. B. in fünf Werktagen – kehrt es automatisch zurück, falls keine Rückmeldung erfolgt.

Abhängigkeit von einem externen Prozess Ein nachgelagerter Prozess (z. B. Systemverarbeitung, Rückfrage an ein Fachteam) muss abgeschlossen sein, bevor das Ticket weiterbearbeitet werden kann. Die Wiedervorlage stellt sicher, dass es zum richtigen Zeitpunkt wieder auftaucht.

Gezielte Terminsteuerung Ein Ticket soll nicht sofort, sondern zu einem bestimmten Datum bearbeitet werden – etwa weil ein Tarif erst ab dem Folgemonat gilt oder ein Vertragszeitraum abgewartet werden soll.

Auswirkungen auf Analytik und Zeiterfassung

Das Setzen des Status auf „Warten" wird im Bearbeitungsexport als Bearbeitungsart statusAction erfasst – auch dann, wenn keine Antwort an den Kunden gesendet wurde. Damit wird die Tätigkeit des Bearbeiters korrekt in der AHT abgebildet.

Tickets im Status „Warten" erscheinen in der Ticketübersicht und können über den Statusfilter gezielt eingesehen werden. So bleibt der Gesamtbestand transparent, auch wenn Tickets temporär nicht aktiv bearbeitet werden.

API-Integration

Wiedervorlagen lassen sich über die enneo-API setzen und steuern.

Voraussetzung: dueBy muss angegeben werden und in der Zukunft liegen. Das Zurücksetzen auf „offen" erfolgt entweder automatisch durch den zeitgesteuerten Prozess oder manuell über denselben Endpoint mit "status": "open".

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

Optional kann im selben Aufruf ein Wartegrund mitgegeben werden. Das Ticketfeld pendingReason (Text oder null) wird zusammen mit "status": "pending" gesendet und muss genau einem der konfigurierten Wartegründe entsprechen. In folgenden Fällen antwortet die API mit 400:

• Der Grund steht nicht in der Liste – die Antwort nennt die zulässigen Gründe.
• Wartegrund erforderlich ist aktiv und der Grund fehlt – die Antwort nennt die zulässigen Gründe.
• Es wird ein Grund gesendet, obwohl keine Wartegründe konfiguriert sind.

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

Das Feld pendingReason wird auch bei der Massenaktualisierung (PATCH /api/mind/ticket) akzeptiert.