Digital Tourist Office

Dokumentation der Arbeite am Digital Tourist Office an den Open Tourism Data Hackdays am 27. und 28. Oktober 2017 in Arosa.

Links:

• Projektseite: http://hack.opendata.ch/project/131/star
• GitHub: https://github.com/opentourism/tourism_office3dot0
• Open Tourism Hack Days: http://hack.opendata.ch/event/9

Teilnehmer in der Arbeitsgruppe:

• Janine Bunte, Schweizer Jugendherbergen
• Mike Schudel, GIScube
• Daniel Takai, Silberrücken AG
• Cristian Margiotta, dialogic.io
• Martin Wirth, Dizmo
• Roman Gaudenz, Objtec
• Stefan Kuhn, Zürich
• Graham Tritt, Bern / Neuseeland

Inhalt

Hintergrund        2

Projektziel        2

Der Gast        3

Destinationsdaten        4

Prototyp Architektur        5

Geschäftskontext        7

Hintergrund

Der Schweizer Tourismus hinkt in der Digitalisierung hinterher. Der Markt für die Vermittlung von Unterkünften beispielsweise wird durch booking.com, Google Hotel Adds  und AirBnB dominiert, die ihre eigenen Datenbestände pflegen und dem lokalen Tourismusgeschäft durch hohe Kommissionen schädigen. Dies ist den Firmen möglich, weil sie über ihre eigenen Datenbestände verfügen.

Zudem ist es für Gäste nicht immer einfach lokal Angebote zu finden, beispielsweise in Vorbereitung einer Reise.  Auch hier gibt es keine Datenangebote auf denen Drittanbieter ihre Services aufsetzen können. Zudem ist die Präsentation dieser Daten, auf welchem Kanal auch immer, sehr schwierig aufgrund des breiten Kulturspektrums der Gäste.

Projektziel

Ziel: Das Projekt soll dem Gast ein optimales Reiseerlebnis ermöglichen.

Zweck: Die Arbeit des Tourismusbüros soll zu einer hohen Zufriedenheit des Gastes, und damit seiner Retention beitragen; zum Zwecke der Erhöhung der Gästezahl einer Destination.

Messkriterium: Die Anzahl der Gäste steigt.

Strategie: Das Tourismusbüro stellt dem Gast die Gesamtheit des Leistungsangebots einer Destination zur Verfügung, und unterstützt ihn bei der bestmöglichen Auswahl seines individuellen Reiseerlebnisses.

Der Gast

Zu Beginn de Hackathons machten wir uns Gedanken über die möglichen Daten rund um den Gast, die für die Entdeckung seiner Bedürfnisse relevant sein könnten. Das folgende Foto des Scribbles fasst diese Daten zusammen:

Destinationsdaten

Wir machten uns ausserdem Gedanken um die Daten der Destination, die benötigt werden, die im auf dem folgenden Foto dokumentiert sind:

Prototyp Architektur

Nach der ersten Diskussion rund um die Daten teilte sich das Projektteam in zwei Streams. Im ersten Stream wurde ein Prototyp für die Vermittlung der Tourismusdaten an den Gast und ihre Visualisierung besprochen. Die folgenden zwei Fotos zeigen Details und Diskussionsergebnisse rund um den Prototyp.

Geschäftskontext

Der zweite Stream beschäftigte sich mit der Geschäftsarchitektur des Systems mit einem Fokus auf die beteiligten Akteure im System Digital Tourist Office. Die Diskussion lief bis spät in die Nacht und wurde auch am kommenden Morgen mit verschiedenen Experten aus dem Tourismusgeschäft vertieft. Das oben abgebildete Foto spiegelt das Diskussionsergebnis grob wieder. Folgende wesentliche Erkenntnisse konnten wir erarbeiten:

• Das Tourismusgeschäft ist fragmentiert, weil die verschiedenen Akteure zueinander in Konkurrenz stehen.
• Es gibt keine gemeinsamen Angebote aus der Destination heraus, weil die Akteure nicht nur miteinander in Konkurrenz stehen, sondern solche Angebote auch Kosten verursachen, die schwierig finanzierbar sind.
• Es braucht aber eine kollektive Anstrengung, die nur aus der öffentlichen Hand, bzw. durch die Tourismusvereine geleistet werden kann.
• Damit solch ein Unternehmen erfolgreich sein kann, sind Partikularinteressen der Akteure auszuschalten. Somit sind konkurrenzierende Kommissionsmodelle als Grundlage der Finanzierung nicht geeignet.
• Wir sehen die Finanzierung ergänzend über die Gästekarten oder Kurtaxe einer Destination.
• Die finanziellen Mittel über die Kurtaxe bzw Gästekarte sind beschränkt, weswegen eine Subvention von Initialprojekten durch Drittfinanzierung (NRP, Innotour, KTI) geboten erscheint.

Bezüglich der Geschäftsfunktionen der Plattform, die im Rahmen eines MVP notwendig wären, identifizierten wir die folgenden:

• Broking: Vermittlung zwischen den Interessen eines Gastes und den Angeboten. Beide Seiten haben sehr reiche, und von Destination zu Destination verschiedene, sich entwickelnde Datenmodelle. Generell erscheint eine Implementierung auf Basis von GraphQL für explorative, lernende Agenten eine interessante Möglichkeit.
• Inspiration: Die Angebote sollten dem Gast über verschiedene Kanäle attraktiv präsentiert werden. Für die Kanäle Mobile / Web sind entsprechende Content Funktionen vorzusehen.
• No Payment: Da alle Akteure über einen oder sogar mehrere Payment Services verfügen, muss das System Digital Tourist Office dieses nicht selber vorsehen. Dies eliminiert die Notwendigkeit eines Clearing Office, und senkt zudem die Anforderungen an die Verfügbarkeit der Plattform.
• Daten: Wesentliche Daten neben der Präsentation eines konkreten Angebots sind Öffnungszeiten, Geokoordinaten und die aktuelle Kapazität.

Für den Ausbau einer Plattform würden wir vor allem das Payment identifizieren, weil dies dem System die folgenden Möglichkeiten eröffnet:

• Kommissionsmodelle werden möglich um die Entwicklung der Plattform finanzieren zu können.
• Ein Fondsystem für die Finanzierung von Tourismusprojekten in der Destination wäre möglich.
• Eine “interne Währung” für den Kauf von Dienstleistungen der Destination und für den Tausch von Leistungen unter den Leistungserbringern.