Det usynlige fald i checkout-flowet.

Tag et typisk funnel for en dansk webshop: 1.000 lægger en vare i kurven, 600 begynder på checkout, 380 når frem til betalingen, 280 gennemfører. Det sidste fald, de 100 ordrer mellem betalingsvalget og den bekræftede ordre, bliver sjældent undersøgt. Det bliver henført til “kunder, der ikke var klar alligevel”.

Det er en forkert konklusion. De 100 kunder ville købe. De havde valgt vare, accepteret prisen og var nået til det sted, hvor betalingen skal ske. At de ikke kom i mål, handler næsten altid om, hvad flowet gjorde ved dem i de sidste 30 sekunder.

Felter, der spørger før de har brug for svaret

Firmanavn, kundenummer, telefonnummer, ønsket leveringsdato. Feltet bliver vist, fordi en skabelon har plads til det, ikke fordi ordren kræver det. Hvert felt uden en funktion er en ekstra beslutning for kunden og et ekstra sted, et flow kan strande.

Valg, der ikke kan fortrydes

Det tvungne login er den klassiske. Kunden skal oprette en konto for at købe én vare, og skal samtidig finde på et password, der opfylder fem krav og ikke er genbrugt. Set fra kundens side er spørgsmålet: hvad får jeg ud af det her, lige nu, 30 sekunder før jeg betaler?

Fragt, moms og valuta, der først vises sent

Når den endelige pris først står klart ved betalingen, føles den som en overraskelse, også når den er korrekt. Det er den dyreste form for transparens: den, der kommer efter tilliden er bygget op.

Fejlbeskeder i maskinsprog

“Fejl 422: payment_intent_invalid” siger intet til et menneske, der står med et kort i hånden. En fejlbesked skal fortælle, hvad der gik galt, hvad kunden skal gøre, og at ordren stadig er intakt.

Gennem hele købsrejsen har kunden givet dig noget: opmærksomhed, klik, oplysninger. Ved betalingen sker byttet, nu skal de give penge, og tilliden er på sit højeste krav. Det er her, garantier, returret, betalingsikoner og en synlig kundeservice gør en målbar forskel. Ikke som pynt, men som svar på de spørgsmål, de stiller sig selv i samme sekund, de skal trykke på knappen.

Standardflows placerer ofte disse signaler i footeren eller på en underside. Det er logisk for den, der byggede sitet. Ulogisk for den, der står i det øjeblik, hvor beslutningen skal tages.

Når man bygger en checkout fra bunden, er den rigtige model en tilstandsmaskine: hvert trin har en defineret tilstand, hvert skridt frem og tilbage bevarer data, og hver overgang er et event, der kan måles. Det er også det, der gør det muligt at optimere. Uden events pr. trin ved man ikke, hvilket felt der dræber ordren.

Hvad der bør måles pr. trin

• Tid brugt pr. felt, og hvilke felter der bliver rettet i.
• Fejlrate pr. validering, ikke kun pr. ordre.
• Genoptagelsesrate: hvor mange vender tilbage efter en afbrudt betaling?
• Fald pr. betalingsmetode, enhed og geografi, de skjuler sig i gennemsnittet.

Teknisk betyder det server-side validering i realtid frem for validering ved submit, fragtberegning der kører asynkront uden at blokere feltet, betalingsmetoder der initieres, før kunden når bunden, og en betalingsknap, der aldrig efterlader kunden i tvivl om, hvad der sker, når den trykkes på.

Arbejdet starter med at optage og opdele det eksisterende flow, ikke med at vælge et nyt tema. Derefter fjernes felter uden funktion, tilstand gøres vedvarende, fejl oversættes til menneskesprog, og de spørgsmål, kunden stiller sig selv ved betalingen, fragt, returret, sikkerhed, besvares direkte i flowet. Først derefter bygges komponenterne, som regel som custom moduler oven på platformens betalings-API i stedet for som endnu et checkout-plugin.

Det er ikke et nyt tema, der redder de sidste 30 sekunder. Det er et flow, der er bygget til at færdiggøre det, kunden kom for.