Thomann Versandoptionen Hero

Autor-Facts

NameJulian
PositionProjektmanager
6. September 2020

Gitarren nach Oslo oder: Die Kunst, die richtige Versandoption anzubieten

Als internationaler Musikversand hat Thomann Kunden in der ganzen Welt. Wer möchte, kann eine Gitarre nach Oslo bestellen, eine Trommel nach Brisbane oder ein Klavier nach Genf. Doch bei der Bestellung muss unser System eine ganze Reihe von Herausforderungen meistern: Zum Beispiel muss es die richtige Paketgröße zuweisen, Adressangaben vereinheitlichen oder prüfen, ob eine Expresszustellung möglich ist. Kurz gesagt: Unsere Kunden müssen für jede Bestellung den passenden Versanddienstleister wählen können. Dafür haben wir unser System dieses Jahr sorgfältig optimiert. Unser Full Stack Developer Francesco Schrüffer (27) berichtet aus der Praxis.

Angenommen, ein Kunde will bei Thomann eine Gitarre bestellen. Er hat dafür verschiedene Möglichkeiten: Er kann die Website nutzen, die mobile Seite oder die App. Dort sucht er nach dem passenden Modell, legt es in den digitalen Einkaufskorb, gibt Zahlungsmodalität und Postanschrift ein – und bestellt. Alles ganz einfach, könnte man meinen. Und tatsächlich ist der Bestellvorgang für Thomann-Kunden auch äußerst komfortabel. Doch damit alles reibungslos läuft, müssen hinter den Kulissen viele Rädchen ineinandergreifen – besonders dann, wenn der Besteller im Ausland sitzt. Wenn die Gitarre nach Oslo oder das Keyboard nach London geht, verkompliziert das den Bestellvorgang – nämlich deshalb, weil in jedem Land andere Zustellbedingungen herrschen. Unser Ziel ist, unseren Kunden – ganz egal, wo sie leben – die maximal mögliche Auswahl an Versandoptionen zu bieten. Sie sollen wählen können, welches Unternehmen die Zustellung übernehmen soll (Fachbegriff: "Frachtführer"). Und sie sollen schon bei der Auswahl sehen können, was die Zustellung kostet, wie lange sie dauert und wie das Produkt transportiert wird. In Echtzeit, wohlgemerkt.

Kräftig am System geschraubt

Um das zu gewährleisten, mussten wir kräftig an unserem System schrauben. Früher gab es bei der Bestellung nämlich keine Auswahlmöglichkeiten. Die Kunden sahen zwar die voraussichtlichen Versandkosten. Sie erhielten aber keine Info darüber, welcher Frachtführer ihr Paket transportierte – ob nun DHL, UPS, Swiss Post oder ein anderes Unternehmen. Die Kunden nutzten häufig die Kommentarfunktion, um uns ihren "Wunsch-Frachtführer" mitzuteilen. Wir mussten den Frachtführerwunsch anschließend händisch ins System eintragen – was natürlich sehr umständlich war. Mit unserem neuen System wollten wir dieses ständige Hin und Her zwischen Kunde und Hotline vermeiden – der Bestellvorgang sollte reibungsloser funktionieren. Wir entwickelten ein neues System – und testeten es dann im Live-Betrieb.

Zunächst aber galt es, die größten "Baustellen" zu bestimmen. Eine davon war der Umgang mit Adresseingaben. Manchmal geben Kunden ihre Versandadressen so ein, dass weder wir noch die Frachtführer etwas damit anfangen können. Diese Kunden können ihre Lieferkosten dann nicht aktuell berechnen lassen, was natürlich schade ist. Denn wenn wir oder der Frachtführer keine Frachtkosten bestimmen können, dann können wir den Versand nicht anbieten. Es ist ja so, dass die Kunden nicht nachträglich mit höheren Frachtkosten konfrontiert werden sollen. Wir bieten die Versandoption deshalb nur an, wenn wir hundertprozentig sicher sind, dass es so funktioniert.

Besonders der Versand in andere Länder kann knifflig werden. Denn jedes Land hat andere Bedingungen – zum einen bestimmte Frachtführer, zum anderen häufig ein eigenes Adressformat. Die Frachtführer brauchen für die ordnungsgemäße Zustellung genau dieses Adressformat. Fehlen bestimmte Parameter, dann kann das Zustellunternehmen den Auftrag nicht übernehmen, weil die Adresse nicht "frachtführerkonform" ist. UPS Express beispielsweise will eine vollständige Adressangabe – mit Straße, Ort, Postleitzahl und so weiter. Allerdings wissen wir, dass die Adressangabe der Kunden – bei bestimmten Ländern – häufig ganz bestimmte Fehler enthält. Saudi-Arabien zum Beispiel hat ein ganz besonderes Postsystem. Das Adressformat ist folgendermaßen aufgebaut: Teil 1 – Bindestrich – Teil 2. Wenn der Kunde bei der Adresse den Bindestrich weglässt, dann akzeptiert UPS Express das nicht. Und dann können wir diese Option auch nicht anbieten. Der Kunde gibt da eine scheinbar richtige Adresse ein, erhält aber nicht die entsprechende Option – und versteht auch nicht, warum das so ist. Bei bestimmten, häufig auftretenden Formatfehlern können wir etwas nachhelfen, indem wir die Adresse nachträglich formatieren. Aber das klappt nicht immer. Das war die erste Herausforderung.

Express- und Speditionsversand als "Baustellen"

Die zweite Herausforderung war, den Speditionsversand zu optimieren. Wir haben einige sehr große Artikel, die per Spedition geliefert werden, zum Beispiel Klaviere oder Harfen. Wir haben einen Pool von Speditionsfirmen, die für uns arbeiten. Vor dem Versand wissen wir nicht, mit welcher Spedition der Artikel schließlich verschickt wird. Welche Spedition zum Zuge kommt, ist von vielen Faktoren abhängig – letztendlich entscheidet das die Versandleitstelle. Weil wir das nicht vorab wussten, konnten wir im Kunden-Interface nie eine Speditionsoption anzeigen. Stattdessen zeigten wir die Standardversandkosten an – und einen kleinen Hinweis, dass die Bestellung per Spedition verschickt wird. Kunden sollten für Rückfragen ihre Telefonnummer angeben. Das hat aber nicht so gut geklappt. Die dritte Herausforderung war, den Expressversand zu verbessern. Grundsätzlich macht es ja nur Sinn, die Option "Expressversand" anzubieten, wenn das betreffende Produkt auch tatsächlich bereits verfügbar ist – und nicht, wenn es erst in drei Tagen bei uns eintrifft. Wir mussten die Verfügbarkeit also schon beim Bestellprozess prüfen können.

Ganz allgemein wollten wir unsere Kommunikation gegenüber den Kunden verbessern. Wenn eine Bestelloption gerade nicht verfügbar war, sollte das für die Kunden möglichst transparent sein. Das System sollte dann die Fehlermeldung anzeigen, die uns der jeweilige Frachtführer zur Verfügung gestellt hatte. Tendenziell wollten wir aber vermeiden, dass die Kunden überhaupt Fehlermeldungen erhalten. Das setzt natürlich voraus, dass das System frühzeitig erkennt, wenn zum Beispiel eine Lieferung in ein bestimmtes Land nicht möglich ist. Das System sollte dann korrigierend eingreifen.

Kurz gesagt: Es gab jede Menge zu tun. Im September 2019 begannen wir mit den Vorarbeiten für den Systemumbau. Eine wichtige Grundlage unseres Versandgeschäfts ist, für Thomann-Produkte die optimalen Paketgrößen zu finden. Das Sortiment ist ja nicht nur riesig, sondern auch hochgradig ausdifferenziert: Es reicht vom Plektrum über die Fender-Gitarre bis zum Konzertflügel. Allerdings können wir einem Versandführer wie UPS nicht einfach sagen, dass wir eine Fender-Gitarre verschicken: Wir müssen ihm mitteilen, welche Größe das jeweilige Paket hat. Die erste große Aufgabe war also, unseren Versand "nachzubauen". Um durchschnittliche Paketgrößen für bestimmte Produktkategorien zu bestimmen, schauten wir uns die historischen Versanddaten von Thomann an – sie reichen bis Anfang 2004 zurück. Auf Basis dieser Daten können wir nun sagen, welches Produkt höchstwahrscheinlich in welchem Paket landet. Es geht jedoch nicht darum, mathematisch perfekt zu packen – sondern realistisch, also mit Spielraum. Ziel ist ja, dass weder wir noch der Kunde draufzahlen müssen, weil das Paket zu knapp kalkuliert war.

30 verschiedene Kartongrößen

Bei Thomann gibt es 30 verschiedene Kartongrößen – vom kleinen Kuvert bis zum riesigen Paket. Die Versandhistorie lieferte uns interessante Erkenntnisse. Wir stellten fest: Das Paket, das am häufigsten zum Einsatz kommt, ist 100 Zentimeter breit, 100 Zentimeter hoch und 28 Zentimeter tief. Auf Platz 2 landete ein Paket mit minimal kleinerem Volumen – und den Maßen 140 cm * 44 cm * 44 cm. Als wir sämtliche Daten beisammen hatten, integrierten wir sie ins System – und begannen mit dem Testing.

Wir wählten ein typisches Verfahren, den A/B-Test, auch "split test" genannt. Grundsätzlich geht es beim A/B-Test darum, zwei Varianten einer Website oder App gegeneinander zu testen – um dann entscheiden zu können, welche bei den Nutzern besser ankommt. Messen lässt sich diese Akzeptanz zum Beispiel in der "conversion rate" – in unserem Fall ist das zum Beispiel der Anteil der User, bei denen es auch tatsächlich zu einem Kaufabschluss kommt. Unser A/B-Test lief von Anfang Oktober 2019 bis Mitte Februar 2020. In diesem Zeitraum gab es insgesamt drei Test-Iterationen, in denen wir das neue Feature – also die erweiterten Bestelloptionen – unter die Lupe nahmen. Die Grundfrage war: Wird das Feature akzeptiert und als eine Bereicherung empfunden – oder verwirrt es die Kunden und führt zu Kaufabbrüchen? Ganz konkret wollten wir Folgendes wissen: Wie interagieren User mit der neuen Version? Interagieren sie überhaupt damit? Und wie wie wirkt sich das auf die Conversions aus?

Drei Iterationen

Die erste Test-Iteration fand im Oktober 2019 statt. Für den A/B-Test hatten wir vier Länder ausgewählt: die USA, Frankreich, Schweden und Finnland. 10 Prozent aller Kunden dieser Länder bekamen in unserem Online-Shop die Variante mit dem neuen Feature zu sehen. Das Formular mit der Versanddienstleister-Auswahl war also standardmäßig in den Bestellvorgang integriert. In dieser ersten Iteration wollten wir vor allem herausfinden, wie das Feature ankommt. Dafür maßen wir die Veränderungen bei den verschiedensten Conversions – also zum Beispiel die Kaufabschlussrate und die Interaktion mit dem Widget für die Versanddienstleister-Auswahl. Das Ganze war so etwas wie eine erste Testphase für den Normalbetrieb. Das Widget mit dem neuen Feature haben wir übrigens mit React programmiert – einer JavaScript-Software-Bibliothek.

Die zweite Test-Iteration lief dann von Oktober bis Dezember – und zwar ebenfalls bei 10 Prozent der Kunden der vier oben genannten Länder. Nun war das neue Feature aber sowohl in Variante A als auch in Variante B vorhanden. Der Unterschied: Bei A war das Widget mit dem neuen Feature eingeklappt, bei B hingegen ausgeklappt – also deutlich besser sichtbar. Die beiden Varianten waren zudem gleichmäßig verteilt. In dieser Iteration sammelten wir Feedback von Kunden und aus verschiedenen Thomann-Abteilungen. Unter anderem ging es darum, wie genau die Logos der DHL-Partner angezeigt werden sollen, wie das User Interface aussehen soll und ob wir das UPS-Express-Angebot auf weitere Länder ausweiten können. Nach jeder Änderung maßen wir eine Reihe von Conversions: Die Interaktion mit dem Widget, die Bestellungen mit geändertem Versanddienstleister und natürlich auch den Kaufabschluss. Das alles wie gesagt für die zwei Testgruppen mit eingeklapptem und ausgeklapptem Widget.

In der dritten Test-Iteration (Dezember bis Februar) kamen dann noch einige Länder hinzu, nämlich Mexiko, Hong Kong, Australien sowie die Vereinigten Arabischen Emirate. Das neue Feature spielten wir nun bei 100 Prozent aller Shop-Besucher aus – auch wieder mit der Eingeklappt-/Ausgeklappt-Variation. In dieser letzten Iteration sammelten wir ebenfalls eifrig Feedback, um verschiedene Dinge nachtunen zu können. Das waren unter anderem der Rabatt auf UPS Express, aussagekräftigere Fehlermeldungen, genauere Versandlaufzeiten sowie eine einheitlichere Kommunikation im gesamten Shop. Auch hier maßen wir wieder die Interaktion mit dem Widget, die Bestellungen mit geändertem Versanddienstleister und die Konversionsrate beim Kauf.

Fein-Tuning führt zum Erfolg

Über den gesamten Testzeitraum konnten wir sehr genau verfolgen, wie sich die Conversion Rate ändert. In der ersten Iteration stellten wir beispielsweise fest, dass die Conversions zurückgingen – also verbesserten wir das Feature schrittweise, bis die Konversionskurve nach oben ging. Seit März ist das neue System für die ganze Welt online – und auf allen Plattformen.

Natürlich tauchen immer wieder neue Herausforderungen auf. In der Corona-Krise beispielsweise konnten wir unsere Produkte vorübergehend nur noch mit ganz bestimmten Frachtführern nach Frankreich verschicken. Das ins System einzubauen, ist vergleichsweise unkompliziert: Unser Versand-Team steht in ständigem Kontakt mit allen Frachtführern – und kann über unser internes Tool bestimmte Parameter (Laufzeit, Preis, Frachführer) in Minutenschnelle im System ändern. Tatsächlich ist auch die Preisbestimmung in Corona-Zeiten eine besondere Herausforderung. Normalerweise haben wir Pauschalpreise auf Frachtführerbasis – das heißt, wir wissen, was zum Beispiel eine UPS-Standardlieferung nach Israel kostet. Durch Corona sind diese Standardversandarten aber weggefallen. Momentan können wir in bestimmte Länder nur noch per Express verschicken. Um so wichtiger ist, dass wir das gegenüber unseren Kunden kommunizieren. Auch hier hilft uns das neue System.

Fazit: Ein Bestellsystem sollte reibungslos laufen – und es sollte möglichst flexible Versandoptionen bieten. Beides haben wir in unserem Projekt gut umsetzen können. Was nicht heißt, dass damit alles getan wäre: Wir werden unser Bestellsystem auch weiterhin genau beobachten und verbessern.

Das Team

Viele Thomann-Abteilungen haben zum Gelingen des Projekts beigetragen, darunter die interne IT, das Hotline-Team, die Logistik und der Export. Zum Webteam-Team gehören die Full Stack Developer Francesco Schrüffer, Fabian Hesse, Sebastian Reuther und Heiko Terfloth, Projektmanagerin Julia Manger und Agile Coach Dominic Burucker.

thomann.io v2

thomann.io v2

Frisch aus dem Kühlregal: Hier ist das neue Frontend!
Thomann Dev Camp 2k19

Thomann Dev Camp 2k19

Dieses Jahr meldet sich das Dev Camp unter dem Motto “gemeinsam abgehoben sein”
Das Thomann Dev Camp

Das Thomann Dev Camp

Wir wissen, was das Dev Team letzten Sommer gemacht hat. Ein Einblick.
Das Slack-Battle

Das Slack-Battle

Der Umzug des Thomann-Teams von Skype auf Slack hat einige Neuerungen mit sich gebracht. Für alle,...
Praktikum bei Thomann in Berlin 2.0 – Web-Tests

Praktikum bei Thomann in Berlin 2.0 – Web-Tests

Das umfangreiche Testing-Framework von m.thomann.de ermöglicht es, Änderungen an der Website...