Löschanfragen von Gästen bearbeiten: Ein Verifizierungs- und Reaktionsworkflow für Restaurants

Warum eine einzelne Löschtaste selten ausreicht

In vielen Betrieben verteilen sich Gastdaten über mehrere Systeme: das Reservierungstool, ein separates CRM oder Marketing-Tool, das Kassensystem (POS), gegebenenfalls eine Bewertungs- oder Feedback-Plattform und E-Mail-Verteiler. Wenn ein Gast eine Löschung verlangt und lediglich der Eintrag im Reservierungssystem entfernt wird, bleiben Kopien in anderen Systemen bestehen. Ein belastbarer Workflow beginnt deshalb mit einer Bestandsaufnahme: Wo genau werden Namen, Kontaktdaten, Präferenzen und Besuchshistorie eines Gastes gespeichert?

Der Rahmen: Verifizieren – Prüfen – Handeln – Dokumentieren

Für die praktische Umsetzung eignet sich ein vierstufiger Rahmen, der sich in jedem Betrieb unabhängig von der genutzten Software anwenden lässt. Er orientiert sich an den von der Europäischen Kommission veröffentlichten Datenschutzgrundsätzen, insbesondere Zweckbindung und Speicherbegrenzung, ohne eine bestimmte Software oder Rechtsordnung vorauszusetzen.

1. Verifizieren

• Bestätigen, dass die anfragende Person tatsächlich der betroffene Gast ist (z. B. Abgleich mit der bei der Buchung genutzten E-Mail-Adresse oder Telefonnummer).
• Klären, ob sich die Anfrage auf alle Daten oder nur auf bestimmte Nutzungen bezieht (z. B. nur Newsletter, nicht die Reservierungshistorie).
• Eingangsdatum der Anfrage festhalten, um die Bearbeitung nachvollziehbar zu machen.

2. Prüfen

• Feststellen, ob ein noch bestehender Zweck vorliegt, etwa eine offene Zahlung, eine bevorstehende Reservierung oder ein laufender Streitfall.
• Prüfen, ob gesetzliche oder betriebliche Aufbewahrungspflichten bestimmte Unterlagen betreffen (etwa Rechnungsbelege), unabhängig vom Löschwunsch.
• Bei Unsicherheit: interne Eskalation an die für Datenschutz verantwortliche Person oder externe rechtliche Beratung, bevor eine Entscheidung kommuniziert wird.

3. Handeln

• Löschung oder Anonymisierung in jedem betroffenen System durchführen: Reservierungstool, CRM, POS-Gastprofil, E-Mail-Verteiler, gegebenenfalls Reputationsmanagement-Tools.
• Bei teilweiser Löschung klar dokumentieren, welche Daten aus welchem Grund verbleiben.
• Bestätigung an den Gast senden, sobald die Umsetzung abgeschlossen ist.

4. Dokumentieren

• Anfrage, Prüfergebnis und durchgeführte Maßnahmen in einem internen Löschprotokoll festhalten.
• Protokoll getrennt von den gelöschten Gastdaten aufbewahren, damit im Zweifel nachweisbar bleibt, dass die Anfrage bearbeitet wurde.

Zweckbindung und Speicherbegrenzung bei Buchungsdaten

Zwei Grundsätze aus den Datenschutzprinzipien der Europäischen Kommission sind für Restaurants besonders relevant: Zweckbindung und Speicherbegrenzung. Zweckbindung bedeutet, dass personenbezogene Daten nur für den Zweck verwendet werden dürfen, für den sie erhoben wurden. Eine Telefonnummer, die für eine Tischreservierung angegeben wurde, ist damit nicht automatisch eine Erlaubnis für fortlaufende Marketing-SMS – dafür braucht es in der Regel eine gesonderte Einwilligung.

Speicherbegrenzung besagt, dass Daten nicht länger aufbewahrt werden sollen, als es der jeweilige Zweck erfordert. Für eine Restaurantbuchung heißt das praktisch: Sobald der Besuch abgeschlossen, bezahlt und ohne offene Reklamation ist, entfällt der ursprüngliche Zweck der Speicherung – es sei denn, es gibt einen weiteren legitimen Grund, etwa ein Treueprogramm, dem der Gast zugestimmt hat, oder eine gesetzliche Aufbewahrungspflicht für Belege. Die Kommission legt dabei keine feste Tagesanzahl fest, die für jeden Betrieb gilt; die konkrete Frist ergibt sich aus Zweck, nationalem Recht und branchenspezifischen Vorschriften.

Praktische Checkliste für die Bearbeitung

Grenzen dieses Workflows

Dieser Rahmen ersetzt keine Rechtsberatung. Er beschreibt eine operative Vorgehensweise, keine abschließende rechtliche Bewertung, ob und in welchem Umfang eine Löschpflicht im Einzelfall besteht. Ob eine Rechnung, ein Buchungsdatensatz oder eine Kommunikationsverlauf gelöscht werden muss oder aus finanz-, steuer- oder lebensmittelrechtlichen Gründen aufbewahrt werden darf, hängt vom jeweiligen nationalen Recht und der konkreten Datenkategorie ab. Restaurants mit mehreren Standorten oder Franchise-Strukturen sollten zudem klären, ob Daten zentral oder pro Standort verwaltet werden, da sich die Löschung sonst nur auf einen Teil der Systeme bezieht. Bei internationalen Gästen oder Buchungen über Drittplattformen kann zusätzlich zu klären sein, welche Partei – das Restaurant oder die Plattform – für welchen Teil der Daten verantwortlich ist.

Wie sich

Rollen und Eskalationsstufen im Tagesbetrieb

Der oben beschriebene Vierstufen-Rahmen funktioniert in der Praxis nur, wenn vorher feststeht, wer welche Entscheidung treffen darf. Ohne klare Rollenverteilung landen Löschanfragen oft bei der Person, die das Telefon oder die Mailbox zufällig zuerst öffnet – das führt zu uneinheitlichen Antworten gegenüber Gästen.

Empfohlene Eskalationsmatrix

Antwortfristen als internes Steuerungsinstrument

Die Datenschutzgrundsätze der Europäischen Kommission legen keine für jeden Betrieb identische Bearbeitungsfrist fest; welche gesetzlichen Fristen im Einzelfall gelten, ist eine Frage des jeweils anwendbaren nationalen Rechts und sollte separat geprüft werden. Unabhängig davon ist es sinnvoll, interne Zielzeiten zu definieren, damit Anfragen nicht unbearbeitet liegen bleiben.

1. Eingangsbestätigung: internes Ziel, dem Gast innerhalb eines festgelegten, betrieblich definierten Zeitraums den Erhalt der Anfrage zu bestätigen.
2. Prüfabschluss: internes Ziel für den Abschluss der Prüfung laufender Zwecke und Aufbewahrungspflichten.
3. Umsetzung in allen Systemen: internes Ziel für den Abschluss der technischen Löschung oder Anonymisierung.
4. Rückmeldung an den Gast: internes Ziel für die abschließende Information über Umfang und gegebenenfalls verbleibende Daten.

Diese Fristen sind betriebsinterne Steuerungsgrößen, keine rechtlich verbindlichen Vorgaben. Sie sollten schriftlich festgehalten und bei Bedarf an die tatsächliche Systemlandschaft des Betriebs angepasst werden.

Randfälle, die im Standardworkflow leicht übersehen werden

Anfragen über Drittplattformen

Wird eine Reservierung über eine externe Buchungsplattform angelegt, liegen Teile der Gastdaten möglicherweise ausschließlich bei der Plattform und nicht im eigenen Reservierungstool. Der Betrieb kann dann nur die Daten löschen, die er selbst gespeichert hat; für den plattformseitigen Datensatz ist der Gast an die Plattform zu verweisen.

Gruppen- und Firmenreservierungen

Bei einer Buchung, die eine Person für mehrere Gäste vorgenommen hat, ist zu klären, ob sich der Löschwunsch nur auf die anfragende Person oder auf weitere in der Buchung genannte Personen bezieht. Ohne deren eigene Bestätigung sollte keine Löschung fremder Daten allein aufgrund der Angabe eines Dritten erfolgen.

Papierbasierte Reservierungsbücher

In Betrieben, die noch analoge Reservierungslisten führen, muss der Workflow auch diese physischen Aufzeichnungen einschließen. Eine rein digitale Löschung reicht nicht aus, wenn derselbe Gastname zusätzlich handschriftlich in einem Buch oder auf einem Ausdruck steht.

Backups, Protokolldateien und unveränderliche Logs

Viele Systeme erstellen automatische Sicherungskopien oder technische Protokolle, aus denen einzelne Datensätze nicht sofort entfernt werden können. Hier ist intern zu dokumentieren, nach welchem Zyklus solche Backups turnusmäßig überschrieben werden, damit der Gast eine realistische Auskunft über den Zeitpunkt der vollständigen Entfernung erhält, statt eine sofortige vollständige Löschung zuzusichern, die technisch nicht eingehalten werden kann.

Verstorbene Gäste oder inaktive Konten

Anfragen von Angehörigen zu den Daten eines verstorbenen Gastes oder zu einem seit Jahren inaktiven Profil erfordern eine gesonderte Prüfung der Berechtigung der anfragenden Person, bevor überhaupt über den Inhalt der Anfrage entschieden wird.

Interne Messung ohne externe Vergleichswerte

Um den Workflow zu überwachen, sollte ein Betrieb ausschließlich mit eigenen, tatsächlich erhobenen Zahlen arbeiten – nicht mit Branchenschätzungen. Sinnvolle interne Kennzahlen sind etwa:

• Anzahl der im jeweiligen Zeitraum eingegangenen Löschanfragen.
• Anteil der Anfragen, die innerhalb der selbst gesetzten internen Zielzeit abgeschlossen wurden.
• Anzahl offener, noch nicht abgeschlossener Fälle zu einem Stichtag.
• Anzahl der Fälle, in denen eine teilweise Löschung wegen laufender Zwecke oder Aufbewahrungspflichten erforderlich war.

Diese Werte dienen der internen Nachverfolgung und Prozessverbesserung; sie sind keine Grundlage für Aussagen über allgemeine Branchenwerte oder Vergleiche mit anderen Betrieben, da hierzu keine belastbaren externen Daten vorliegen.

Weitere Grenzen des Workflows

Zusätzlich zu den bereits genannten rechtlichen Einschränkungen gilt: Ein interner Prozess kann technische Limitierungen einzelner Softwaresysteme nicht auflösen. Wenn ein Reservierungstool, CRM oder POS-System keine granulare Löschfunktion für einzelne Datenfelder anbietet, sollte dies gegenüber dem Anbieter des jeweiligen Systems angesprochen werden, statt intern eine Lösung zu improvisieren, die zu unvollständiger oder inkonsistenter Löschung führt. Der Workflow ist außerdem ein lebendes Dokument: Ändert sich die Systemlandschaft des Betriebs – etwa durch Wechsel des Reservierungstools oder Einführung eines neuen CRM –, muss die Bestandsaufnahme der betroffenen Systeme entsprechend aktualisiert werden, da sonst neue Speicherorte von Gastdaten im Prozess unberücksichtigt bleiben.

Primärquellen

• European Commission: data protection principles

FAQ

Redaktioneller Hinweis: ChefNet veröffentlicht diesen Leitfaden und entwickelt Produkte für Restaurantsuche und -betrieb. Allgemeine Betriebshinweise sind von Produktaussagen getrennt. Funktionen können sich im Verlauf der Pilotphase ändern. Veröffentlicht 2026-08-12.