Ticket-Historie und Aufbewahrung: Was beim Toolwechsel mitmuss

Jede Helpdesk-Migration erzwingt eine Frage, die die meisten Teams seit Jahren vor sich herschieben: Wofür ist diese ganze Historie eigentlich da? Zehn Jahre Tickets fühlen sich wie ein Vermögenswert an – bis Sie sie umziehen müssen. Dann werden sie zur Rechnung, bemessen in Exportstunden, Importzeit, Speicher und Suchrauschen. Die ehrliche Antwort: Ticket-Historie erledigt drei Aufgaben, jede mit einer eigenen Haltbarkeit – und sobald Sie diese Aufgaben benennen, trifft sich die Entscheidung zwischen Behalten und Archivieren fast von allein.

Die drei Aufgaben alter Tickets

Aufgabe 1: Kontext für Agents. „Hat diese Kundin schon einmal geschrieben? Was haben wir ihr zugesagt?“ Das ist der Alltagsfall, und er ist massiv auf die jüngste Vergangenheit gewichtet. Vertrauen Sie hier keiner Faustregel, sondern den Daten Ihres eigenen Tools: Sehen Sie nach, wann ein Agent zuletzt ein Ticket geöffnet hat, das älter als ein Jahr war. In den meisten Teams konzentrieren sich die Abrufe überwältigend auf die letzten sechs bis zwölf Monate, mit einem dünnen Ausläufer für aktive Enterprise-Accounts und offene Streitfälle.

Aufgabe 2: Reporting und Trends. Volumenkurven, Themenmischung, saisonale Muster. Reports brauchen Aggregate, keine Rohkonversationen – und Aggregate lassen sich einmal berechnen, als Zahlen exportieren und zu vernachlässigbaren Kosten für immer aufbewahren. Sie brauchen keine zehn Jahre Rohtickets, um sich zu merken, dass der Januar Ihre Spitze ist.

Aufgabe 3: Grundlage für die KI. Die jüngste Aufgabe – und die missverstandenste, deshalb bekommt sie ihren eigenen Abschnitt.

Achten Sie darauf, was auf dieser Liste fehlt: Nichts davon verlangt rohe, jahrzehntetiefe Historie in Ihrem Arbeitswerkzeug. Aufgabe 1 will Aktualität, Aufgabe 2 will Zahlen, und Aufgabe 3 will – wie gleich zu sehen – Kuratierung. Der Impuls, alles zu migrieren, kommt aus der Verlustangst, nicht aus einer Aufgabe, die diese Daten tatsächlich erfüllen.

Was Ihre KI wirklich braucht (weniger, als Sie denken)

Eine verlockende Intuition sagt: mehr Historie, klügere KI. Die Funktionsweise moderner Support-KI zeigt in die andere Richtung.

KI-Agents antworten aus Ihrer Wissensdatenbank – aktuelle, kuratierte Artikel – und nicht, indem sie sich durch Jahre roher Konversationen graben. Wo vergangene Tickets überhaupt helfen, sind es die jüngeren, sauber gelösten: Sie zeigen, wie Ihr Team heute formuliert, für das Produkt, das Sie heute ausliefern. Alte Tickets beschreiben Produkte, die Sie längst verändert haben, Richtlinien, die Sie ersetzt haben, und Behelfslösungen, die Sie repariert haben. Sie einzuspeisen fügt keine Weisheit hinzu, sondern Widersprüche – und Widersprüche zeigen sich als selbstbewusst falsche Antworten.

Einen Effekt zweiter Ordnung übersehen Teams regelmäßig: Veraltete Historie verschmutzt auch die Suche der Agents. Wenn jemand „Rückerstattungsrichtlinie“ nachschlägt und Treffer aus drei Richtlinien-Generationen bekommt, erbt die darauf aufgebaute KI-Antwort genau diese Verwirrung. Ein ausgedünnter, aktueller Korpus ist kein Kompromiss zulasten der KI-Qualität – er ist die KI-Qualität. Deshalb ist eine Migration im Stillen das beste KI-Readiness-Ereignis, das ein Support-Team je bekommt: Sie erzwingt den Korpus-Frühjahrsputz, den sonst niemand terminiert.

Der Rahmen: behalten, archivieren, löschen

Drei Körbe, entschieden je Datenklasse statt je Ticket:

• Behalten (live migrieren): die letzten 12–24 Monate an Konversationen, alle Kontakte samt benutzerdefinierten Feldern, die vollständige Wissensdatenbank sowie offene und kürzlich geschlossene Streitfälle unabhängig vom Alter. Das deckt nahezu jeden realen Abruf ab – und alles, wovon die KI profitiert.
• Archivieren (exportieren, ablegen, nicht importieren): alles Ältere, als schreibgeschützter Export in strukturiertem Format – JSON mit Index schlägt CSV für alles, was Sie je durchsuchen könnten – plus die Anhänge, in einem Speicher, den Sie kontrollieren. Archive sind für die seltene Prüfung, den Streitfall oder die nostalgische Nachfrage da; im Suchindex Ihres Arbeitswerkzeugs haben sie nichts verloren.
• Löschen: als Spam geschlossene Tickets, Ein-Wort-Wechsel, Bounce-Müll und Testtickets. Das ist kein riskanter Minimalismus, sondern Rauschunterdrückung. Das Archiv der Abwesenheitsnotizen hat noch nie jemand gebraucht.

Der Rahmen hat einen angenehmen Nebeneffekt: Ihr neuer Helpdesk startet schnell und bleibt schnell, weil sein Suchindex Signal statt Sediment trägt.

Aufbewahrungspflichten, im Klartext

Hier neigen Teams entweder zu großen Versprechen oder zur Schockstarre – bleiben wir also schlicht und ehrlich. Aufbewahrungsregeln sind real, sie fallen unterschiedlich aus – und dieser Artikel ist keine Rechtsberatung.

Ein paar allgemeine Muster, die man kennen sollte:

• Für manche Unterlagen gilt in bestimmten Branchen und Rechtsräumen eine vorgeschriebene Mindestaufbewahrung – typischerweise etwa abrechnungsnaher Schriftverkehr, Beschwerden in regulierten Branchen oder Unterlagen mit Vertragsbezug. Die Pflicht hängt dabei meist am Unterlagentyp, nicht am Helpdesk als Ganzem.
• Datenschutzregime ziehen in die entgegengesetzte Richtung: Der Grundsatz der Datenminimierung erwartet, dass personenbezogene Daten nicht länger aufbewahrt werden als für einen benannten Zweck nötig. „Wir haben alles für immer behalten, weil Migrieren mühsam war“ ist kein Zweck.
• Archivierung befreit Daten nicht von Datenschutzpflichten. Ein Ticket im Kaltspeicher bleibt ein personenbezogenes Datum: Löschersuchen, Auskunftsersuchen und Meldepflichten reichen auch dorthin.

Der praktische Schritt: Lassen Sie vor der Migration die Person, die bei Ihnen Recht oder Compliance verantwortet, Aufbewahrungsfristen je Datenklasse aufschreiben – Tickets, Kontakte, Anhänge, CSAT –, selbst wenn am Ende eine schlichte Tabelle mit drei Zeilen steht. Die Migration setzt diese Tabelle dann um. Mehr Beziehung braucht es zwischen beiden nicht: Die Rechtsseite entscheidet, die Migration führt aus.

Personenbezogene Daten im Archiv

Wenn Sie dem Rahmen folgen, sammeln sich alte personenbezogene Daten genau im Archiv – behandeln Sie es also bewusst:

• Zugriff einschränken. Der laufende Helpdesk arbeitet mit rollenbasierten Rechten; Ihr Archiv sollte das auch tun. Ein für alle lesbarer Speicher mit zehn Jahren Kundenkonversationen ist ein Risiko, kein Backup.
• Ein Manifest führen: was im Archiv liegt, welche Zeiträume es abdeckt, in welchem Format – und wer die Aufbewahrungsfrist freigegeben hat. Ihr künftiges Ich durchsucht bei einem Löschersuchen das Manifest statt des Rohdumps.
• Für das Löschen bauen. Legen Sie Daten je Kundin und Kunde so ab, dass sich die Unterlagen einer einzelnen Person entfernen lassen, ohne alles auszupacken. Ein Archiv, aus dem Sie nicht löschen können, ist eine Pflicht, die Sie nicht erfüllen können.
• Ein Ablaufdatum setzen. Entscheiden Sie, wann das Archiv selbst überprüft oder vernichtet wird, und tragen Sie es in den Kalender ein. Aufbewahrung ohne Enddatum ist Horten mit Richtliniendokument.

Was das für Ihren Migrationsplan bedeutet

Die Aufbewahrungsentscheidung formt die Migration selbst um, und zwar zum Guten: Der Live-Import schrumpft auf einen Bruchteil des naiven „alles umziehen“-Plans – kürzere Importfenster, saubere Suche ab Tag eins und ein KI-Korpus, der scharf startet statt trüb. Teams, die sich für 12–24 Monate plus Streitfälle entscheiden, sehen den Import regelmäßig in Stunden statt in Tagen fertig werden.

Bei der Migration mit MoveDesk wählen Sie die Historientiefe direkt beim Import – und weil die White-Glove-Migration kostenlos ist und beide Tools parallel laufen können, starten Sie mit 12 Monaten, leben einen Monat damit und holen tiefere Historie später nach, falls die Realität je danach fragt. Nach unserer Erfahrung tut sie das selten.

Schreiben Sie die Drei-Körbe-Tabelle noch diese Woche – behalten, archivieren, löschen, mit einer Aufbewahrungsfrist je Klasse. Eine Seite, die Ihre Migration kleiner macht und Ihre Datenhygiene unterwegs gleich mit hebt.