Flowchart for onboarding af kunder

Hvad er flowchart for onboarding af kunder?

Kunde-onboarding er levering efter salget: alt mellem en underskrevet kontrakt og en kunde, der er i drift, oplært og får det, de har betalt for. Det er værd at holde adskilt fra de to processer, den oftest forveksles med. Leverandør-onboarding er modtagelse, kontrol og godkendelse af en leverandør, I er ved at begynde at betale. Medarbejder-onboarding er en intern tiltrædelsesproces. Kunde-onboarding går den modsatte vej: pengene er allerede bundet, og løftet er allerede givet, så arbejdet består i at levere det, før den sponsor, der købte løsningen, mister tålmodigheden eller skifter job.

Forløbet herunder krydser fem baner. Salg optræder to gange og kun to gange (ved overleveringen og igen, når kunden bliver tavs), og det er nogenlunde den rigtige mængde salgsinvolvering, efter en aftale er lukket. Onboarding eller implementering ejer midten af processen. Økonomi ejer oprettelse af konto, fakturering og de kredit- eller KYC-tjek, jeres organisation kræver. Support optræder én gang, til sidst, fordi det reelt er der, de overtager kunden. Kunde-banen er den, det er værd at læse grundigt: den rummer de tre punkter, hvor kunden, ikke I, styrer forløbet, nemlig levering af data og systemadgange, godkendelse af klarhed til go-live og bekræftelsen efter 30 dage af, om succeskriterierne blev indfriet.

To beslutninger og én gren bærer det meste af leveringsrisikoen. 'Er data migreret korrekt?' har en rettelsesløkke frem for én enkelt godkendelse, fordi migreringer sjældent lander i første forsøg, og en ærlig proces viser det nye forsøg. 'Er go-live godkendt som klar?' er et reelt go/no-go: et no-go sender kunden tilbage til konfiguration, data og oplæring i stedet for stille og roligt at flytte datoen. Og vejen for den tavse kunde er tegnet frem for forudsat: fra intet svar til en rykker fra den kundeansvarlige i salg og videre til en onboarding sat på pause og markeret, hvis der stadig ikke er kontakt. Alle onboarding-teams har den slags kunder; få har et defineret sted at placere dem, så de bliver liggende i en tilfældig indbakke.

Hvad dette flowchart dækker

I denne skabelon

• Fem swimlanes (Kunde, Salg, Onboarding/implementering, Økonomi og Support) fordelt på seks faser: Overlevering fra salg, Kickoff og plan, Konto og fakturering, Konfiguration og datamigrering, Oplæring og go-live samt Ibrugtagning og support
• Overgangen fra aftale til levering: kunden underskriver kontrakten, salg overleverer kunden til onboarding med en overleveringspakke, der afholdes kickoff og aftales succeskriterier, og der udgives en onboarding-plan med navngivne ansvarlige på begge sider
• Opsætningen i Økonomi med en reel forgrening: 'Kræves kredit- eller KYC-tjek?' springer tjekket over, hvor det ikke er relevant, og 'Er compliance-tjekkene godkendt?' frigiver enten kontoen eller sætter den i bero for dokumentation og tester igen, når dokumentationen foreligger
• Vejen for den tavse kunde: 'Har kunden leveret data og adgange?' sender en tavs kunde videre til 'Kontakt genoptaget efter rykker fra salg?', som enten fører tilbage til hovedforløbet eller ender med onboarding sat på pause og markeret, i stedet for en åben opgave, ingen ejer
• Konfiguration og datamigrering med en valideringsløkke: konfigurer system og integrationer, migrer og indlæs kundens data, og lad derefter 'Er data migreret korrekt?' enten føre videre til oplæring eller sende indlæsningen tilbage til rettelse og et nyt tjek
• Oplæring af brugere og administratorer, en go/no-go-beslutning om klarhed placeret i Kunde-banen, go-live i produktion, evaluering af kickoffets succeskriterier efter 30 dage og overlevering til support og den kundeansvarlige

Hvornår du skal bruge skabelonen

• I er ved at bygge eller omskrive en onboarding- og implementeringsfunktion og vil have rækkefølgen og overleveringerne på plads, før nogen skriver drejebogen
• Kunder går i stå efter underskrift, og ingen kan sige, om forsinkelsen ligger hos jeres team, hos økonomi eller hos kunden
• Salg og levering er uenige om, hvad der blev lovet, og overleveringen skal være et trin i processen frem for en videresendt mailtråd
• Tid til go-live eller tid til første værdi er et nøgletal, I rapporterer på, og I har brug for at se, hvilken bane der holder hver kunde i hver fase
• I skal have nye implementerings- eller customer success-medarbejdere hurtigt op i gear og vil have én side frem for en langt skrevet procedure

Sådan fungerer det

1. Tilpas banerne til jeres leveringsteams

   Omdøb Kunde, Salg, Onboarding/implementering, Økonomi og Support til de teams, der faktisk findes hos jer. Mindre organisationer slår typisk implementering og support sammen til én bane eller kører onboarding ud af customer success. Slet en bane frem for at lade den stå tom, men behold Kunde-banen, selv om den kun rummer tre noder, fordi det er den klareste måde at vise, hvor stor en del af den kritiske vej I ikke selv styrer.

2. Definer, hvad overleveringen fra salg skal indeholde

   Gør 'Overlever kunden til onboarding' til en tjekliste: underskrevet scope, hvad der reelt blev lovet under salget, hvad der allerede er aftalt som uden for scope, navngivne kontaktpersoner og beslutningstagere hos kunden, ønsket go-live-dato og den kommercielle deadline bag den. Beslut, om salg forbliver på kunden gennem kickoff, og skriv det på diagrammet: et uafklaret svar betyder i praksis altid ingen.

3. Skriv succeskriterierne som målbare udsagn

   'Afhold kickoff og aftal succeskriterier' er kun brugbart, hvis resultatet kan testes efter 30 dage. Erstat løse mål med udsagn, der nævner et tal, en ansvarlig og en dato: for eksempel en bestemt mængde behandlet i systemet inden en given uge, eller et navngivet team, der bruger det som deres primære system. Det er præcis de samme udsagn, trinnet 'Evaluer succeskriterier efter 30 dage' læser op, så vage kriterier koster jer to gange.

4. Fastlæg triggeren i økonomi og reglerne for bero

   Notér, hvad der gør 'Kræves kredit- eller KYC-tjek?' til et ja hos jer (for eksempel kontraktværdi, betaling på faktura, en ny juridisk enhed eller en reguleret branche), og hvem der afgør det. Skriv derefter, hvad bero betyder i praksis: om konfigurationsarbejdet fortsætter, mens kontoen er i bero, hvem der orienterer kunden, og hvilken dokumentation der frigiver den. Tag formuleringen fra jeres egen politik frem for fra denne skabelon.

5. Aftal migreringstesten inden migreringen

   Udfyld, hvad 'Er data migreret korrekt?' faktisk tjekker: antal poster pr. objekt, kontrolsummer på beløbsfelterne og en stikprøve, kunden selv gennemgår. Navngiv, hvem der godkender (det skal være kunden og ikke det team, der kørte indlæsningen), og sæt en grænse for, hvor mange rettelsesrunder der kører, før go-live-datoen formelt tages op igen.

6. Lås go/no-go-kriterierne og udgiv en versionsstyret kopi

   List klarhedskriterierne på forhånd, udpeg hvem der leder gennemgangen, og bekræft, at beslutningen ligger hos kunden. Tilføj jeres egne grænser for, hvornår en kunde er gået i stå, på rykkergrenen: for eksempel antal dage uden svar før eskalering og før pause. Del derefter diagrammet med salg, økonomi og support til kommentering, og hold det under versionsstyring, så diagrammet og den skrevne drejebog ikke skrider fra hinanden.

Ofte stillede spørgsmål

Hvor lang tid bør kunde-onboarding tage?

Det afhænger næsten udelukkende af, om datamigrering og integrationer er med i scope. En selvstændig kunde uden migrering kan være i drift på en til to uger. Læg en datamigrering og en enkelt integration til, og fire til otte uger er realistisk; implementeringer på tværs af flere systemer med sikkerhedsgennemgang tager længere. Det brugbare mål er ikke den samlede tid, men hvor længe hver bane holder kunden, fordi de fleste overskridelser er ventetid og ikke arbejdstid, og den største enkeltpost er som regel ventetid på kundens egne opgaver som dataudtræk og administratoradgange. Mål overleveringerne, før I forsøger at presse arbejdet sammen.

Hvad skal overleveringen fra salg til onboarding indeholde?

Nok til at leveringsteamet ikke stiller kunden spørgsmål, kunden allerede har svaret på. Det vil sige det underskrevne scope, hvad der blev lovet mundtligt under salget, hvad der eksplicit er holdt udenfor, de kommercielle vilkår der påvirker leveringen som startdato for fakturering, den navngivne sponsor og de daglige kontaktpersoner, det tekniske miljø kunden har beskrevet, og enhver deadline kunden har lovet internt. Læg det i en struktureret form frem for en fortællende mail. Den hyppigste fejl er løftet, der bliver givet i kvartalets sidste uge og aldrig når frem til den, der skal indfri det.

Hvad gør I, når en ny kunde bliver tavs under onboarding?

Fastlæg grænserne på forhånd frem for fra sag til sag. Dette flowchart sender en kunde uden respons fra 'Har kunden leveret data og adgange?' videre til en rykker fra den kundeansvarlige i salg, som har relationen og oftest sponsorens mobilnummer, og derefter til en pause med markering, hvis der stadig ikke er kontakt. At sætte forløbet eksplicit på pause betyder to ting: det stopper kunden fra at binde implementeringskapacitet, der stille er reserveret til dem, og det skaber en dokumentation af, hvorfor go-live-datoen flyttede. Aftal, hvad en pause betyder kommercielt, for faktureringen er ofte allerede begyndt.

Hvordan adskiller kunde-onboarding sig fra leverandør- og medarbejder-onboarding?

De deler et ord og næsten intet andet. Leverandør-onboarding er modtagelse: due diligence, risikoklassificering og verifikation af bankoplysninger, før en leverandør kan få penge, med bevisbyrden hos leverandøren. Medarbejder-onboarding er en intern tiltrædelsesproces med kontrakt, udstyr og adgange. Kunde-onboarding er levering efter salget, hvor det er jer, der har noget at bevise, og kunden allerede har en underskrevet kontrakt og en forventning. Den praktiske konsekvens er, at kunde-onboarding ikke har en port, I bare kan nægte at åbne: går forløbet i stå, skal diagrammet indeholde en defineret pause og en eskalering, ikke et afslag.