Eine zugesagte Erstattung wird zurückgenommen. Was eine Plattform dabei wirklich verliert.

Eine Zusage, die zwei Tage hält

Am 9. April 2026 bestätigt ein Support-Mitarbeiter eines großen europäischen Lieferdienstes schriftlich eine Erstattung von 22,71 EUR. Die Bestellung war bezahlt, aber nie angekommen. Der Kunde nimmt die Zusage sofort an.

Am 11. April nimmt ein anderer Mitarbeiter die Zusage zurück. Begründung: Der Kunde habe sich erst am 6. April gemeldet und damit außerhalb der 48-Stunden-Frist. Das stimmt nicht. Die erste Meldung lag zu diesem Zeitpunkt über drei Wochen zurück.

Der Fall liegt uns vollständig vor, mit Chatverlauf und Zeitstempeln. Er ist klein. Genau deshalb ist er brauchbar. Er zeigt an einem einzigen Ticket, was passiert, wenn ein Support-System kein Gedächtnis hat und jeder Mitarbeiter die Entscheidung des vorigen überschreiben darf. Wir nennen diesen Zustand Operational Decay: Die Prozesse laufen weiter, aber die Zusagen des Unternehmens verlieren nach und nach ihre Verbindlichkeit.

Der Ablauf über dreieinhalb Wochen

18. März 2026. Bestellung aufgegeben, Betrag abgebucht, Ware kommt nicht an. Die GPS-Daten zeigen den Fahrer in der Nähe der Adresse. Es gibt kein Klingeln, kein Foto, keine Unterschrift. Die Plattform wertet eine Lieferung als erledigt, sobald der Fahrer einen Umkreis um die Adresse betritt, den sogenannten Geofence. Ob der Kunde die Ware bekommt, prüft niemand. Das System kennt nur “im Umkreis” oder “nicht im Umkreis”. Das Fehlen eines Fehlersignals gilt als Erfolg.

19. März. Der Kunde meldet das Problem über den Support in der App. Diese Meldung verschwindet später aus seiner Historie. Darauf kommen wir zurück.

19. März bis 4. April. Keine Reaktion. Das Ticketsystem, ein zugekauftes Werkzeug eines Drittanbieters, sortiert nach Alter, Kundenkategorie und Betrag. Ein einzelnes Ticket über 22 EUR rutscht nach unten. Das ist keine Bosheit. Es ist die Folge eines Systems, das auf Durchsatz eingestellt ist und nicht auf Verlässlichkeit. In dieser Zeit bestellt der Kunde bei anderen Anbietern. Der Wechsel kostet ihn nichts, die andere App ist schon installiert.

5. April. Der Kunde meldet sich zum dritten Mal. Mitarbeiter A antwortet innerhalb weniger Minuten, freundlich, mit Namen, mit Entschuldigung und mit einer Rückfrage nach der Lieferadresse. Die Adresse steht in der Bestellung. Die Antwort enthält keinen Bezug auf das bestehende Ticket. Sie hätte auf jedes andere Ticket genauso gepasst.

7. April. Der Kunde bestätigt die Adresse. Mitarbeiter A fragt, ob eine Erstattung als Guthaben in der App in Ordnung wäre. Der Kunde stimmt zu.

9. April. Mitarbeiter B übernimmt den Fall, ohne dass der Kunde darüber informiert wird. Er spricht die Erstattung von 22,71 EUR als Guthaben aus. Der Kunde nimmt schriftlich an. Ab hier gibt es eine Vereinbarung: Das Unternehmen hat eine Leistung zugesagt und der Kunde hat sie angenommen.

11. April. Mitarbeiter C übernimmt und nimmt die Zusage zurück. Die Begründung mit der 48-Stunden-Frist ist doppelt falsch. Erstens lag die erste Meldung am 19. März und nicht am 6. April. Zweitens spielt die Frist keine Rolle mehr, sobald ein Kollege die Erstattung bereits zugesagt hat. Mitarbeiter C sieht das offenbar nicht oder darf es nicht berücksichtigen, weil die Regel im System die Ablehnung als richtig markiert.

11. und 12. April. Der Kunde bittet zweimal um Weiterleitung an einen Vorgesetzten. Beide Male wird ihm die Weiterleitung zugesagt. Beide Male meldet sich niemand. Der Kunde lässt den Betrag über seine Bank zurückbuchen und reicht eine Beschwerde bei der Rechtsabteilung und beim Datenschutz der Plattform ein. Eine Beschwerde beim Europäischen Verbraucherzentrum bereitet er vor. Bei der Plattform bestellt er nicht mehr.

Warum die Antworten so höflich und so leer sind

Die Nachrichten von Mitarbeiter A und Mitarbeiter C haben dasselbe Muster. Fehlerfreie Sprache, Anrede mit Namen, eine Entschuldigung, ein Textbaustein. Kein Hinweis darauf, dass jemand den Verlauf gelesen hat. So sehen Antworten aus, die ein Sprachmodell vorformuliert, also eine KI, die Texte schreibt. Der Mitarbeiter liest gegen, klickt auf Senden und wechselt zum nächsten Chat.

Ob es hier genau so war, wissen wir nicht. Das Muster passt aber zu dem, was in großen Supportorganisationen üblich ist. Ein Mitarbeiter betreut mehrere Chats gleichzeitig. Gemessen wird die Zeit pro Vorgang. Wer einen alten Fall wirklich liest, ist langsamer als die Kollegen. Das System belohnt die kurze Antwort und bestraft das Verstehen.

Forschung zu Unterbrechungen bei Wissensarbeit, etwa von Gloria Mark an der University of California, Irvine, zeigt, dass ständige Wechsel zwischen Aufgaben Tempo erzeugen und zugleich Stress und Druck. Ein Mitarbeiter, der zwischen vier Chats springt, kann einen Fall mit drei Wochen Vorgeschichte in der Zeit, die ihm bleibt, nicht erfassen. Er sieht Ticketnummer, Betrag, Regel und Ablehnungsgrund. Er sieht nicht die Zusage seines Kollegen.

Das Bittere daran: Dasselbe Sprachmodell, das die höfliche Antwort schreibt, könnte den gesamten Verlauf in Sekunden zusammenfassen und dem Mitarbeiter sagen, dass eine Zusage bereits existiert. Dafür müsste das Modell den Verlauf aber sehen. Diese Verbindung fehlt in den meisten Ticketsystemen.

Was die Ablehnung kostet

Der Streitwert bleibt über den ganzen Verlauf bei 22,71 EUR. Die Kosten auf Seiten der Plattform wachsen mit jeder Runde.

Drei Mitarbeiter haben den Fall bearbeitet. Die Rückbuchung über die Bank löst bei der Plattform Gebühren und Bearbeitung aus, egal wie der Streit ausgeht. Die Beschwerde bei der Rechtsabteilung bindet Juristen. Jede dieser Positionen kostet mehr als der Betrag, um den es geht. In Summe liegt der interne Aufwand nach unserer Einschätzung bei einem Vielfachen der Erstattung. Eine genaue Zahl haben wir nicht. Sie hängt von Stundensätzen und Abläufen ab, die wir nicht kennen.

Dazu kommt der Kunde. Er gibt nach eigener Angabe rund 500 EUR im Monat bei Lieferdiensten aus. Selbst wenn nur ein Teil davon auf diese Plattform entfiel, sind die Bestellungen eines einzigen Monats mehr wert als die verweigerte Erstattung. Über Jahre gerechnet geht es um einen Betrag, der die 22,71 EUR um Größenordnungen übersteigt.

Position	Ablehnung	Sofortige Erstattung
Erstattung	gespart	ausgezahlt
Bearbeitung	drei Mitarbeiter, Rückbuchung, Rechtsabteilung	ein Mitarbeiter, eine Aktion
Kunde	verloren	bleibt

Die Entscheidung ist also nicht sparsam. Sie ist teuer. Sie wirkt nur sparsam, weil das Ticketsystem allein die Erstattung zählt und alles andere in anderen Abteilungen anfällt.

Warum das System trotzdem ablehnt

Die Mitarbeiter handeln in ihrem Ausschnitt richtig. Mitarbeiter C sieht eine Regel und einen Antrag. Er sieht weder, wie viel der Kunde bestellt, noch dass ein Kollege bereits zugesagt hat. Und selbst wenn er beides sähe: Das System gibt ihm keine Befugnis, von der Regel abzuweichen.

Das ist das Grundproblem regelbasierter Support-Logik. Sie stellt sicher, dass jede einzelne Entscheidung zur Regel passt. Sie stellt nicht sicher, dass die Summe der Entscheidungen zum Unternehmen passt.

Vertrauen sinkt nicht langsam, es kippt

Vertrauen in eine Plattform baut sich über viele Bestellungen auf, die einfach funktionieren. Das kostet die Plattform nichts, es entsteht nebenbei. Eine gebrochene Zusage reicht, um es zu beenden. Es gibt kein “etwas weniger Vertrauen”. Der Kunde bestellt weiter oder er bestellt woanders.

Lieferdienste geben viel Geld für Neukunden aus, für Gutscheine, Anzeigen und Empfehlungsprogramme. Die Plattform in diesem Fall hat also mit einiger Wahrscheinlichkeit mehr für die Gewinnung dieses Kunden bezahlt, als sie ihm jetzt verweigert. Um ihn zu ersetzen, muss sie das noch einmal bezahlen und dann Monate warten, bis der neue Kunde so regelmäßig bestellt wie der alte.

Mehr Mitarbeiter machen es nicht besser

Die übliche Antwort auf wachsendes Supportvolumen lautet: mehr Leute. Der Fall zeigt, warum das allein nichts bringt.

In einem Team mit drei Leuten kennt jeder die Fälle der anderen. In einem Team mit dreihundert kennt niemand die Fälle von irgendwem. Jeder Wechsel des Bearbeiters ist eine Übergabe. Jede Übergabe verliert Kontext, wenn das System ihn nicht mitträgt. Hier waren es drei Bearbeiter und drei verschiedene Entscheidungen: A fragt nach, B löst, C hebt die Lösung auf. Das ist keine Eskalation. Das ist Zufall.

Ab einer gewissen Teamgröße überwiegen die Übergabeverluste den Gewinn an Kapazität. Wo diese Grenze liegt, hängt vom Werkzeug und von den Regeln ab. Sicher ist nur: Mehr Leute in dasselbe System zu setzen, verschiebt sie nach unten.

Die Alternative ist nicht mehr Personal, sondern ein System, das den Kontext hält. Ein Sprachmodell mit Zugriff auf den vollständigen Verlauf, den Wert des Kunden und die Regeln kann in Sekunden erkennen, dass hier bereits eine Zusage existiert. Nicht, weil es klüger wäre als ein Mensch. Sondern weil es nicht parallel acht Chats bedient und den ganzen Verlauf auf einmal liest.

Die verschwundene Erstmeldung

Ein Detail verdient einen eigenen Abschnitt. Die Meldung vom 19. März ist aus der Historie des Kunden in der App verschwunden. Er kann sie nicht mehr aufrufen.

Dafür gibt es drei mögliche Erklärungen. Erstens eine automatische Archivierung: Tickets ohne Aktivität werden nach einer Frist aus der aktiven Ansicht genommen. Der Kunde sieht sie nicht mehr, der interne Support schon. Zweitens ein Systemwechsel oder ein Update, bei dem alte Tickets nicht vollständig übernommen wurden. Drittens eine Löschung nach Regel, etwa um Speicher zu sparen.

Für den Kunden ist die Ursache egal. Das Ergebnis ist in allen drei Fällen dasselbe: Die Plattform beruft sich auf eine Frist und kann gleichzeitig nicht zeigen, wann die Kommunikation begonnen hat. Der Kunde kann es, mit Screenshots und Bestätigungsmails.

Drei Punkte sind hier wichtig.

Auskunftsrecht. Nach Artikel 15 DSGVO kann der Kunde eine Kopie aller Daten verlangen, die das Unternehmen über ihn gespeichert hat. Wenn die Meldung vom 19. März in dieser Auskunft fehlt, muss das Unternehmen erklären, warum. Wurde sie gelöscht, braucht es dafür eine Grundlage. Existiert sie noch, muss sie in der Auskunft auftauchen.

Nachweis der Frist. Wer eine Frist gegen einen Kunden geltend macht, muss in der Regel belegen können, wann sie begonnen hat. Ein System, das die Erstmeldung nicht mehr zeigt, kann das nicht. Wie ein Gericht das im Einzelfall bewertet, hängt vom anwendbaren Recht ab. Der Punkt bleibt: Das Unternehmen argumentiert mit Daten, die es selbst nicht mehr hat.

Nachvollziehbarkeit. Die GoBD, die Regeln für die Aufbewahrung steuerrelevanter Unterlagen in Deutschland, gelten nicht automatisch für jedes Support-Ticket. Der Gedanke dahinter gilt aber für jede geschäftliche Kommunikation: Was du später brauchst, um eine Entscheidung zu begründen, musst du aufbewahren können.

Die technische Lösung ist einfach. Jede Nachricht, jedes Ticket und jede Statusänderung wird angehängt und nie gelöscht, in der Fachsprache ein Append-only-Log. Der Kunde sieht seine gesamte Historie, jederzeit. Speicher für Textnachrichten kostet fast nichts, auch bei Millionen Tickets im Jahr. Wir bauen solche Systeme auf eigenen Servern bei Hetzner in Deutschland, weil wir dann selbst bestimmen, was gespeichert wird und wie lange. Wie sich Datenschutz und solche Systeme vertragen, steht in unserem Artikel zur DSGVO als vermeintlicher Innovationsbremse.

Vier Ursachen, die sich wiederholen

Dieser Fall ist kein Ausreißer. Wir sehen dasselbe Muster in Projekten immer wieder, wenn der Support auf einem zugekauften Ticketsystem läuft, das auf Durchsatz eingestellt ist.

Kein Gedächtnis. Jeder Mitarbeiter sieht ein Ticket, nicht eine Beziehung. Eine Regel, nicht eine Geschichte. Einen Betrag, nicht einen Kunden, der seit Jahren bestellt.

Regeln ohne Kundenwert. Eine 48-Stunden-Frist ist bei Gelegenheitskunden mit Missbrauchsrisiko sinnvoll. Bei einem Stammkunden ist sie unsinnig. Die Regel unterscheidet nicht, weil sie den Kunden nicht kennt. Die Daten wären da, aber die Entscheidungslogik hat keinen Zugriff darauf. Das gleiche Problem beschreiben wir für Vertriebsdaten im Artikel über CRM-Systeme als Datengräber.

Keine Endgültigkeit. Wenn A zusagt und C widerrufen kann, gibt es keine Verbindlichkeit. Jede Zusage ist ein Zwischenstand.

Falsche Kennzahlen. Wer Support an Bearbeitungszeit und Ticketdurchsatz misst, bekommt schnelle Ablehnungen. Ein Mitarbeiter, der ein Ticket in fünf Minuten ablehnt, steht besser da als einer, der zwanzig Minuten investiert und den Kunden hält. Es wird das Falsche gemessen, ähnlich wie bei Meetings, deren Kosten niemand sieht.

Wie eine Support-Logik aussieht, die Zusagen hält

Drei Regeln reichen, um den beschriebenen Fall unmöglich zu machen.

Zusagen sind endgültig. Sobald ein Mitarbeiter eine Erstattung zusagt und der Kunde annimmt, wird der Vorgang im System als abgeschlossen markiert. Ein nachgelagerter Mitarbeiter kann ihn nicht mehr ändern. Nur eine Führungskraft darf das, mit dokumentiertem Grund.

Der Kundenwert entscheidet mit. Bevor eine Erstattung abgelehnt wird, rechnet das System: Was bestellt dieser Kunde im Jahr und wie wahrscheinlich geht er nach einer Ablehnung? Übersteigt der erwartete Verlust den Betrag deutlich, wird die Erstattung ohne weitere Prüfung freigegeben. Die Schwelle legst du selbst fest.

Die Historie bleibt. Keine automatische Archivierung, kein Löschen nach Frist. Der Kunde kann seine gesamte Kommunikation jederzeit einsehen. Wer seine Daten transparent hält, muss sich nicht auf Fristen berufen, die er nicht belegen kann.

Ehrlicherweise: Ob du diese Regeln in deinem bestehenden Ticketsystem umsetzen kannst, hängt vom Werkzeug ab. Viele erlauben eigene Regeln und Sperren, manche nicht. Wer die Logik selbst betreibt und das Ticketsystem nur als Datenablage nutzt, hat die Freiheit dazu. Wer ganz vom Anbieter abhängt, wartet darauf, dass die Funktion irgendwann kommt. Was diese Abhängigkeit über die Jahre kostet, rechnen wir im Artikel zur SaaS-Abo-Falle vor.

Was du bei dir prüfen kannst

Fünf Fragen, die du an dein eigenes Support-System stellen kannst. Du brauchst dafür keinen Techniker, nur Zugang zum System und einen echten Fall.

1. Kann ein Mitarbeiter die Zusage eines Kollegen aufheben, ohne dass jemand es freigeben muss?
2. Sieht ein Mitarbeiter beim Öffnen eines Tickets, wie viel dieser Kunde im letzten Jahr bestellt hat?
3. Kann ein Kunde seine vollständige Kommunikation mit dir einsehen, auch nach Monaten?
4. Was passiert technisch, wenn ein Mitarbeiter “an das Management weitergeleitet” schreibt? Landet das Ticket bei einer Person oder zurück im Pool?
5. Woran wird dein Support-Team gemessen? Wenn nur die Bearbeitungszeit zählt, weißt du, was du bekommst.

Wenn zwei oder mehr Antworten unangenehm ausfallen, lohnt sich ein genauerer Blick. Wenn du dabei Unterstützung willst, melde dich. Ein Blick auf einen konkreten Fall reicht oft, um zu sehen, wo es hakt.