Buchungsportale behalten, eigenen Kanal daneben bauen: in welcher Reihenfolge

Buchungsportale abzuschalten, sobald die eigene Plattform steht, ist der naheliegende Plan und in der Praxis der riskanteste. Portale bringen Reichweite, die ein neuer Kanal erst aufbauen muss. Tragfähig ist die umgekehrte Reihenfolge: zuerst ein eigener Bestand, dann die Anbindung der Portale, zuletzt ein Anlass, direkt beim Betrieb zu buchen oder zu bestellen.

Warum Buchungsportale nicht der Gegner sind

Ein Betrieb, der Touren, Termine, Zimmer oder Ware über Portale und Marktplätze verkauft, zahlt dort nicht nur Provision. Die Plattform entscheidet, an welcher Stelle sein Angebot erscheint, welche Bewertungen daneben stehen und welche Kontaktdaten er vom Kunden überhaupt zu sehen bekommt. Wer ein zweites Mal kommt, bucht wieder über das Portal, weil der Betrieb ihn auf keinem anderen Weg erreicht.

Daraus entsteht oft der Wunsch nach einem harten Schnitt. Er scheitert an einer einfachen Asymmetrie: Das Portal wird von Menschen gefunden, die den Betrieb noch nicht kennen, die eigene Seite anfangs nur von denen, die ihn schon kennen. Wir behandeln Buchungsportale beim Aufbau deshalb als Kanal, der bleibt, und legen mit dem Betrieb fest, woran er erkennt, dass sich Buchungen nach innen verschieben. Das Ziel ist nicht, Portale loszuwerden, sondern nicht mehr von einem einzigen abzuhängen.

Schritt eins: ein Bestand, der nicht im Portal wohnt

Bei vielen Betrieben lebt das Angebot inzwischen in den Portalen selbst: Beschreibungen, Bilder, Preise, Zeitfenster und Stornobedingungen, jeweils in der Maske des Anbieters gepflegt und überall ein wenig anders. Eine eigene Plattform, die diesen Stand abschreibt, erbt jede Abweichung und wird zur nächsten Stelle, an der gepflegt werden muss.

Der erste Arbeitsschritt ist deshalb ein Bestand, der beim Betrieb liegt: ein Datenmodell für Angebote, Kapazitäten, Preise und Regeln, aus dem später jeder Kanal gespeist wird. Führt der Betrieb Termine bereits in einem Kalender oder Artikel in einer Warenwirtschaft, wird dieses System zur Quelle, und die Plattform liest daraus, statt eine zweite Liste zu führen.

Wie viel an diesem Schritt hängt, zeigt der Tagesausflugsanbieter OneDayTours aus Lissabon. Er pflegte sein Angebot parallel in 14 Sprachen, zusätzlich zur Abhängigkeit von Buchungsportalen mit hohen Provisionen. Mit der eigenen Plattform, die das Angebot an einer Stelle hält, über mehrere Kanäle veröffentlicht und KI-gestützt übersetzt, lautet das Ergebnis dort: −68 % Pflegeaufwand.

Schritt zwei: Buchungsportale anbinden, bevor der eigene Kanal öffnet

Erst wenn der Bestand steht, verbinden wir ihn mit den Portalen, und zwar in beide Richtungen. Verfügbarkeiten und Preise gehen aus dem eigenen System hinaus, Buchungen aus den Portalen kommen herein und belegen dieselbe Kapazität wie eine Buchung über die eigene Seite. Fehlt diese Verbindung, führt jemand im Betrieb zwei Kalender, und jede direkte Buchung gefährdet den nächsten Portalgast. Wie dieser Abgleich über alle Kanäle funktioniert, erklärt der Lexikonartikel zum Channel Manager.

Die Reihenfolge hat einen praktischen Grund. Jedes Portal hat eigene Regeln dafür, wie Daten übergeben werden, wie oft sie abgefragt werden dürfen und was bei einem Konflikt geschieht. Das lässt sich nur am echten Datenfluss prüfen. Deshalb läuft die Verbindung eine Zeit lang mit, während der Betrieb weiter wie gewohnt verkauft, und wir vergleichen die Belegung in beiden Systemen, bevor der eigene Kanal für Kunden öffnet.

Eine Grenze gehört ehrlich dazu: Nicht jedes Portal bietet eine Schnittstelle. Wo keine existiert, bleibt ein Abgleich über dessen Export oder die Pflege von Hand. Welcher Weg für welches Portal gilt, steht vor dem Start im Angebot, damit niemand eine Automatik erwartet, die es nicht geben kann.

Schritt drei: ein Grund, direkt zu buchen

Eine Buchungsseite allein holt niemanden aus dem Portal. Kunden buchen direkt, wenn sie einen Grund haben: Sie kennen den Betrieb bereits, sie haben nach dem ersten Besuch einen Weg zurück, und die Buchung ist auf dem Telefon mit wenigen Eingaben erledigt. Zum eigenen Kanal gehört deshalb mehr als ein Formular: eine installierbare Web-App oder Anwendung, über die eine Wiederholungsbuchung kurz bleibt, eine Bestätigung, die den Kontakt beim Betrieb hinterlegt, und eine Adresse, die auf Beleg, Karte und Bestätigungsmail steht.

Hier endet auch, was Software entscheiden kann. Ob Direktkunden einen Vorteil bekommen, etwa großzügigere Stornobedingungen, legt der Betrieb fest, und manche Portalverträge regeln, was er dabei darf. Diese Klauseln prüfen wir nicht, das gehört in die Rechtsberatung des Betriebs. Wir bauen die Regeln so, dass er sie ändern kann, ohne die Plattform anfassen zu lassen.

Wie wir den eigenen Kanal aufbauen

In einem Auftrag stehen die drei Schritte als getrennte Lieferungen im Angebot, jede mit eigenen Abnahmekriterien: das Datenmodell mit dem übernommenen Bestand, die Anbindung der Portale mit dem Vergleich der Belegung, der Kanal für Kunden. Repository und Zugänge liegen von Anfang an beim Betrieb, Kundendaten aus direkten Buchungen stehen in seiner Datenbank statt in der eines Portals. Verarbeiten wir dabei personenbezogene Daten im Auftrag des Betriebs, schließen wir einen Auftragsverarbeitungsvertrag.

Die Oberfläche für Telefon und Browser bauen wir unter App-Entwicklung, das System dahinter mit Verfügbarkeit, Regeln und Schnittstellen zu Portalen und Kalender unter Softwareentwicklung.