Zum Hauptinhalt springen
Wiedervorlagen sind kein manueller Merkzettel – sie sind ein systemischer Steuerungsmechanismus. Ein Ticket im Status „wartend” verschwindet aus dem aktiven Bearbeitungsfluss und kehrt zu einem definierten Zeitpunkt automatisch zurück.
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 „wartend” – 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 „wartend” verpflichtend und muss in der Zukunft liegen.
Beide Felder greifen direkt ineinander: Ohne Fälligkeitsdatum kann kein Ticket auf „wartend” gesetzt werden. Das verhindert Tickets, die dauerhaft aus dem Bearbeitungsfluss herausfallen.

​
Systemverhalten

Sobald ein Ticket auf „wartend” 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 „wartend” 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 „wartend” gesetzt, markiert das System die Fälligkeit als manuell gesetzt (dueByWasSetManually). Automatisch berechnete Fälligkeiten – etwa durch Tag-Konfigurationen – bleiben davon getrennt nachvollziehbar.

​
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 „wartend” 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 „wartend” 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": "2025-06-01 08:00:00"
}