Grundsätzliche Funktionsweise von Internet Booking Engines (IBE)

Eingabe-Formular

Zurück zum Eingabe-Formular. Prinzipiell sollte es für die IBE-Anbieter möglich sein, dieses Formular beliebig im Aussehen zu verändern. Trotzdem findet man im Internet oftmals die gleichen Eingabe-Formulare, die dann lediglich einige Farben geändert haben. Sicherlich hängt das damit zusammen, dass individuelle Anpassungen des Designs, Kosten verursachen, auf die sehr gerne verzichtet werden. Allerdings muss das nicht sein. Leider haben die Anbieter bei der Entwicklung ihrer Web-Oberfläche zu wenig an diesen Anspruch gedacht. Mit modernen Technologien und einer darauf ausgelegten Entwicklung, wäre eine individuelle Gestaltung der IBE-Maske durchaus möglich.

Weiterhin bieten diese Eingabe-Formulare verschiedene Hilfsfunktionen für den Benutzer, um die Eingabe zu erleichtern. Dazu zählen insbesondere ein Kalendarium zur Auswahl der Flugtage, eine integrierte Suche nach Flughafen-Codes (3-Letter-Code), aber auch die gleichzeitige Auswahl von regional zusammenliegenden Flughäfen (z.B. Abflug Deutschland West) gehört dazu. Gerade bei der Auswahl der Flughäfen können neue Technologien wie z.B. AJAX den Eingabekomfort erhöhen. Damit lässt sich dann z.B. schon während der Eingabe der ersten Buchstaben eine Liste von möglichen Flughäfen anzeigen. Zum Teil wird diese Technik bereits eingesetzt.

Die optische Gestaltung des Eingabe-Formulars ist meiner Meinung nach, sehr wichtig. Bei einer immer älter werdenden Gesellschaft (und damit auch potentiellen Kunden), sind Miniatur-Formulare die kaum lesbar sind, nicht gerade Benutzerfreundlich. Auch fällt mir immer wieder auf, dass bereits hier (wie auch später bei der Anzeige der Ergebnisse), gerne Fachbegriffe auf der Webseite erscheinen, die ein Endkunde nicht unbedingt kennen muss. Ein gutes Eingabe-Formular sollte also auch so Begriffe wie "Gabelflug" o.ä., auf Wunsch des Benutzers, genau erklären können.

Die Suche nach Flügen

Nachdem der Benutzer seine gewünschten Flugdaten in dieses Formular eingegeben hat und die Suche ausgelöst hat, kommt das Herzstück einer IBE zum Tragen - die eigentliche Suchmaschine. Aber was und wo sucht diese Maschine?

Diese Frage sollte eigentlich jeder Betreiber - und NICHT der Hersteller - einer IBE beantworten. Denn es kommen nun viele Faktoren ins Spiel, die über das Was, Wie und Wo entscheiden. Fangen wir einmal mit dem Wo an:

Als Datenquelle für die Anzeige in der IBE dienen im Regelfall ein oder mehrere Reservierungssysteme, die an die IBE angebunden werden. Weiterhin können und werden zusätzlich Datenbanken mit speziellen Tarifen abgefragt, die nicht über ein CRS abrufbar sind. Bei diesen sogenannten Nego-Tarifen handelt es sich um speziell mit der jeweiligen Fluggesellschaft verhandelten Tarifen, die typischerweise den Großkunden der Fluggesellschaften (wie z.B. Consolidator, große Portale oder auch großen Flugverkäufern) zur Verfügung gestellt werden.

Theoretisch können auch beliebige andere Datenquellen in die Suche integriert werden. Oftmals verwenden die IBE-Hersteller dazu sogenannte Schnittstellen. Das bedeutet, dass die eigentliche Datenquelle nicht im näheren Bereich der IBE (z.B. ein lokales Netzwerk oder eine Festplatte) ist, sondern diese Daten von anderen Dienstleistern zur Verfügung gestellt werden und meist über das Internet mit speziellen Befehlen abrufbar sind. Ein Beispiel dafür wäre die Einbindung von Charter-Flugdaten oder auch von Low Cost Carriern.

Was wird Wie gesucht?

Das Was und das Wie lassen sich nicht so einfach trennen. Deswegen zeige ich hier das Zusammenspiel auf. Im Prinzip ist das Was einfach zu formulieren: passende Flugangebote aus den o.g. Datenquellen suchen und dem Benutzer zur Auswahl anzeigen. Doch was ist ein passendes Flugangebot? Hier scheiden sich in den verschiedenen Systemen oftmals die Geister. Ist es ein reines Preis-Angebot ohne geprüft zu haben, ob noch Plätze auf der Maschine frei sind? Ist es ein Angebot, das bereits auf Verfügbarkeit geprüft ist und unmittelbar gebucht werden kann? Ist es ein Alternativ-Angebot, falls die gewünschten Daten kein (sinnvolles) Ergebnis liefern? Was heißt dann Alternative? Andere Flugdaten? Andere Strecke?

Die Beantwortung dieser Fragen sollte jeder IBE-Betreiber für sich durchführen. Dazu sollte er allerdings einiges über das Wie verstehen, da durch diese Antworten auch verschiedene Kosten für den laufenden Betrieb der IBE entstehen können. Deshalb schauen wir uns als nächstes an, welche Kosten entstehen können.

Im Regelfall entstehen keine weiteren Kosten bei den Abfragen der Low Cost Carrier. Bei den Linienfluggesellschaften sieht das allerdings schon ganz anders aus. Auch wenn es zukünftig eventuelle Direktverbindungen von den IBE's zu den Airline-Systemen geben wird, ist derzeit noch die Praxis, dass Linienfluggesellschaften über mindestens ein Reservierungssystem angeschlossen sind. Und bei diesem Zugriff auf diese Daten, können durchaus Kosten entstehen.

Transaktionskosten

Jeder Zugriff auf das Reservierungssystem (CRS) erzeugt eine sogenannte Transaktion, die gelegentlich auch "Scan" genannt wird. Das ist in etwa vergleichbar mit jeder direkten Eingabe im CRS, die mit der Enter-Taste abgeschlossen wird. Diese Transaktionen verursachen Kosten in unterschiedlichen Höhen bei den Reservierungssystemen. Und eben diese Kosten werden an den Webseiten-Betreiber weiter gereicht. Dabei ist die Kostenhöhe im Regelfall von der Wertigkeit der Abfrage abhängig. Hier ein einfaches Beispiel: eine Darstellung einer bestehenden Buchung im CRS verursacht sehr geringe Kosten, die Abfrage der Verfügbarkeit kostet schon etwas mehr und die volle Preisermittlung einer Buchung ist noch teurer.

Mit dem Wissen über die eventuell anfallenden Kosten, können wir uns nun wieder der "Was"-Frage widmen. Will man nun seinem Kunden auf der Internet Booking Engine z.B. ausschließlich bereits auf Verfügbarkeit geprüfte und vollkommen mit Preisen versehene Flüge anzeigen, hat das prinzipiell zur Folge, dass eine hohe Anzahl an (teuren) CRS-Transaktionen notwendig sind. Der Benutzer erhält zwar dadurch sehr verlässliche Informationen angezeigt. Allerdings: kommt es nicht zur gewünschten Buchung, bleibt man auf den Kosten sitzen. Das andere Extrem wäre, dass der IBE-Betreiber sich dazu entschließt, auf der Webseite nur ungeprüfte Informationen anzuzeigen. Dadurch spart er sich zunächst einige Transaktionskosten. Allerdings besteht die Gefahr, dass der so angelockte Kunde einen günstigen Flug nun buchen möchte und bei der dann notwendigen Verfügbarkeitsprüfung bzw. bei der Preisermittlung der gewünschte Flug gar nicht mehr buchbar ist bzw. der Preis sich erhöht hat. Die Konsequenz daraus könnte sein, dass der Kunde dieses Spiel maximal ein- bis zweimal mitmacht und aufgrund von Erfolgslosigkeit zu einer anderen Webseite wechselt.

Bei fast allen IBE's gibt es die Möglichkeit, mittels einer sehr feinen Konfiguration, die gerade erwähnten Funktionen sehr detailliert einzustellen. Lassen Sie sich im Zweifelsfall von Ihrem IBE-Betreiber genau erklären, welches Für und Wider sich durch jede Veränderung der Konfiguration ergibt und ob es weitere Konfigurationsmöglichkeiten zur Optimierung in Ihrem Sinne gibt.

Daten zwischenspeichern

Apropos IBE-Hersteller: die Problematik mit den Transaktionskosten ist den Herstellern schon seit geraumer Zeit bekannt und auch (zurecht) ein Dorn im Auge. Zwar konnten (und können?) sie an der Kostenweitergabe der CRS nichts ändern, aber sie können Mechanismen in Ihre Software einbauen, die die Transaktionen minimieren. Nach meiner Ansicht ist dabei ein wesentlicher Faktor die Verwendung eines Cache. Cache kommt aus dem Englischem und bedeute soviel wie Zwischenspeicher. Möglicherweise haben Sie den Begriff auch schon einmal im Zusammenhang mit Festplatten oder Internet-Browsern gehört. Beim Letzteren z.B. werden Elemente (wie z.B. Bilder) von besuchten Webseiten auf der lokalen Festplatte zwischengespeichert. Besucht man nun die Webseite erneut und das Bild hat sich in der Zwischenzeit nicht geändert (was z.B. beim Logo in der Regel zutrifft), ruft der Browser dieses Bild nicht erneut aus dem Internet ab, sondern benutzt das vorher zwischengespeicherte Bild.

Übertragen auf eine IBE bedeutet das, dass ein Cache einer IBE die Verfügbarkeits- und Preisanfragen an ein CRS zwischenspeichert und wenn ein weiteres mal diese Flugverbindung abgefragt wird, wird die Antwort aus dem Cache geliefert und nicht erneut beim CRS angefragt. Damit spart man sich weitere Transaktionskosten. Dieser durchaus nützliche Mechanismus hat aber auch Begleiterscheinungen.

Zum einen muss dabei geklärt sein, wie lange ein Eintrag im Cache noch gültig ist. Da ja rund um die Uhr über verschiedene Kanäle im CRS gebucht wird, muss ein Flug, der vor 5 Minuten noch frei war, jetzt nicht mehr unbedingt Verfügbar sein. Im Idealfall kann der IBE-Betreiber selbst festlegen, welche Informationen im Cache, wie lange gültig sind. Hier können durchaus unterschiedliche Ansprüche vorhanden sein. Ein Webseitenbetreiber, der überwiegend seine Flugpreise in Preisvergleichsmaschinen wie z.B. Kelkoo veröffentlicht, hat voraussichtlich den Anspruch, dass die ermittelten Preise im Cache eine Gültigkeit von 24 Stunden haben. Dagegen kann eine Webseite den Anspruch haben, ein gesunden Mittelweg zwischen eventuell veralteten Cache-Daten und CRS-Transaktion zu nutzen und eine maximale Gültigkeit von 5 Minuten tolerieren.

Der zweite Punkt, der bei einer Nutzung eines Caches bedacht werden muss, ist die Frage, wie oft es vorkommen kann, dass überhaupt eine Flugverbindung ein zweites mal abgefragt und damit aus dem Cache angezeigt werden kann. Bezieht sich dann der Cache auf nur eine einzige Buchungs-Webseite, die nur 100 Besucher am Tag hat, dann ist bereits vorauszusehen, dass der Cache wohl selten zum Einsatz kommt. Da ist ein Cache natürlich um ein vielfaches wirkungsvoller, wenn er die Daten aus möglichst vielen Buchungs-Webseiten sammelt und eben auch diesen wieder zur Verfügung stellt. Das wird in der Regel nur dann erzielt, wenn der Cache (und damit meistens die gesamte IBE) zentral beim IBE-Hersteller gehalten wird und die eigentliche Buchungs-Oberfläche in die eigene Webseite eingebunden wird.

Wie bereits erwähnt, versuchen die IBE-Hersteller derzeit, einzelne Fluggesellschaften direkt über eine Schnittstelle in ihre Systeme zu integrieren und damit die teuren CRS-Kosten zu umgehen. Mit der zunehmenden Vereinheitlichung der Schnittstellen wird das nach meiner Ansicht auch nicht mehr lange dauern (wenn es nicht teilweise schon geschehen ist). Das wird CRS nicht gerade erfreuen, da nicht nur die Transaktionen dann wegfallen, sondern am Ende natürlich auch die Buchungen. Doch da müssen die CRS mit leben, haben sie doch nicht zuletzt wegen der hohen Transaktionskosten dafür gesorgt, dass die IBE-Betreiber und -Anbieter überhaupt alternative Verbindungen zu den Airlines suchen.

Wartezeit

Egal, wie nun die Anfrage des Kunden bearbeitet wird, entsteht sehr häufig eine längere Wartezeit für den Kunden an seinem Bildschirm. Nahezu alle Systeme zeigen während dieser Wartezeit, in der die Anfrage bearbeitet wird, eine spezielle Webseite an, die den Benutzer um Geduld bei der Ermittlung der Ergebnisse bietet. Ich persönlich finde die "Warteseiten" am Besten, die mir am wirkungsvollsten vermittelt, was das System gerade tut. Dazu reicht z.B. die wechselnde Einblendung einer Information wie z.B. "Suche gerade bei Airline XY". Zuletzt habe ich sogar eine Buchungsmaschine gesehen, die während der Suche bereits die ersten Ergebnisse einblendete und sobald ein weiterer Treffer hinzukam, der günstiger war, diesen dann nach oben in der Liste einsortierte. Allerdings wird dadurch wiederum sehr häufig die Anzeige aktualisiert, was bei langsamen Internet-Verbindungen unerwünscht sein kann.

Steuern und Gebühren

Während der Abfrage muss die IBE noch ein etwas unschönes Detail beachten - die Berechnung der Steuern und Gebühren. Und diese Berechnung ist nicht immer trivial. Zum einen entstehen erneut Transaktionskosten beim CRS, die wiederum versucht werden durch zwischengespeicherte Steuern zu minimieren. Zum anderen ist diese Minimierung teilweise gar nicht möglich, da eine effektive Berechnung bei einigen Fluggesellschaften nur anhand einer in der Buchung vorhandenen Flugnummer erfolgen kann. Meines Wissens nach ist das z.B. bei der British Airways der Fall. Hier muss die IBE schon bereits bei der Preisermittlung eine Pseudo-Buchung anlegen, um zu den richtigen Steuern und Gebühren zu kommen, obwohl noch gar nicht klar ist, ob der Kunde diesen Flug auch buchen will. Notwendig wird diese Berechnung allerdings immer bleiben, da die gesetzlichen Rahmenbedingungen es nicht erlauben, nur den Flugpreis anzuzeigen und den Verweis "zuzüglich Steuern und Gebühren" einzublenden. Der Verbraucher soll dadurch die Möglichkeit erhalten, den tatsächlichen Endpreis eines Fluges mit dem eines anderen zu vergleichen. Und bei den heute vorherrschenden hohen Steuern und Gebühren, die oftmals den eigentlichen Ticketpreis überschreiten, ist das wohl auch angebracht.

Das Ergebnis

Nun haben wir, ob mit oder ohne Cache, die Fluganfrage des Kunden ausgeführt und zeigen ihm das Ergebnis an. Die optische Darstellung der Egebnisse ist mitunter recht unterschiedlich. Ich meine, dass hier vor allem der persönliche Geschmack entscheidend ist. Im Regelfall wird das Ergebnis in einer tabellarischen Form dargestellt, die der Benutzer von oben nach unten "durchsuchen" kann. Den Kundenwünschen entsprechend wird gleichzeitig das Ergebnis aufsteigend nach dem Preis sortiert. Ob das immer so sein muss, weiß ich nicht. Allerdings kann ich mir gut vorstellen, dass es Nischen-Bereiche gibt, wo die Flugauswahl nach anderen Kriterien stattfinden kann, als nach dem Preis.

Manche IBE blendet bei dieser Ergebnismenge auch noch eine Alternative ein. So wird eventuell ein günstigerer Tarif optional angezeigt, der bei einem veränderten Flugtag buchbar wäre.

Die Buchung

Hat der Kunde sich nun für einen Flug entschieden, findet er im Regelfall in unmittelbarer Nähe zu dieser Verbindung eine Schaltfläche "Buchen" oder ähnlich. Wie bereits ausgiebig im oberen Teil erwähnt, kann es von hier an für den Benutzer recht reibungslos weiter gehen, wenn bereits zuvor auf Verfügbarkeit geprüft wurde und der Zeitraum zwischen dieser Prüfung und dem "echten" Buchen recht kurz war. Jede IBE wird nun trotzdem noch einmal die Verfügbarkeit prüfen und dem Kunden ein Eingabe-Formular anzeigen, dass für den Abschluss der Buchung benötigte Daten abfragt.
Wurde die Verfügbarkeit zuvor allerdings noch nicht geprüft bzw. kam diese Information aus Cache, kann es sein, dass der Kunde nun feststellen muss, dass das zuvor angezeigte und güstige Angebot gar nicht mehr buchbar ist. Dann bringt ihn die IBE normalerweise wieder in die Ergebnisliste zurück, mit dem Verweis, einen anderen Flug auszuwählen.

Gehen wir nun von dem günstigen Fall aus, dass alles Verfügbar ist, so wie der Kunde es gerne möchte. Wie bereits erwähnt, fragt nun die IBE weitere Daten mit einem Eingabe-Formular ab. Das sind zum einen Passagierdaten. Gegebenenfalls muss der Kunde auch sein Geburtsdatum eingeben, wenn der ausgewählte Tarif nur für bestimmte Altersgruppen erlaubt ist. Weiterhin werden die Kundendaten, also die Informationen zur Rechnungserstellung, abgefordert. Zu guter Letzt muss der Kunde sich für eine Zahlungsart entscheiden. Hier sollten alle IBE's in der Lage sein, die Zahlungsarten abzuwickeln, die der Betreiber einer Buchungs-Webseite akzeptieren möchte.

Im weiteren Verlauf der Buchung hat die IBE nun die Aufgabe, die Buchung im CRS (oder einem anderen angeschlossenem Airline-System) abzuschließen, eventuell den Zahlungsvorgang online abzuwickeln (z.B. bei Kreditkartenzahlung) und dem Kunden eine Bestätigung/Rechnung anzuzeigen bzw. zuzuschicken. Im Idealfall lässt der IBE-Hersteller dem Betreiber individuell konfigurieren, welche Daten bestätigt bzw. in Rechnung gestellt werden und in welcher Form.

Der allerletzte Teil wäre noch, wenn die IBE und/oder das angeschlossene CRS einen Datensatz für die Weiterverarbeitung der Buchung in einem Backoffice-System zur Verfügung stellen würde.

Ich hoffe, mit diesem Beitrag dem interessierten Leser einen Überblick über IBE's gegeben zu haben. Sicherlich ist das ein oder andere nur oberflächlich beschrieben oder zwischenzeitlich haben sich Änderungen in den Systemen ergeben. Außerdem erhebe ich hier keinen Anspruch auf vollständige Darstellung aller IBE-Funktionalitäten. Falls Sie Ergänzungen in irgendeiner Form zu diesem Beitrag haben, würde ich mich über entsprechende Kommentare freuen.