Undskyld

Sig undskyld til kunderne, når du har lovet noget, du ikke kan levere som forventet. I videoen fra juli 2014 fortæller jeg om en beslutning i Dinero, som gjorde nogle brugere skuffede og vrede.

Sig undskyld til kunderne, når dit løfte skuffer dem

Det her var en af de hårdere videoer at lave. Dinero og jeg var havnet i en shitstorm, som vi godt havde vidst ville komme. Jeg ville både forklare, hvorfor vi var endt der, og fortælle, hvad jeg mente, man skulle gøre i sådan en situation.

Vi havde lovet noget, som ikke ville blive til det, nogle brugere havde håbet på. Derfor sluttede jeg heller ikke bare med en forklaring. Jeg sagde undskyld og mente det.

Vi havde bygget Dinero til de helt små virksomheder

Da vi begyndte på Dinero et par år tidligere, var målgruppen de helt små iværksættere. Konsulenter, freelancere, foredragsholdere og andre uden ansatte, som havde brug for et let tilgængeligt regnskabssystem.

Vi ville gøre fakturering, bogføring og arbejdet med moms og skat lettere. Det var de mennesker, vi byggede forretningen og systemet til.

Efterhånden fik vi mange ønsker om en forbindelse til webshops. Det kunne føles som rigtig mange, når man over tid fik et par hundrede mails og opfordringer. Men i forhold til hele brugerskaren var det stadig en lille del. Jeg sagde, at vi havde ladet os forføre lidt af de ønsker.

Et API var som et stik, andre kunne koble sig på

Jeg forklarede API’et som en slags stik i væggen, hvor andre kunne programmere en forbindelse til vores system. En webshop kunne for eksempel få et salg bogført i Dinero, uden at en person manuelt skulle taste det ind.

Det kunne spare tid, især i større webshops, og give muligheder for statistik og andre ting. Jeg mente dengang, at mange mindre og mellemstore shops kunne klare sig med mere samlet, manuel bogføring.

Jeg var usikker på de præcise regler for, hvor ofte det måtte gøres, og sagde det også i videoen. Mine overvejelser om samlet bogføring er derfor en del af forklaringen fra 2014, ikke en vejledning til at bogføre en webshop i dag.

Vi vurderede først, at API’et ikke ville være særlig svært at lave, fordi Dineros opbygning allerede byggede på et API. Det kunne gøre nogle brugere glade, så vi lovede det og meldte ud, at vi ville være færdige i juli.

Selve API’et var ikke hele opgaven

Da vi nåede juli, var selve API’et efter min beskrivelse færdigt. Men så begyndte konsekvenserne at stå tydeligere for os.

En almindelig bruger som en konsulent eller freelancer havde et nogenlunde overskueligt aktivitetsmønster. Jeg nævnte måske otte-ti login om måneden, nogle få fakturaer og omkring 15–25 bilag. Tallene var eksempler på det mønster, vi arbejdede ud fra.

Det gjorde det lettere at vurdere behovet for servere og datakraft, efterhånden som antallet af brugere voksede. Hvis en del af softwaren begyndte at halte, havde vi en idé om udviklingen og tid til at reagere.

En webshop med 500 ordrer om dagen ville være noget andet. På en måned kunne det blive omkring 15.000 bilag i stedet for nogle få dusin. Jeg brugte det som billede på, at én webshop kunne belaste systemet mange hundrede gange mere end en almindelig bruger.

Hvad ville der ske, når julesalget gik i gang?

Jeg forestillede mig, at vi åbnede forbindelsen og hurtigt fik 500–600 webshops på. Hvad ville der så ske i december, når julesalget tog fart? Ville systemet stadig være hurtigt og behageligt at bruge for alle?

Det var vi bekymrede for. Det var ikke, fordi jeg mente, problemerne var umulige at løse. Men da vi begyndte at undersøge og dimensionere løsningen, vurderede vi, at der skulle to-tre ekstra medarbejdere til alene for at sikre, at det ikke blev langsomt for nogen.

Det var vores daværende forventning til den ekstra indsats. Vi stod ikke med et dokumenteret resultat fra en stor, færdig webshopintegration.

En fejl kunne ligge fire forskellige steder

Supporten var en anden udfordring. Hvis en webshop ringede og sagde, at forbindelsen ikke virkede, hvor lå fejlen så?

Var det Dinero? API’et? Den connector, vi ikke selv havde lavet mellem API’et og webshoppen? Eller selve webshoppen?

Vi havde ikke længere kontrol over hele kæden. Min vurdering var, at vi ville få brug for flere supportere, som også kunne programmere og undersøge kode i andre systemer for at finde fejlen.

Det ændrede vores billede af opgaven. Det handlede ikke længere kun om at bygge et stik. Vi skulle også håndtere den løbende belastning og de problemer, der opstod rundt om forbindelserne.

Vi måtte vælge, hvem vi først og fremmest ville bygge for

Jeg fortalte, at vi anslog, at under fem procent af brugerne, som ville koble webshops på, kunne komme til at stå for 50–70 procent af vores samlede udviklings- og supportomkostninger. Det var vores anslag og begrundelse på det tidspunkt.

Hvis vi lagde hele den ekstra omkostning over på webshopbrugerne, mente vi, at vi ville blive dyrere end e-conomic og andre systemer med API. Hvis vi i stedet tog den ind i forretningen, frygtede vi, at det ville gå ud over de øvrige brugere.

Vi ville have sværere ved at lave de nye funktioner, vi havde lovet dem, og vi var bekymrede for stabiliteten. Jeg beskrev det som at blive utro mod den målgruppe, vi oprindeligt havde valgt.

Beslutningen var derfor at ændre planen for webshops. API’et var der stadig, og jeg forventede, at det ville blive frigivet til andre anvendelser, for eksempel tidsstyring og kørselsregnskab. Men vi ville ikke åbne for den webshopbelastning, vi frygtede. Det er en beskrivelse af beslutningen i juli 2014.

Folk havde ret til at være vrede

Da vi meldte beslutningen ud, blev vi ikke populære hos alle. Det kunne jeg godt forstå. Nogle havde ventet og glædet sig til noget, vi faktisk havde lovet dem.

En del accepterede forklaringen og var indstillet på at fortsætte manuelt. Andre blev meget vrede. Det var ikke noget, jeg kunne argumentere væk ved at sige, at beslutningen gav mening for os.

Vi havde skrevet et blogindlæg, hvor vi forklarede forløbet og lagde kortene på bordet. Og vi gav en uforbeholden undskyldning. Jeg var ked af at skuffe folk og af at have skabt en forventning, der ikke blev indfriet. Jeg vidste godt, at det kostede på tilliden til både mig og teamet.

Find fakta, forklar løsningen og prøv at rette op

Mit råd til andre i en shitstorm var først at finde ud af, hvad der faktisk var sket, og hvordan man ville korrigere det. Det kunne også være et nedbrud eller en helt anden situation.

Hos os handlede det blandt andet om at prøve at kompensere brugere, som var særligt ramt, måske fordi de havde betalt forud. Jeg beskrev ikke en bestemt kompensationsordning, men sagde, at vi måtte finde en løsning og gøre det så godt, vi kunne.

Og så måtte vi lægge os fladt ned. Folk havde ret til at være vrede og skuffede. Når vi havde lovet noget og ikke kunne holde det som forventet, skulle vi forklare, hvad der var sket, fortælle, hvad vi ville gøre ved det, og sige undskyld uden forbehold.

Sig undskyld til kunderne og forklar, hvad der skete

Vi havde lovet en mulighed for at forbinde webshops med Dinero gennem et API. Da vi kom længere med arbejdet, blev vi bekymrede for, hvad det ville betyde for drift og support.

En webshop kunne sende langt flere transaktioner end den lille virksomhed, vi oprindeligt havde bygget systemet til. Samtidig kunne fejl ligge flere steder i forbindelsen mellem systemerne.

Vi vurderede dengang, at det ville kræve en indsats, som kunne gå ud over vores øvrige brugere. Tallene i videoen er vores daværende overvejelser og anslag.

Beslutningen skuffede dem, der havde ventet

Vi valgte at ændre planen for webshopforbindelsen. Det var svært, fordi vi faktisk havde lovet noget andet, og folk havde glædet sig til det.

Jeg kunne godt forstå reaktionen. Vi havde skabt forventningen, og derfor kunne vi ikke bare argumentere folks skuffelse væk.

Læg kortene på bordet

Jeg fortæller, at vi forklarede beslutningen i et blogindlæg og gav en uforbeholden undskyldning. Vi skulle også prøve at finde en løsning for brugere, som følte sig ramt, blandt andet dem, der havde betalt forud.

Mit råd var at få styr på forløbet, fortælle hvad man ville gøre ved det og sige undskyld uden at diskutere, om kunden havde ret til at være vred.

Læs også Min vej som leder om mine erfaringer med at tage ansvar som leder.

Historien handler om beslutningen i 2014. Den beskriver ikke Dineros nuværende API eller muligheder for webshopintegration.

Læs også om at finde sin egen stil som leder.

De bedste hilsner

Martin