Prijsweergave verbeteren door duidelijkheid

Een ruw schema van de interacties die een reiziger met een prijs kan hebben en wat er uit elk daarvan volgt. Het is geen volledige weergave van elke staat waarin de funnel kan verkeren, en dat zou het ook nooit worden. Wat het oplevert zijn de edge cases die je vooraf kunt zien in plaats van die een developer in een sprint vindt, en een gedeeld object om naar te wijzen wanneer iemand vraagt of we aan een heel specifiek edge case hebben gedacht.

Het begon als één vraag met een complex antwoord: wat nemen andere platforms op in de nachtprijs?

Die eerlijk beantwoorden betekende beslissen met wie je vergelijkt, waar, en onder welke boeking. Dus: Findhotel tegen Expedia, Booking, Agoda, Skyscanner, TripAdvisor, Airbnb en Kayak, want dat zijn de partijen waaraan het bedrijf zich al spiegelde. In Nederland, Duitsland, het Verenigd Koninkrijk, Australië, Belarus, Indonesië en Israël, want dat zijn de markten waar onze eigen regels voor prijsweergave al verschilden.

Vergelijkbare resultaten hebben een controle nodig, dus elke zoekopdracht was dezelfde zoekopdracht: Park Plaza Victoria in Amsterdam, één volwassene, één kamer, voor de nacht van 13 oktober 2020, een hotel dat juist is gekozen omdat er zowel toeristenbelasting als een toeristenheffing op zit. De zoekopdrachten zelf zijn in september uitgevoerd, een maand vooruit, ongeveer wanneer iemand een stedentrip boekt. Een tweede ronde vroeg om twee nachten, 13 tot 15 oktober, in de vijf markten waar de eerste ronde een vraag had opgeroepen. Waar een platform dat hotel niet had, is het dichtstbijzijnde equivalent gebruikt en is de vervanging genoteerd.

Ik leidde de ideatiesessies, en de benchmark is wat ze de moeite waard maakte. Een team meenemen langs wat acht concurrenten met dezelfde boeking doen is een snellere manier om vast te stellen wat mogelijk is dan welke mening ook. Het verschuift het gesprek van meningen over prijs naar waarnemingen over prijzen.

Na elke sessie volgde de scoping, met de product owner en de data scientist. Twee vragen, altijd in deze volgorde: "Hoe zou het juiste antwoord eruitzien als niets de ontwikkeling in de weg stond?", en "Wat is het kleinste stuk dat we konden ontwikkelen om in echt verkeer te zetten?". Het gat tussen die twee antwoorden vormde de roadmap.

De wireframes werden een klikbaar prototype, bewust ruw gehouden. Het publiek waren stakeholders en iedereen in het bedrijf met een belang bij de uitkomst, en een scherm dat er af uitziet nodigt uit tot een gesprek over hoe af het eruitziet. Een grijs scherm nodigt uit tot een gesprek over de prijs.

Daarna guerrillatesten, wat hier betekent: pakken wie beschikbaar is en kijken hoe ze het proberen. Het vervangt geen studie en het is ook nooit als zodanig gepresenteerd. Het vangt het voor de hand liggende, en het levert de vragen op die als echt onderzoek terugkomen bij het team: wat gebeurt er als de valuta van de reiziger niet de valuta van de aanbieder is, wat gebeurt er bij meerdere kamers, wat gebeurt er als de kostenpost groter is dan de kamer.