Eine Airbnb-Buchung, mehrere E-Mails,
eine Zeile

Was eine Reservierungs-E-Mail enthält und was sie auslässt

Eine Reservierungs-E-Mail ist ein vollständiges Buchungsdokument für den Moment, in dem sie gesendet wurde, und ein unvollständiges für jeden Moment danach. Die Bestätigung enthält den Bestätigungscode, den Namen des Gastes, das Inserat, die Check-in- und Check-out-Daten, die Anzahl der Nächte, die Anzahl der Gäste, den Gesamtbetrag, den der Gast gezahlt hat, Ihren Verdienst für den Aufenthalt und, wenn der Gast bei der Buchung eine hinterlassen hat, seine Nachricht.

Die Daten stehen im Nachrichtentext. Wenn zusammen mit der Bestätigung eine Kalenderdatei eingeht, enthält sie Daten und eine Zusammenfassungszeile, aber nicht den Bestätigungscode, den Gast oder das Geld. Das ist der erste Punkt, den Sie klären sollten, bevor Sie eine Weiterleitungsregel wählen: Der Nachrichtentext ist das Dokument.

Airbnb versendet außerdem von mehr als einer Adresse. Die eigene Hilfeseite zu fehlenden Benachrichtigungen nennt [email protected], [email protected] und [email protected] als Adressen, die Sie zu Ihren Kontakten hinzufügen sollten – ein nützlicher Hinweis für jede Absender-Positivliste: Erlauben Sie die Adressen, die Airbnb tatsächlich verwendet, nicht eine geratene Adresse.

Was die E-Mail auslässt, ist ebenso wichtig. Sie enthält nicht die E-Mail-Adresse des Gastes. Die Telefonnummer des Gastes wird erst nach Bestätigung der Reservierung verfügbar und verschwindet aus der Reservierung, sobald eine Stornierung bearbeitet wird. Die Nachricht enthält nicht das Auszahlungsdatum, den aktuellen Status der Buchung oder eine Historie der Änderungen. Wegen dieser Lücken kann eine Bestätigung einen Datensatz eröffnen, aber nicht der Datensatz sein.

Die Bestätigung sagt Ihnen, dass eine Buchung existiert. Sie kann Ihnen nicht sagen, ob diese Buchung noch so aussieht wie beim Versand der E-Mail.

Drei Nachrichten, die eine Buchung verändern

Eine Buchung, die sich nie ändert, erzeugt trotzdem eine Bestätigung und eine Auszahlung. Eine Buchung, die sich ändert, erzeugt ein zweites Dokument, das dem ersten widerspricht – und genau diesen Widerspruch muss die Tabelle auflösen.

Eine Änderung beginnt als Anfrage. Airbnbs Hilfeseite für Gastgeber erklärt, dass ein Gast eine Reiseänderungsanfrage senden kann und dass Gäste ihre Reservierung auch über den Link in der Bestätigungs-E-Mail ändern können. Die Änderung wird innerhalb von Airbnb ausgehandelt und angewendet. Die aufschlussreichere Zeile steht in Airbnbs eigener Anmerkung zur Verwaltung von Änderungen mit Software: Reservierungsänderungen können über Ihre Software weder angenommen noch abgelehnt werden und müssen im Airbnb-Konto bearbeitet werden. Wenn ein Property-Management-System dieses Ereignis nicht selbst verarbeiten kann, hat eine nachgelagerte Tabelle keine Chance, es sei denn, die Änderungs-E-Mail wird erfasst.

Eine Stornierung ist eine separate Nachricht mit drei gleichzeitigen Folgen. Airbnbs Hilfeseite für Gastgeber besagt, dass bei einer Stornierung durch den Gast der Gastgeber sofort benachrichtigt wird, die Daten freigegeben werden und Auszahlungen und Rückerstattungen koordiniert werden. Nichts davon ist eine neue Buchung, und nichts davon lässt sich aus der ursprünglichen Bestätigung ableiten.

Auszahlungen laufen nach einer anderen Uhr. Airbnbs Zahlungsbedingungen besagen, dass der Gastgeber per E-Mail benachrichtigt wird, wenn jede Auszahlung initiiert wird. Eine Auszahlung kann mehrere Reservierungen abdecken, weshalb eine Auszahlungszeile und eine Buchungszeile selten eins zu eins übereinstimmen.

Eine Änderungsnachricht ist oft kürzer als eine Bestätigung. Sie sagt, was sich verschoben hat, statt die ganze Buchung zu wiederholen – deshalb kann eine Spalte, die aus einer Bestätigung gefüllt wird, bei einer Änderung leer bleiben. Das ist zu erwarten. Der Bestätigungscode und der Ereignistyp sind die Felder, die eine Änderungsnachricht liefern muss.

Warum die Tabelle die Änderung verpasst

Die Tabelle verpasst eine Änderung, weil die Änderung auf Airbnb abgeschlossen wird und die Tabelle nur weiß, was im Postfach angekommen ist.

Die meisten Weiterleitungsregeln beziehen sich auf die erste Nachricht. Ein Filter, der um die Worte „reservation confirmed" herum gebaut ist, erfasst keine spätere Nachricht über eine Stornierung, und eine Regel, die auf einer Betreffzeile basiert, erfasst immer nur ein Ereignis. Die wichtigsten Nachrichten sind die, die nach dem Schreiben der Regel eintreffen.

Die zweite Ursache ist die reine Anhängextraktion. Jede verarbeitete E-Mail wird zu einer Zeile – das richtige Verhalten für eine Prüfspur und das falsche für ein Statusfeld. Nichts überschreibt die frühere Zeile, also behält die Bestätigung ihre alten Daten und sieht dabei vollständig aus.

Die dritte ist der Verknüpfungsschlüssel. Eine Betreffzeile nennt meist den Gast, nicht den Bestätigungscode. Fehlt der Code oder steht er in einer anderen Vorlage an anderer Stelle, teilen die beiden Zeilen keinen Wert, über den die Tabelle sie abgleichen könnte. Am Ende haben Sie zwei plausible Zeilen und keine Regel, welche aktuell ist.

Leiten Sie alles weiter, taucht ein viertes Problem auf: Anfragen, Buchungsanfragen und Erinnerungen nennen denselben Gast und dieselben Daten, sodass sie wie Reservierungen wirken. Eine später abgelehnte Anfrage hat bereits eine Zeile erzeugt. Eine Erinnerung für einen stornierten Aufenthalt hält die alten Daten im Protokoll am Leben.

Das Ergebnis ist eine bestimmte Art von Fehler. Ein Gast verschiebt einen zwei Nächte langen Aufenthalt um zwei Tage. Die Bestätigungszeile sagt weiterhin Dienstag. Die Reinigungskraft plant die Wechselreinigung anhand der Tabelle, der Buchhalter zählt die ursprünglichen Nächte, und die Zeile sieht fertig aus – deshalb prüft sie niemand erneut. Die Daten wurden nie falsch eingegeben. Ein späteres Ereignis wurde einfach nie auf eine frühere Zeile angewendet.

Eine Reservierungs-E-Mail ist ein Ereignis. Eine Buchungstabelle ist eine Aufzeichnung. In der Lücke dazwischen lebt das falsche Check-in-Datum.

Dasselbe Momentaufnahme-Problem zeigt sich bei Bestellbestätigungs-E-Mails im E-Commerce, wo eine Adressänderung oder eine Stornierung eine Zeile hinterlassen kann, die richtig aussieht und falsch versendet wird. Der Unterschied liegt hier im Volumen: Ein Shop sendet eine Bestätigung pro Bestellung, während eine Kurzzeitvermietung eine Bestätigung, eine Änderung, eine Stornierung und eine Auszahlung sendet – und jede beschreibt dieselbe Reservierung aus einem anderen Blickwinkel.

Leiten Sie die E-Mails in ein Postfach, das den Nachrichtentext liest

Der Einstiegspunkt ist eine Postfachadresse, keine Airbnb-Integration. E-Mail-Postfach gibt einem Konto eine dedizierte Adresse für Airbnb-Buchungs-E-Mails: Alles, was dorthin gesendet oder weitergeleitet wird, landet in der Verarbeitungswarteschlange, und eine Absender-Positivliste hält fremde Mail fern. Die Einstellung, die für Airbnb zählt, ist die, die festlegt, wo gelesen wird.

Eine Vorlage deckt alle vier Nachrichtenformen ab, weil der Abgleich semantisch erfolgt. Das reicht aus, um Airbnb-Buchungsdaten aus einer Bestätigung, einer Änderung, einer Stornierung und einer Auszahlung zu extrahieren, ohne für jede einen Parser zu benötigen. Eine Änderungsnachricht, die das Check-in-Datum nicht wiederholt, lässt diese Zelle leer, statt sie mit einer Vermutung zu füllen – genau das Verhalten, das Sie in einem Journal wollen. Wenn die Buchung als Screenshot statt als E-Mail bei Ihnen eingeht, deckt die Feld-für-Feld-Anleitung zum Herausziehen von Bestätigungscodes und Daten aus Buchungs-Screenshots diese Eingabe ab. Dieselbe Einstellung „nur Nachrichtentext“ macht auch in einen E-Mail-Text geschriebene Rechnungen extrahierbar, und die allgemeine Version dieses Routing-Musters wird im E-Mail-Parser-Workflow behandelt.

Jedes Ereignis behalten, eine Zeile pro Reservierung anzeigen

Die Tabelle, die aus dem Postfach kommt, ist ein Ereignisprotokoll, und das sollte sie bleiben, denn die Stornierungsnachricht ist der einzige Beweis, dass die Buchung storniert wurde. Fügen Sie einen zweiten Tab für die Ansicht hinzu, mit der Sie arbeiten, und lassen Sie den Bestätigungscode entscheiden, welche Zeile die Buchung repräsentiert.

Behalten Sie im Rohdaten-Tab jede verarbeitete Nachricht in Eingangsreihenfolge und fügen Sie eine Sequenzspalte mit =ROW() hinzu. Eine höhere Zeilennummer bedeutet eine spätere Nachricht – die einzige Uhr, die Sie brauchen, wenn der Export keinen Empfangszeitstempel enthält. Verweisen Sie im Arbeitstab in Google Sheets mit einer Formel auf den Rohdaten-Tab, sortieren Sie nach dem Code und dann nach der Sequenznummer, neueste zuerst, und behalten Sie die erste Zeile pro Code:

=UNIQUE(SORT(Emails!A2:L, 1, TRUE, 2, FALSE))

Das liefert eine Zeile pro Bestätigungscode, und weil die Sortierung das neueste Ereignis nach oben setzt, ist die überlebende Zeile die neueste. Eine Änderung ersetzt die Daten. Eine Stornierung ersetzt den Status. Die früheren Zeilen stehen weiterhin im Rohdaten-Tab – genau das wollen Sie, wenn ein Buchhalter fragt, warum sich eine Auszahlung verschoben hat.

Passen Sie die Spaltenbuchstaben an Ihr eigenes Layout an, da die Formel davon ausgeht, dass der Bestätigungscode in Spalte A und die Sequenznummer in Spalte B steht. Behalten Sie stornierte Zeilen in der Arbeitsansicht und filtern Sie sie heraus, wenn Sie die aktuelle Belegungsliste brauchen. Das Löschen einer Stornierungszeile entfernt die Erklärung für eine Rückerstattung, und nächsten Monat wird sich niemand mehr daran erinnern, warum das Geld fehlt.

Ein Fall löst sich nicht automatisch auf. Eine Nachricht, der tatsächlich ein Bestätigungscode fehlt, kann nicht darüber verknüpft werden, bleibt also im Rohdaten-Tab sichtbar und wird manuell zugeordnet. Das sollte selten vorkommen, und es ist besser, die verwaiste Zeile zu sehen, als dass eine Formel sie stillschweigend fallen lässt.

Wer welche Spalte liest

Eine Tabelle kann einen Gastgeber, einen Co-Gastgeber, eine Reinigungskraft und einen Buchhalter bedienen – aber nur, wenn jeder die für seine Aufgabe gebaute Ansicht öffnet.

Der Gastgeber arbeitet vom deduplizierten Tab aus. Er ist Belegungs- und Einnahmenprotokoll zugleich: Datum, Nächte, Gästezahl, Auszahlung und Status in einer Zeile pro Reservierung. Der Rohdaten-Tab dient der Prüfung einer Angabe, nicht der Monatsplanung.

Der Co-Gastgeber braucht den Namen des Gastes, die Daten, die Gästezahl und die Notiz, die der Gast bei der Buchung hinterlassen hat. Eine geteilte Tabellenansicht liefert das, ohne einen Airbnb-Login herauszugeben – wichtig, wenn ein Co-Gastgeber bei manchen Inseraten hinzugefügt ist und bei anderen nicht.

Die Reinigungskraft oder Einsatzleitung braucht drei Dinge: das Check-out-Datum, das Inserat und ob am selben Tag ein weiterer Gast eincheckt. Verweisen Sie diese Person auf den deduplizierten Tab, niemals auf den Rohdaten-Tab. Eine Reinigungskraft, die den Rohdaten-Tab liest, ist der häufigste Weg, auf dem ein korrigiertes Datum wieder falsch wird.

Der Buchhalter braucht die Gästesumme, die Reinigungsgebühr, Ihre Auszahlung und den Monat – und die stornierten Zeilen müssen stehen bleiben. Auszahlungsnachrichten gehören in einen eigenen Tab, weil eine Auszahlung mehrere Reservierungen abdecken kann und der Abgleich ein Vergleich zwischen zwei Körnungen ist: Buchungen und Bankereignisse. Ist das Ziel ein CRM statt einer Tabelle, wandert derselbe Feldsatz per CSV-Import hinüber; das Muster für E-Mails in CRM-Kontakte verwandeln gilt für den Gastdatensatz, wobei der Reservierungscode als Kennung Duplikate fernhält.

Was dieses Setup nicht kann

Die Grenze ist das Postfach. Dies liest die Mails, die Airbnb sendet, und nichts anderes – und einige der Grenzen sollten Sie kennen, bevor Sie die Tabelle bauen.

Dahinter steckt keine Airbnb-API. Airbnb bietet Gastgebern keine offene Reservierungs-API an; der Zugang gehört seinen Softwarepartnern, und die Liste der Preferred Software Partner 2025 besteht aus Property-Management- und Channel-Management-Systemen wie Guesty, Hostaway, Hospitable, OwnerRez, Lodgify, Beds24, Uplisting und Hostfully. Wenn Sie Zwei-Wege-Synchronisierung brauchen, ist das die Kategorie, aus der Sie kaufen – und ein anderer Kauf als ein Tabellen-Workflow.

Es gibt keine Kalender- oder PMS-Synchronisierung. Der Kalenderexport von Airbnb ist ein .ics-Feed, mit dem man Daten in einem anderen Kalender blockiert. Er enthält Daten, nicht den Gast, den Code oder die Auszahlung, und kann den Reservierungsdatensatz daher nicht ersetzen.

Nichts wird an Airbnb zurückgeschrieben. Die Tabelle kann keinen Preis ändern, Daten öffnen oder schließen, einen Gast anschreiben oder eine Stornierung bearbeiten. Sie protokolliert, was passiert ist; sie verwaltet das Inserat nicht.

Automatisierung der Gästekommunikation ist eine andere Aufgabe. Die meisten Ergebnisse für „Airbnb E-Mail-Automatisierung" drehen sich um geplante Antworten und Nachrichtenvorlagen. Dies hier deckt die Datenseite desselben Postfachs ab, und beides kann nebeneinander bestehen, ohne sich zu berühren.

Ein Ereignis, das nie per E-Mail eintrifft, bleibt unsichtbar. Wenn Buchungsbenachrichtigungen ausgeschaltet sind, wenn ein Gast anruft statt zu schreiben oder wenn eine Änderung im App-Thread vereinbart wird, erfährt die Tabelle nichts davon. Die E-Mail ist eine Kopie der Ereignisse der Plattform, nicht die Plattform selbst.

Die Kontaktdaten sind bewusst dünn. Keine E-Mail-Adresse des Gastes, eine Telefonnummer erst nach der Bestätigung und nach einer Stornierung gar keine Telefonnummer. Behandeln Sie die Tabelle als Betriebsaufzeichnung, nicht als Marketingliste.

FAQ

Verbindet sich das direkt mit Airbnb?

Nein. Es liest E-Mails, die Sie an ein dediziertes Postfach weiterleiten. Es gibt keinen Airbnb-Login, keine API-Verbindung und keine Kalendersynchronisierung. Der Vorteil ist, dass es mit den Nachrichten funktioniert, die Airbnb ohnehin sendet, auch von Adressen und Vorlagen, die sich ohne Vorankündigung ändern.

Welche Airbnb-E-Mails sollte ich weiterleiten?

Die Bestätigung, die Änderung, die Stornierung und die Auszahlung. Anfragen, Buchungsanfragen und Erinnerungen können ebenfalls hinein, wenn Sie das vollständige Protokoll möchten, aber sie fügen Zeilen hinzu, filtern Sie also nach Ereignistyp, bevor Sie die Tabelle jemandem aushändigen. Eine abgelehnte Anfrage ist keine Reservierung.

Kann es eine Änderungs-E-Mail von einer neuen Buchung unterscheiden?

Ja. Eine neue Buchung trägt einen neuen Bestätigungscode, während eine Änderung den Code der Reservierung wiederverwendet, die sie ändert, und die abgeleitete Spalte Ereignistyp erfasst, welche Art von Nachricht eingegangen ist. Wenn eine Änderungsnachricht den Code weglässt, kennzeichnet der Ereignistyp sie dennoch, und Sie verknüpfen diese Zeile manuell.

Löschen Stornierungen die Zeile?

Nein. Eine Stornierung fügt eine Zeile mit einem anderen Status hinzu, und die Arbeitstab zeigt den neuesten Status für diesen Code. Behalten Sie die Zeile: Sie erklärt die fehlende Auszahlung und die wieder freigegebenen Daten, und sie ist der einzige Nachweis, dass die Buchung nicht einfach verschwunden ist.

Funktioniert es für Vrbo, Booking.com und Direktbuchungen?

Ja. Das Postfach kümmert es nicht, welche Plattform die Nachricht gesendet hat. Fügen Sie die anderen Absender zur Positivliste hinzu, behalten Sie dieselben Spalten bei, und ein Portfolio, das über mehrere Kanäle bucht, landet in einer Tabelle. Direktbuchungsbestätigungen von Ihrer eigenen Website funktionieren genauso.

Wohin kommt die fertige Tabelle?

Exportieren Sie sie als XLSX oder CSV und öffnen oder importieren Sie sie in Google Sheets, oder importieren Sie die CSV in ein CRM. Das Google Sheets-Add-on ist auf Dateien ausgelegt, die Sie über seine Seitenleiste hochladen, daher folgt eine Postfach-Nachricht stattdessen dem Exportweg. Wenn Sie nach einer Möglichkeit gesucht haben, Airbnb-Reservierungen nach Google Sheets zu bekommen, ist der Export der letzte Schritt, und die Arbeit, die darüber entscheidet, ob die Tabelle stimmt, fand früher statt, als die Spalten und der Ereignistyp definiert wurden.

Die Zeile ist eine Entscheidung darüber, welche Nachricht zählt

Eine Airbnb-Reservierung ist kein einzelnes Dokument. Sie ist eine kurze Reihe von Nachrichten, und die Zeile in Ihrer Tabelle ist eine Entscheidung darüber, welche davon gewinnt. Sobald der Bestätigungscode der Schlüssel ist und die neueste Nachricht überlebt, ist die Tabelle keine Kopie Ihres Postfachs mehr, sondern etwas, das Sie einer Reinigungskraft, einem Co-Gastgeber oder einem Buchhalter aushändigen können, ohne einen Hinweis hinzuzufügen, welchem Datum zu trauen ist.

Probieren Sie es mit einer Reservierung aus, die sich geändert hat. Leiten Sie die Bestätigung und die Änderung weiter, legen Sie die Spalten einmal fest, und sehen Sie, welche Zeile die Ansicht behält. Wenn die Daten in der Zeile mit den Daten in der letzten E-Mail übereinstimmen, erledigt das Setup die Aufgabe, die die manuelle Version leicht zu überspringen machte.