Alternative Umsetzungsideen für den eTarif

In diesem Forum können Sie alle Fragen und Hinweise rund um die Gestaltung der App bzw. die Nutzerführung einbringen.
Antworten
AlexN
Beiträge: 49
Registriert: 9. April 2019 00:47

16. April 2019 17:51

Auch wenn der aktuelle Test des kilometerabhängigen eTarifs auf eine bestimmte Applikation zugeschnitten ist, kann es sinnvoll sein, offen über alternative Umsetzungsmöglichkeiten nachzudenken, zumal die VRS-Geschäftsführung hier mitliest.

Meines Erachtens muss die gesuchte Lösung folgende Anforderungen erfüllen:

1) Wartungsfreiheit, d.h. keine Installation irgendwelcher Hardware durch die Verkehrsbetriebe, um Folgekosten zu vermeiden, die sonst in Tickets eingepreist würden, wie es heute bei den Automaten der Fall ist;

2) Niedrige Einstiegshürde, d.h. sie muss so einfach zu bedienen sein, dass potenzielle Nutzer nicht schon vor der ersten Nutzung abgeschreckt, sondern vielleicht sogar animiert werden, ÖPNV zu nutzen und ein digitales Ticket zu kaufen - hierzu zählen sowohl die Frontend Usability als auch ein modernes Angebot an Zahlungsmethoden, v.a. Apple Pay/Google Pay;

3) Mißbrauchssicherheit, d.h. sie muss ausreichenden Schutz vor Leistungserschleichung durch zu viele Freiheiten oder Ausbeutung von technischen Schwächen der Infrastruktur gewährleisten;

4) Sparsamkeit beim Energie- und Datenverbrauch, sonst sind Servicekosten, die die Verkehrsbetriebe einsparen, einfach nur auf Fahrgäste umgewälzt, und das wird als nicht fair empfunden, darüber hinaus kommen Daten- und Akkufresser einfach nicht gut an;

5) Absolute Zuverlässigkeit, d.h. der Nutzer muss sicher sein, dass man auch bei Umständen, die er nicht zu vertreten hat, wie Nichtverfügbarkeit einer mobilen Datenverbindung, WLAN, GPS etc. die Fahrt antreten und beendigen kann, denn nur so wird man sich den Kauf von Papiertickets abgewöhnen, was von Verkehrsbetrieben angestrebt wird. Darüber hinaus können so Reklamationfälle minimiert werden.

6) Überwachungsfreiheit, d.h. sie muss ohne Tracking auskommen, damit man nicht in die Datenschutzbredouille kommt und damit die Nutzer nicht befürchten, dass mit ihren Daten ein Bewegungsprofil entsteht; darüber hinaus gibt es unterirdisch einfach kein GPS.

Die Lösung von Fairtiq erfüllt die Anforderungen 1 und 2, jedoch nicht 3 bis 6.

Ich stelle mir folgendes Produkt vor, das alle genannten Anforderungen erfüllen würde. Der Vorschlag resultiert aus der Erfahrung mit diversen ÖPNV-eTicketing-Verfahren in Europa und Nordamerika. Da ich sehr viel in verschiedenen Regionen unterwegs bin und vor Ort immer ÖPNV benutze, sind auf meinem Gerät mehrere dutzend solcher Apps installiert. Dadurch kenne ich verschiedene Tarifierungs- und Ticketingansätze.

Also. Die imaginäre Software ist in die marktübliche Kartensoftware wie Google Maps, Apple Maps oder Here Maps integriert. Man öffnet die Kartenapp, wählt den Start- und Zielort und lässt die Strecke berechnen. Daraufhin erscheint die Option "VRS" neben den anderen, die in die Kartensoftware auch integriert sind, z.B. myTaxi, Uber oder Lyft. Im Unterschied zu den genannten Diensten steht bei der VRS-Option ein verbindlicher Preis, der im Vergleich mit Taxipreisen immer gut aussieht. Bei der Preisberechnung läuft eine Günstigerprüfung auf der Basis der gewählten Strecke: Luftlinienpreis vs. Preisstufenpreis. Die günstigere Option wird zum Kauf angeboten. Auf diese Weise spricht man potenzielle Taxinutzer an, macht die Preisberechnung vor dem Kauf transparent und die Streckenberechnung wird von einer vertrauten Drittanbietersoftware übernommen.

Der Nutzer tippt auf Kaufen und wird zur Ticketapp weitergeleitet. Dort muss er nur auf "Jetzt kaufen" tippen und bevorzugt mit Apple Pay bzw. Google Pay bezahlen.

Ganz wichtig: das Ticket ist nach dem Kauf zunächst inaktiv, quasi nicht entwertet. Man würde einen ausgegrauten Aztec-Code mit Angabe der Start- und Zielhaltestelle sehen. Es handelt sich um einen Kauf auf Vorrat, den der Nutzer jederzeit wieder stornieren kann. Im Unterschied zum hektischen alternativlosen Kauf eines Handytickets zum sofortigen Fahrtantritt kann der Nutzer das Ticket auch bequem im voraus kaufen, wenn man dafür Zeit und WLAN hat. Es muss möglich sein, mehrere Tickets auf Vorrat zu kaufen.

An der Haltestelle, also erst dann, wenn der Nutzer sich vergewissert hat, dass die Betriebslage es ihm möglich macht, wie gewünscht zu fahren, wird das Ticket durch einen Wisch aktiviert, d.h. entwertet. Dadurch wird der Aztec-Code normal angezeigt, es läuft der Zeitzähler usw. Der Zeitpunkt der Entwertung wird lokal gespeichert. Das Ticket kann nicht mehr storniert werden. Auschecken o.Ä. ist nicht erforderlich, die Gültigkeit endet automatisch an der gewählten Zielhaltestelle.

Wenn der Nutzer spontan über die ursprünglich gewählte Zielhaltestelle hinaus fahren will, kann er ein Ticket kaufen, wo diese Haltestelle als Start angegeben ist, und es gleich entwerten. (Wenn zwischen zwei Entwertungen weniger als 180 Minuten liegen, wird der zweite Grundpreis später im Backend verrechnet, s.u.)

Wenn der Nutzer es möchte, kann er jederzeit online gehen und die gekauften Tickets, entwertet und untentwertet, mit dem Backend manuell synchronisieren ("sichern"), um z.B. beim leeren Akku und Vorhandensein eines zweiten Geräts die Tickets dort weiter zu nutzen.

Da das Frontend grundsätzlich im Offline-Modus läuft, kann es keine sofortige Berücksichtigung der Tageskappung o.Ä. geben. Innerhalb eines Betriebstages wird jede gefahrene Strecke deshalb zunächst separat geticketet, d.h. voll bezahlt. Wenn das Gerät online geht (das kann auch mal mehrere Tage nach der Nutzung sein), synchronisiert sich die Ticketapp mit dem Backend: es werden alle entwerteten Tickets aller abgeschlossenen Betriebstage, die noch nicht verarbeitetet sind, auf den Server hochgeladen. Mit diesen Datensätzen wird dann die entfernungsabhängige Tageskappung à la London geprüft. Nachbelastung kommt nicht vor, etwaige Überzahlung wird erstattet. Wenn Anschlussfahrten festgestellt werden (Ziel der Fahrt 1 = Start der Fahrt 2 und Entwertung innerhalb von 180 Minuten), wird der zweite Grundpreis erstattet. Und so weiter, je nachdem wie man den Tarif ausgestaltet.

Ein existierendes System mit allen diesen Funktionalitäten habe ich noch nicht gesehen, v.a. kenne ich kein ÖPNV-System, das wie die Taxidienste in die bekannten Kartenapps integriert ist. Der Kauf auf Vorrat mit späterer Aktivierung ist in vielen eTicketing-Systemen in Großbritannien umgesetzt. Ansatzweise gibt es das auch in Den Haag. Eine halbherzige Lösung gibt es in Berlin: bei der BVG lässt sich ein 4-er-Handyticket kaufen, wovon der erste Abschnitt zum sofortigen Fahrtantritt ist und die anderen drei später entwertet werden können. Das Musterbeispiel eines ausgeklügelten Backends ist TfL/London oder das Bizkaia-Konsortium.

Hat wer noch Ideen?
Antworten