Flowchart for onboarding af kunder
Procesdiagram for kunde-onboarding med swimlanes for kunde, salg, implementering, økonomi og support — fra kontraktunderskrift til en kundekonto i stabil drift.
Sådan fungerer det
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.
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.
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.
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.
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.
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.