Hvordan skaber man mersalg på 1. milliard kr.?

Du har måske læst artiklen “E-handelsekspert øger netsalg med en milliard” i Børsen d. 14.02.2012. Da denne overskrift kan lyde ganske imponerende, tager jeg dig med bagom scenen og forklarer lidt mere om, hvad det reelt kræver, at skabe mersalg i denne størrelsesorden. Dette håber jeg, kan inspirere dig i din hverdag, til at optimere din Netbutik.

1. Jeg beregner den økonomiske værdi
Inden jeg indgår et evt. samarbejde med en ny kunde, beregner jeg den potentielle økonomiske gevinst projektet kan skabe. Det gør jeg, da kunden skal kunne tjene investeringen i mig og teknologien hjem mange gange.

Jeg opstiller derfor 3 scenarier: 1) hvis det går over forventet, 2) hvis det går som forventet – et mål jeg er villig til at gøre min løn afhængig af og 3) hvis det går værre end forventet. Projektet skal være rentabelt selvom det går værre end forventet, da jeg hermed er helt sikker på at kunne indfri min kundes kommercielle
forventninger.


Læs artikel

 

 

2. Jeg beskriver kunderne
I en best-case proces, går jeg hernæst i gang med at beskrive virksomhedens repræsentative kunder, også kaldet kundearketyper, eller personas. For at kunne bygge succesfulde e-handelsløsninger, er det bydende nødvendigt, at man kender sine kunders præcise ønsker, krav og behov, i det øjeblik de lander på din hjemmeside.

3. Jeg afklarer teknologien
Med udgangspunkt i den løsning der skal bygges, sætter jeg mig ind i, om den tekniske platform, database, mv. kan understøtte de funktioner der skal til at skabe en kommercielt succesfuld løsning. Dette gør jeg for at sikre, at teknologileverandøren har kompetence til at løfte opgaven. Derfor er det godt at få fastslået fra start, om de kan stå distancen eller ej, da der oftes er tale om en større teknologisk investering.

4. Jeg prototyper løsningen
Hernæst går jeg i gang med at bygge en prototype, der visualiserer alle hjemmesidens funktioner, flows, mv. Som en af de få her i Europa, bygger jeg “high fidelity” prototyper (læs mere om de forskellige typer af detaljeringsniveauer i prototyper). Sagt på almindeligt dansk, så bygger jeg fra start prototyper der er meget detaljerede – de ligner nærmest design. Grunden til jeg gør dette er, at prototypen hermed kan fungere som et omdrejningspunkt for alle involverede i processen – kunden, designeren, programmøren, etc. fra start i processen.

Det betyder, at prototypen løbende kan blive afklaret rent teknisk, forretning- og SEO mæssigt, etc. inden der er kodet én eneste linje. Dette skaber en effektiv og meget positiv proces, hvor alle er involveret i projektet og der opnås derfor et “shared mind” på tværs af alle faggrupper.

Prototypen opbygges med udgangspunkt i kundearketyperne og deres realitetstro use-cases. Hvad køber de? Hvor tit? I hvor store mængder? Etc. Det betyder, at prototypen for et e-handelsprojekt kan komme til at fylde 400-600 sider. Prototypen bag SmartGuy, Girl, etc. fylder eksempelvis 550 sider. Dette kan nok lyde voldsomt for de fleste, men når først man går i gang med programmeringen af hjemmesiden, så er prototypen uundværlig for at undgå fejl og hermed for at kunne indfri de kommercielle målsætninger.

5. Jeg brugertester prototypen og designet
Som det næste brugertester jeg prototypen og flere typer af design. Brugertesten er baseret på “tænke-højt” metoden og design-testen er baseret på en række “emotional design” principper, hvor jeg tester kundernes bevidste og ubevidste designreaktioner (læs mere om dette her). På denne måde finder jeg ud af, hvor det går galt rent rent kommercielt, design- og brugervenlighedsmæssigt.

Jeg finder altid 4-6 store fejl der vil kunne ødelægge salget og ca. 20-30 mindre fejl, der vil gøre det svært at benytte hjemmesiden. Af denne grund løser jeg ikke kundeopgaver uden at brugerteste løsningen undervejs – det er simpelthen uansvarligt at lade være. (Herudover har de mange brugertests også givet mig mulighed for at skrive “Sælg mere på Nettet“, hvor alle de fejl og løsninger jeg har fundet frem til i over 100 brugertest er beskrevet i detaljer). Jeg vil derfor anbefale, at du holder dig langt væk fra folk der mener, at det ikke er nødvendigt at brugerteste din ehandelsløsning – de ved simpelthend ikke, hvad de taler om. Sorry to say.

6. Produktion af prototype, design og evt. HTML
På baggrunden af brugertesten tilretter jeg hele prototypen. Alle repræsentative sider designes og frontendprogrammeres (HTML, HTML5, Ajax, etc.).

 

 

7. Løsningen dokumenteres
Prototypen beskrives baseret på en funktionsbeskrivelse, sådan at dem der skal programmere løsningen (ofte folk i Indien, Ukraine, etc.) nemt kan tilgå den ellers forholdsvist omfattende prototype. Herudover skriver jeg også alle fejlbeskeder til hvert enkelt input felt, drop down menu, etc. på hele hjemmesiden.

8. Kvalitetssikring
Når den tekniske leverandør har programmeret løsningen (CustomerSense leverer udelukkende frontend programmering), foretager jeg en kvalitetssikring hvor jeg tilsikrer, at design og funktion er i fuld overensstemmelse med prototypen, designet, funktionsbeskrivelsen og fejlbeskederne.

9. Måling af den kommercielle effekt
Hernæst lanceres løsningen og den kommercielle effekt (konverteringsrate, ordrestørrelse og kundefastholdelsesrate) af projektet måles, når løsningen har været i markedet i en repræsentativ periode.

Det kræver en effektiv metode og knofedt
En af grundende til, at jeg har skrevet dette indlæg er bl.a., at overskriften “E-handelsekspert øger netsalg med en milliard” jo bestemt lyder rigtigt imponerende. Noget andet er dog, hvad det rent faktisk kræver, at opnå sådanne resultater. Derfor har jeg beskrevet min proces (i hovedtræk), sådan at du kan blive inspireret til, at gribe optimeringen af din egen hjemmeside an med en tilsvarende seriøsitet. I de seneste 8 år, har jeg benyttet denne metode til at hjælpe mine kunder med at meromsætte imellem 15 – 300%.

En hurtig A/B split kan være farlig
Efter at Google Website Optimizer har udviklet sig til at være et meget populært og effektivt testværktøj, oplever jeg alt for ofte at folk “lige laver en hurtig A / B split test” og så optimerer deres løsning, udelukkende på baggrund af de resultater de kommer frem til i A /B splittesten.

Dette kan ofte vise sig at være ganske farligt, da du kan risikere at teste 2 dårlige sider eller løsninger op imod hinanden, hvor den ene ret beset bare er dårlige end den anden. Jeg har – lidt hårdt sagt – læst flere blogindlæg, hvor folk præsenterer resultater fra en A / B splittest, hvor jeg i mit stille sind har rystet på hovedet over nogle af de fejlagtige konklusioner der er kommet frem. Det kan være en farlig vej at gå. Omvendt skal jeg dog understrege, at jeg synes brugen af A / B test er et fantastisk værktøj, hvis det er kombineret med en brugertest – altså en kombination af kvalitativ og kvantitativ data. På denne måde skabes et retvisende billede af, hvad der virker og ikke virker.

Derfor anbefaler jeg, at man brugertester større ændringer på sin hjemmeside (i et lukket fora) inden man i uvidenhed eksperimenterer med virkelige kunder og hermed sin omsætning. Det kan dog være ok, at A / B split teste mindre ændringer, uden først at brugerteste – men, det skal overvejes nøje. Hvis du ikke brugertester din hjemmeside og heller ikke arbejder med udgangspunkt i dine kunders ønsker, krav og behov, så gætter du dig øjensynligt frem til nogle løsninger, der kan vise sig at være helt forkerte. (Dette har jeg tidligere skrevet et indlæg om).

Grib processen rigtigt an og skab resultater
Kom i stedet for godt fra start med dit optimeringsarbejde, ved at arbejde metodisk – evt. baseret på en metode som den jeg beskriver ovenfor. Hvis du træder dine skridt korrekt, kan du opnå rigtigt gode kommercielle resultater.

Rigtig god arbejdslyst med din egen konverteringsoptimering og kommentér gerne.

Posted in e-bog, E-handel, Proces, Sælg mere på Nettet.

16 Comments

  1. Rigtig spændende at læse om dine arbejdsgange Benjamin. Jeg kan se, at jeg ikke er kommet helt skidt fra start med mine første kundesamarbejder som selvstændig konsulent, da jeg stort set gennemgår de samme faser. Dog har jeg til gode at skrive en prototyperapport på 550 sider endnu 🙂

    Hvad er forskellen på din prototyperapport og kravspecifikation?

    • Hej Mogens. Godt at høre, at du er kommet godt fra start (tillykke med det!) og at du kan bruge indlægget 🙂

      Jeg udarbejder ikke prototype-rapporter, jeg bygger konkrete (high-fidelity) prototyper, der visuelt viser hvert eneste side i de e-handelsløsninger jeg bygger. Dette er helt centralt for måden jeg arbejder på, da det gør, at jeg meget tidligt i en proces, kan blive konkret rent løsningsmæssigt og hermed brugerteste prototypen, inden den omsættes til en teknisk løsning. Når prototypen er godkendt af kunden, udarbejder jeg en funktionsbeskrivelse, der – ja, rent funktionelt – beskriver løsningen / prototypen. Denne funktionsbeskrivelse benytter mange af de udviklingshuse jeg samarbejder med så til at skrive en teknisk kravsspecifikation – besvarede det dit spørgsmål?

  2. Tak for dit svar Benjamin. Lige et kort opfølgende spørgsmål:

    Vil det sige, at når dine prototyper bliver 400-600 sider, er det 400-600 sider med design af de enkelte websider i ehandelsløsningen?

    • Det var så lidt. Der er ikke tale om design, men om en prototype – en prototype der danner grundlag for design og programmering. Læs mere om prototyper her: http://www.usability.gov/methods/design_site/prototyping.html

      …hvor jeg som nævnt bygger “high fidelity prototypes” – jeg er (mig bekendt) den eneste i DK der benytter denne metode / tilgang til prototyper: http://www.usabilityfirst.com/glossary/high-fidelity-prototype/

      De to bedste måder at lære noget om brugervenlighed på, er 1) at brugerteste og 2) at bygge prototyper – og helst i den rækkefølge, hvor du bygger en prototype som du så efterfølgende brugertester. Når man så er gået i luften med en endelig teknisk / designet løsning, kan man lære endnu mere af at A / B splitteste, hvor jeg ved, at du har godt styr på sidst-nævnte, samt brugertests.

    • Normalt går 70 – 80% af min arbejdstid på at bygge og teste prototyper – og, jeg nyder det i store drag 🙂 I år har jeg dog holdt en del foredrag, mv., så det er blevet til færre timers prototype, men det er kernen i min forretning / metode.

  3. Igen tak for hurtigt svar, som er meget interessant.

    Det er vist blot mig der ikke har helt forstand på de forskellige prototype-begreber. Jeg er dog nysgerrig og er stadig ikke 100% med. Der står usability.gov siden, at high-fidelity prototyping er “a fully functioning Web site”. Laver du simpelthen et fuldt funktionsdygtigt website, der så danner grundlag for design og programmering?

    • Nej, jeg bygger fuldt ud detaljerede prototyper, men de er ikke programmerede (de behøver ikke være funktionsdygtige for at høre ind under “high fidelity” begrebet, hvilket primært henviser til prototypens detaljeringsniveau) – der er tale om “flade” (ikke-funktionelle) sider, der dog indeholder alle detaljer omkring menu, indhold, tekst, knapper, links, etc.

  4. Okay, så du laver ikke-designede skitser, hvor du har forsøgt at tænke så meget ind som muligt vedr. menuer, tekster, links, knapper osv.?

    Laver du disse skitser i hånden eller bruger du et værktøj som f.eks. Balsamiq?

    • Hej Mogens – ja, det kan man godt sige. Jeg laver ikke skitser i hånden, da jeg benytter prototypen som et (oftest internationalt) projektstyringsværktøj, hvor håndskitser er for uklare og hermed ikke kommunikérbare på tværs af faggrupper og landegrænser.

      Jeg benytter ikke prototypeværktøjer (såsom Balsamiq), da jeg ikke ønsker at bygge noget funktionel logik ind i mine prototyper. Det bliver hurtigt en konstrueret virkelighed, samt for besværligt / tungt at arbejde med og i.

      • Tak igen for svar.

        Jeg beklager min uvidenhed 🙂 Hvis du laver visuelle prototyper, men de ikke er lavet hverken i hånden, i et skitseprogram som Balsamiq, eller designet f.eks. i Photoshop – hvordan laver du så disse prototyper?

        • Jamen, du har da intet at beklage – det er et rigtig godt spørgsmål 🙂 Oftes benytter jeg PowerPoint til at bygge mine prototyper, da 1) alle mine kunder har dette program installeret på deres computer, 2) jeg hurtigt kan arbejde detaljeret i det og da 3) jeg nemt kan benytte programmet til at brugerteste og tilrette prototyperne – et setup jeg i øvrigt også for nyligt har benytte til test af en mobil shop. Det fungerer upåklageligt.

          Problemet med prototypeværktøjer er, at de 1) er for standardiserede, 2) forsøger at opbygge en logik i flows, mv. der hurtigt kan ende i funktionelle blindgyder, når man brugertester, 3) ikke er systemer mine kunder er vant til, 4) ikke kan håndtere mit detaljeringsniveau og 5) er for langsomme at arbejde i, i.f.t. high-fidelity prototyping.

          Keep it simpel, yet fast and detailed 🙂

          • Hej Benjamin

            Så er jeg endelig med. Mange tak.

            Igen rigtig fedt at få lidt indblik i dine arbejdsmetoder og værktøjer.

          • Hej Mogens. Det var så lidt 🙂

            Held og lykke med den videre færd, det ser spændende ud, det du laver.

            NB: jeg påtænker at lave et “CustomerSense Academy”, hvor man kan blive undervist i min metode, bog + øvrige erfaringer indenfor e-handel.

            Mvh, Benjamin

    • Hej Tim. Mange tak!

      Størrelsen af mine kunder er (jf. punkt nr. 1 i mit indlæg) 100% styret af, hvor meget jeg kan hjælpe en potentiel kunde med at meromsætte. Hvis de har en meget lille omsætning, kan de nok ikke tjene investeringen i mig hjem mange gange – i sådanne tilfælde takker jeg nej til at løse en opgave, da mine kunder skal tjene penge på at involvere mig i deres virksomhed.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *