Den här olyckligtvis sanna historien utspelade sig under hösten 2023 när jag skulle köpa flygbiljett från bortre Asien tillbaka till Sverige.
Att köpa en flygbiljett låter kanske som en enkel sak, men sanningen är den att flygbiljettsbranschen består av massvis med olika aktörer: nationella myndigheter, internationella organisationer, flygbolag, resebolag, aggregatorer, försäkringsbolag, betalbolag och många, många andra nischade aktörer. Fram till början av 2020 fanns det exempelvis ett svenskt bolag vars hela affärsidé gick ut på att å flygresenärers vägnar driva processer mot flygbolag för att få dem att betala förseningsavgifter. Och det är inte ens den mest udda nischen av denna spretiga bransch.
Hursomhelst så använde jag en så kallad aggregator-sida (en sida som samlar och presenterar erbjudanden om flygbiljetter från många olika källor) för att hitta bästa erbjudandet från den uppsjö av flygbolag och resebolag som trafikerar den aktuella rutten. Jag hittade en biljett från ett bolag som av legala skäl kommer att gå under namnet “resebolag A”. Resebolag A är en så kallad etablerad aktör med lång historia. Detta är dock inte nödvändigtvis en bra sak.
Jag påbörjade orderflödet på resebolagets webbsida, tackade nej till en lång rad erbjudanden (först som paket, sen som enskilda val), fick tom JS-popups med frågan “är du verkligen säker på att du inte vill ha [dyr försäkring av tvivelaktigt värde]?” och kom slutligen fram till betalsidan.
På betalsidan gjorde jag en banköverföring som lyckades och blev sedan omdirigerad tillbaka till resebolaget. Där möttes jag, inklämt i en liten iframe(!), av felmeddelandet: “Något gick fel.”
Jag tänkte att “det var säkert inget viktigt fel, betalbolaget visade ju att betalningen lyckades.” Jag tittade i min inkorg och såg ett mejl med titeln “Resebolag A: Tack för din betalning!” följt av ett mejl med titeln “Resebolag A: Er reseförfrågan – Annullering”. Det första mejlet sade sammanfattningsvis: “Allt gick bra, här är ditt kvitto, biljetten kommer strax”, medan det andra mejlet i stora drag sade: “Du, förresten, vi skojade bara. Det blir ingen biljett, men vi har redan dragit pengar från ditt konto. Ta det lugnt, pengarna kommer (antagligen) tillbaka om några dagar.”
Nu anade jag oråd och loggade in i min bank för att titta på balansräkningen, vilket bekräftade mina rädslor: pengarna var borta. Nu gick jag i taket på riktigt. Det var dags att ringa till kundtjänst och lämna in ett formellt klagomål under lugna och sansade former.
Konversationen med kundtjänst gick ungefär såhär:
Jag: “Hej! Jag undrar vad statusen på min order med ordernummer XXXXX är?”
Kundtjänst: “Jag ser att något gick fel och den är annullerad.”
Jag: “Okej, och vad var det som gick fel?”
Kundtjänst: “Det vet jag inte. Det finns så många aktörer inblandade här. Men jag ser att du kom från reseaggregatorn X, så nästa gång kan du använda reseaggregatorn Y istället.”
Jag: “Jaså, funkar Y bättre?”
Kundtjänst: “Det vet jag inte.”
Jag: “…”
Vid det här laget insåg jag att supporten hos resebolag A behövde mer support än mig, så jag gav upp och slängde på luren. Mina pengar var i ett fin-tekniskt limbo, men jag kunde skrapa ihop till en ny biljett genom att flytta runt pengar bland olika sparkonton och delade konton.
Jag behövde fortfarande en flygbiljett och eftersom direktflyg är eftertraktade och stolsplaceringen visade att det bara fanns ett tiotal platser kvar på planet så behövde jag agera snabbt. Resebolag A skulle dock aldrig någonsin få pengar av mig igen, så jag tittade på listan över erbjudanden i aggregatorn och valde ett mindre resebolag som av legala skäl kommer att kallas “resebolag B”. Detta resebolag hade inte lika många recensioner som resebolag A, men hade ett högre betyg.
Jag gick in i deras orderflöde och märkte att de var betydligt mer rakt på sak: inga extra tjänster, inga smaskiga erbjudanden om försäkringar, inga popups med “är du verkligen säker på att…?”. Försiktigt pessimistisk så fortsatte jag orderflödet fram till betalningssteget. Där kom den stora överraskningen.
“Din biljett är nu bokad! Följ länken nedan för att göra din betalning. Om betalningen inte inkommit innan kl 22 inatt kommer biljetten avbokas.”
I ett tillstånd av mild chock gick jag igenom betalningsflödet som även det lyckades. Jag tittade sedan i min inkorg och såg två mejl: det första som bekräftade min bokning men noterade att betalningen inte gjorts ännu (och bifogade en länk till betalsidan) samt ett mejl som bekräftade att betalningen inkommit. En dryg timme senare kom även min elektroniska biljett.
Lärdomar från min historia
Om vi nu tittar tillbaka på denna historia ur ett systemutvecklingsperspektiv, vad kan vi då lära oss?
1. Bygg inte ditt orderflöde som en enda transaktion.
Det är inte rimligt att ett orderflöde ska vara strukturerat som ett korthus, där en enda felande länk får hela alltet att kollapsa, vilket var fallet med resebolag A. Resebolag B, däremot, hade identifierat att ordern kunde hanteras i två steg (bokning och betalning), vilket gav en mer felsäker process ur teknisk synpunkt och dessutom en bättre kundupplevelse. Om du gör bokningar och betalningar ömtåliga så ökar risken att kunderna blir upprörda, och i en så pass konkurrensutsatt bransch som resebranschen så är risken mycket hög att de väljer en annan aktör.
2. Håll koll på varför saker går fel.
Som kund finns det en förväntan att få veta varför ett köp misslyckats. Att på frågan om vad som gick fel svara “Det vet jag inte” inger knappast förtroende, vare sig för kunden eller för produkt- eller systemägaren. I alla icke-triviala system är det viktigt att ständigt samla och spara loggar, identifiera fel och arbeta för att hitta sätt att lösa felen, antingen genom att upptäcka och laga felkällan eller att fånga och hantera felen som är för svåra eller för dyra att lösa. Sneglar man på exempelvis bank- och finansbranschen, där allvarliga buggar kan leda till att Finansinspektionen är den som ställer frågan om vad som gick fel, så kan svaret “Det vet jag inte” leda till dryga böter och andra påföljder.
3. Bygg bra tester för dina viktigaste flöden.
“Det finns så många aktörer här” är en dålig ursäkt. Det här svaret ledde till många frågetecken hos mig, inte minst för att det visar en handfallenhet inför ett problem som är långt ifrån unikt, men också långt ifrån olöst, samtidigt som detta problem gäller resebolagets kärnaffär. Typiskt när man ställs inför en domän med många olika scenarier, särskilt inom systemintegration, är det viktigt att skapa en högkvalitativ automatiserad testsvit. Extra möda bör läggas på att göra det enkelt att skapa nya tester när en ny aktör tillkommer i någon del av orderflödet och göra det till en del av varje user story. Dessutom bör en testmatris skapas, som visar alla möjliga kombinationer av inputs och resultat i flödet, så att både utvecklare och produktägare kan förvissa sig om att de automatiska testerna har fullgod täckning.
Ett boktips om ämnet!
Om du i dagsläget underhåller ett system eller bygger ett nytt från grunden och vill undvika fallgroparna ovan, var är då en bra plats att börja på? Personligen kan jag rekommendera att du läser boken Release it! Design and deploy production-ready software av Michael T Nygard, en bok som går igenom många olika lösningsförslag för stabilitet, säkerhet, felhantering, monitorering, felsökning och katastrofsimuleringar med både praktiska tips och exempel från verkliga händelser.
Behöver du ytterligare hjälp så finns vi på Citerus här för att hjälpa dig lyckas med ditt projekt.
