Sådan laver du en onboarding-proces for kunder

Kort fortalt

• Gør overleveringen til en port frem for en meddelelse; kun den ene af de to holder.
• Giv kunden en bane, fordi de holder to af portene, ikke fordi de er langsomme.
• Succeskriterierne hører til på kickoff, for det er dem, en evaluering efter 30 dage måler imod.
• Et no-go, der kun flytter go-live-datoen, er en forsinkelse i en beslutnings form.
• Compliance-hold på en konto er normalt; design sløjfen frem for at eskalere hver enkelt.

Onboarding fejler ved overdragelsen, ikke inde i den

Intet i onboarding af kunder er teknisk svært, og det skrider alligevel. Årsagen er strukturel: processen spænder over to interne teams, der mødes ved ét trin, og de fleste onboarding-dokumenter behandler det trin som en meddelelse. Salget lukker, der oprettes en kanal, implementering begynder at læse. Hvad der blev lovet i mødelokalet, hvem hos kunden der må beslutte, hvilken integration man antog fandtes: intet af det er en betingelse for noget, så intet af det skal være sandt, før næste trin begynder.

Leveringen skal kunne afvise kontoen, og nogen med mandat skal sige det på forhånd. Den tilladelse forvandler overleveringspakken fra en høflighed til et sæt betingelser (et underskrevet scope og en navngiven kontaktperson med beslutningskompetence er der, eller de er ikke), og den giver kortet et sted, hvor processen stopper og venter. Uden det er et onboarding-kort en huskeliste med pile, og en overskridelse er en betingelse, der levede i nogens hoved og blev sprunget over, uden at nogen besluttede at springe den over.

Eksemplet herunder giver kunden sin egen bane, og det er den anden ting, der er værd at kopiere: en beslutning tegnet i en andens bane kan man ikke svare på for dem. »Har kunden leveret data og adgange?« er dér, processen stopper, og grenen »Intet svar« giver kontoen videre til »Kontakt genoptaget efter rykker fra salg?« frem for til en lukning. »Er go-live godkendt som klar?« sender sit »No-go« tilbage i »Konfigurer system og integrationer« frem for at flytte datoen.

Fra underskrevet kontrakt til reel brug

Onboarding af kunder fordelt på fem baner, den første kundens egen: den bane, der afgør, hvornår alt det andet må gå videre.

1. Overleveringen er hele risikoen

   En underskrift, en overlevering, et kickoff der aftaler succeskriterier, og derefter en udgivet plan med ansvarlige: fire rækker, hvoraf »Overlever kunden til onboarding« er den anden. Det meste af det, der skrider senere, kan spores tilbage til, hvad den række bar med sig eller ikke bar.

2. Et hold er ikke en afvisning

   Banekolonnerne fyldes ud, og Økonomi tager kontoen i fire rækker. »Kræves kredit- eller KYC-tjek?« sender dem, der gør, videre til »Er compliance-tjekkene godkendt?«, som kan svare »Sat i bero«, og »Sæt kontoen i bero for dokumentation« vender tilbage til netop den beslutning på »Dokumentation modtaget«.

3. Porten kunden selv holder

   »Har kunden leveret data og adgange?« er dér, processen holder op med at arbejde på kundens vegne, og »Intet svar« gives videre til salg, der rykker. Derefter konfiguration og migrering, og »Er data migreret korrekt?«, der sender fejl til »Ret fejl og indlæs data igen« til et nyt tjek.

4. No-go sender arbejdet tilbage

   Oplæring, og derefter »Er go-live godkendt som klar?«, som kunden holder: »Go« går videre, »No-go« vender tilbage til »Konfigurer system og integrationer«. Efter evalueringen på 30 dage kommer »Overlever til support og kundeansvarlig«; det eneste fejlslutpunkt er »Onboarding sat på pause og markeret«, som nås på »Ingen kontakt«.

Sådan fungerer det

1. Skriv ned, hvad leveringen tager imod

   List de betingelser, implementering har brug for, før de tager kontoen: underskrevet scope, en navngiven kontaktperson med beslutningskompetence, forudsætninger for miljø og integrationer, og alt hvad der blev lovet under salget. Alt på listen, der ikke kan kontrolleres, er ikke en betingelse, men et håb: gør det kontrollerbart, eller fjern det.

2. Skil jeres egne trin fra kundens

   Gå flowet igennem to gange. Markér først, hvilke trin kunden udfører, og derefter hvilke beslutninger kun kunden kan svare på: den anden liste er kort, som regel to poster, og det er den, der stopper alt. Skriv ud for hver, hvad der sker, når der ikke kommer et svar, for det er den vej, I kommer til at bruge.

3. Skriv trinnene som rækker, og forbind dem med numre

   Hver række i kolonnen Bokstekst bliver en kasse. Skriv de rækkenumre, et trin fører til, i kolonnen Linje til, adskilt af komma. Fordi forbindelserne er numre frem for tegnede streger, forbliver flowet intakt, når et trin omdøbes eller arket omorganiseres, og det er forskellen på et kort, I retter i, og et kort, I tegner forfra.

4. Sæt kunden i kolonnen Lodret bane

   Ansvarlige står i kolonnen Lodret bane og faser i kolonnen Vandret bane, og kolonnen er ligeglad med, om den ansvarlige er på jeres lønningsliste. Læg en beslutningsrække i kundens bane, og diagrammet siger direkte, at svaret ikke er jeres at give, og det er sværere at tale sig omkring på et kickoff end den samme sætning i en plan.

5. Tegn hver afvisning som en navngiven gren

   Hvert spørgsmål får Beslutning i kolonnen Figur, begge sine destinationer i Linje til og sine grennavne i Linjetekst i samme rækkefølge, så ingen pil forlader en rombe uden tekst. Et lavere rækkenummer er måden, en sløjfe skrives: et fejlet migreringstjek, der vender tilbage til rettelsestrinnet, et no-go, der vender tilbage til konfigurationen.

6. Send det til godkendelse, og del så linket

   Send det færdige diagram til godkendelse, og send derefter linket til kundeteamet og til kundens navngivne kontaktperson. En godkendelse på en plan, der forlader virksomheden, besvarer det spørgsmål, de stiller først (er dette aftalt, eller er det nogens udkast), og den daterer den revision, kickoffet arbejdede ud fra.

Faldgruber du skal undgå

• Overlevering ved at invitere til en kanal

  At tilføje implementering til en tråd er ikke en overdragelse af ansvar. Indtil nogen har bekræftet, hvad de tager imod, bliver salgets antagelser i sælgerens hukommelse og dukker op igen som diskussioner om scope i uge tre.

• At svare på kundens port for dem

  Der ankommer et delvist udtræk, og »Har kunden leveret data og adgange?« bliver sat som opfyldt, fordi alternativet er at stoppe. Porten attesterer så ingenting, og de manglende felter dukker op i migreringen som et dataproblem frem for et indsamlingsproblem.

• At flytte datoen frem for at beslutte

  Kan en beslutning om klarmelding kun udskyde, er det ikke en beslutning. Det brugbare svar på ikke klar er en vej tilbage til bestemt arbejde (konfiguration, migrering eller oplæring) med datoen genberegnet fra det sted, arbejdet starter igen.

• Ingen vej for en kunde, der går i tavshed

  Konti, der holder op med at svare, lukker ikke sig selv; de ligger i en pipeline og bruger opmærksomhed og prognose. Tegn en eksplicit tilstand for sat på pause og markeret, så en konto enten er i fremdrift eller synligt parkeret.

Lav jeres eget kort over kunde-onboarding

Åbn eksemplet som jeres eget diagram, fastlæg hvad implementering skal have, før de tager en konto, og omdøb banerne til jeres egne teams.

Lav jeres eget kort over kunde-onboarding

Relaterede guides

• Sådan laver du et tværfunktionelt flowchart
• Sådan laver du et swimlane-diagram
• Sådan kortlægger du overleveringer i en proces

Ofte stillede spørgsmål

Hvad skal en overlevering fra salg til levering indeholde?

Seks ting, alle kontrollerbare: det underskrevne scope, de kommercielle vilkår, der påvirker leveringen, en navngiven kontaktperson hos kunden med mandat til at godkende, alt hvad der blev lovet under salget inklusive det mundtlige, de tekniske forudsætninger, løsningen antager, og alt hvad der allerede er aftalt som uden for scope. De sidste to mangler oftest, og de er de to, der giver diskussioner om scope i uge tre. Gør pakken til en betingelse for overleveringen frem for et dokument, der laves bagefter.

Hvor lang tid bør onboarding af en kunde tage?

Ikke i uger, og et tal oplyst uden sine betingelser er et tal, I kommer til at misse. To af beslutningerne her tilhører kunden (»Har kunden leveret data og adgange?« og »Er go-live godkendt som klar?«), så enhver dato er en prognose betinget af begge. Udgiv den sådan: datoen, de to svar den afhænger af, og hvad der sker, hvis de ikke kommer, for grenen »Intet svar« flytter datoen frem for at absorbere forsinkelsen. Kunder, der får at vide, hvilket af deres svar der holder datoen, giver det som regel hurtigere.

Skal kunden se onboarding-planen?

Ja, og den samme plan som I arbejder efter, ikke et resumé af den. En plan, kunden kan læse, er den eneste form, hvor påstanden om, at deres egne trin ligger på den kritiske vej, bliver troet, og den gør samtalen om klarmelding til go-live til noget, der forhandles på forhånd frem for leveres som en overraskelse. Skriv deres kontaktperson på de rækker, de ejer, og udgiv de datoer, rækkerne bærer, så holder de to svar, kun de kan give, op med at komme sent som standard.

Hvad er time to value, og hvordan måles det?

Time to value er den tid, der går fra underskrift til, at kunden får det udfald, de købte, målt mod kriterier aftalt på kickoff frem for mod go-live. Go-live er en milepæl i jeres proces; værdi er en hændelse i deres. Vælg én observerbar ting per kunde (et transaktionsvolumen i drift, en rapport økonomi faktisk bruger, en kø besvaret af det nye system) og tjek den efter 30 dage. Uden det tjek kan processen ikke fortælle jer, om den virkede.