Flowchart for kundeopsigelse (fra anmodning til lukket konto)
Flowchart for kundeopsigelse: kontraktvilkår og opsigelsesvarsel, årsagen registreret før ethvert fastholdelsestilbud, tilbudstrappen og dens loft, slutfaktura, dataeksport, lukning af adgang og kodning af churn.
Hvad er flowchart for kundeopsigelse (fra anmodning til lukket konto)?
Opsigelse er den proces, de fleste abonnementsforretninger aldrig har skrevet ned, og derfor er det den, der udløser klagerne. Anmodningen lander et andet sted end på opsigelsesknappen, ligger fire dage, og bliver besvaret af den, der samler den op, med en rabat vedkommende selv har fundet på. Ingen registrerer, hvorfor kunden går, før tilbuddet er givet, og på det tidspunkt er svaret altid pris. Opsigelsesvarslet bliver læst første gang, da kunden gør indsigelse mod slutfakturaen. Adgangen bliver slukket samme eftermiddag, anmodningen kom, selv om kontoen er betalt seks uger frem, så en kunde, der var gået i god ro og orden, nu har en åben supportsag og noget at sige offentligt. Til sidst bogføres afgangen som ét tal, der blander dem, der valgte at gå, sammen med dem, hvis betalingskort udløb. Intet af det er en fejlvurdering. Hvert enkelt er et trin, ingen nogensinde er blevet tildelt, i en proces, der findes som en vane frem for som en procedure.
Dette diagram dækker opsigelsen af et løbende abonnement eller en kontraktbunden ydelse, fra ønsket om at opsige modtages, til afgangen er kodet, og kontoen enten er sat i kø til win-back eller spærret. Det er ikke refusionsprocessen: penge retur på en enkelt transaktion, frister for refusion, godkendelse af kulancesager og chargebacks ligger på /da/templates/refusionsproces-for-kunder, og dette diagram trækker kun på det arbejde til den forholdsmæssige refusion til sidst. Det er heller ikke en klage eller en eskalering. En kunde, der er vred frem for på vej ud, hører hjemme i /da/templates/kundeklage-proces eller, hvis sagen skal opad, i /da/templates/eskalering-af-kundeklager, og en ydelse, der er gået i stykker og har skabt en sag, hører hjemme i /da/templates/kundeservice-eskaleringsproces. Det er ikke en fornyelsesbeslutning truffet i ro og mag før udløb: det er /da/templates/kontraktfornyelse-proces, som udløses af en varsling på horisonten frem for af en anmodning i luften, og som er tegnet fra den anden side af bordet, hvor I er kunden, der skal beslutte, om I vil blive ved med at betale. Inddrivelse af penge, der stadig skyldes, efter kontoen er lukket, overtages af /da/templates/debitorproces. Og det er den fjerne ende af /da/templates/kunde-onboarding-proces: de konti, integrationer og licenser, der blev sat op der, er dem, der rulles tilbage her.
Tre ting, som de fleste nedskrevne opsigelsesprocedurer lader være underforstået, er tegnet som beslutninger. 'Må der gøres et fastholdelsesforsøg?' besvares i fasen Kontogennemgang, før tilbudstrappen frem for inde i den, og det er her, én-gangs-reglen bor: en kunde, der allerede er fastholdt med et tilbud, en kunde med en åben faktureringstvist, eller en kunde, der har bedt sig fri for salgshenvendelser, går direkte til varsling. 'Er indrømmelsen inden for teamets bemyndigelse?' skiller det, en medarbejder må give væk, fra det, der kræver en chef, så tilbudstrappen har et skrevet loft i stedet for et humør. Og 'Er ophørsdatoen nået?' er en rigtig port med en venteløkke bag sig, for den enkeltvane, der gør mest skade i denne proces, er at lukke adgangen på opsigelsesdatoen. Den ufrivillige vej er tegnet med: 'Frivillig opsigelse eller manglende betaling?' sender en fejlet betaling ud ad sit eget rykkerspor, der enten genåbner kontoen eller kobler sig på den samme rygrad af varsling og offboarding, så manglende betaling ikke kan rapporteres, som om kunden selv valgte at gå.
Hvad dette flowchart dækker
I denne skabelon
- Seks swimlanes (Kunde, Fastholdelsesteam, Fastholdelseschef, Fakturering, Drift og Revenue operations) fordelt på seks faser: Modtagelse, Kontogennemgang, Fastholdelse, Opsigelse og afregning, Offboarding og Churn-analyse
- Modtagelse fra alle kanaler, der deler sig ved 'Frivillig opsigelse eller manglende betaling?', så en fejlet betaling kører sit eget rykker- og suspenderingsforløb og enten når frem til 'Kontoen genåbnet, ingen churn registreret' eller kobler sig på hovedflowet ved den skriftlige bekræftelse
- Kontogennemgang før enhver forhandling: 'Registrer henvendelsen og find kontrakten' for bindingsperiode, opsigelsesvarsel og automatisk fornyelse, derefter 'Registrer årsagen ud fra årsagskoderne', og så porten 'Må der gøres et fastholdelsesforsøg?', der håndhæver ét fastholdelsestilbud pr. kunde
- En fastholdelsesbane med et loft over sig: 'Giv fastholdelsestilbuddet fra trappen', en kontrol i 'Er indrømmelsen inden for teamets bemyndigelse?', der sender alt større videre til fastholdelseschefen og tilbage igen med et revideret tilbud, og en kundebeslutning, der enten ender i 'Ændring gennemført og opfølgningsdato aftalt' eller kører videre
- Opsigelse og afregning: 'Bekræft varsel og ophørsdato skriftligt', slutfakturaen og pro rata-beregningen, og en trevejsbeslutning i 'Hvad skyldes på ophørsdatoen?', der dækker en refusion, et gebyr for førtidigt ophør eller intet skyldigt beløb
- Offboarding og lukning: en løkke i 'Er ophørsdatoen nået?', der holder adgangen åben og dataeksporten tilgængelig, indtil datoen indtræffer, 'Luk adgangen, og fastsæt sletningsdatoen', afgangsundersøgelsen, kodning af churn i CRM og en deling i 'Egnet til win-back?' til enten en konto i kø eller en konto, der lukkes og spærres for henvendelser
Hvornår du skal bruge skabelonen
- I skal skrive en opsigelsespolitik eller en drejebog for churn og har brug for ét billede af, hvem der modtager anmodningen, hvem der må give rabat, hvem der fakturerer, og hvem der lukker ydelsen
- Jeres churn-tal er ét enkelt tal, og ingen kan fortælle jer, hvor meget af det der er kunder, som vælger at gå, og hvor meget der er betalingskort, som udløb
- Medarbejderne giver forskellige rabatter for at fastholde den samme type kunde, og der findes ingen skreven grænse for, hvad teamet må tilbyde uden en chef
- Kunderne bliver ved med at sige, at de opsagde tidligere, end jeres registreringer viser, og opsigelsesvarsel og ophørsdato bliver diskuteret sag for sag frem for bekræftet skriftligt
- I skal sætte et fakturerings-, CRM- eller provisioneringssystem op og vil have overleveringerne mellem fastholdelse, fakturering og drift aftalt, før noget som helst automatiseres
Sådan fungerer det
Omdøb banerne, så de passer til jeres egne teams
Erstat Kunde, Fastholdelsesteam, Fastholdelseschef, Fakturering, Drift og Revenue operations med de funktioner, I reelt har. Små organisationer lægger som regel fastholdelsesteamet ind under supporten og giver chefbanen til den, der bærer omsætningstallet; et selvbetjeningsprodukt har måske slet intet fastholdelsesteam, og så bliver tilbudstrappen til skærmbilleder i opsigelsesflowet. Slå hellere en bane sammen end at lade den stå tom. Lad dog Kunde-banen være: den bærer to kasser, anmodningen og svaret på tilbuddet, og alt efter dem sker med kontoen frem for sammen med kunden.
Skriv årsagskoderne, før I rører ved tilbuddene
'Registrer årsagen ud fra årsagskoderne' er værdiløst, indtil listen findes og er kort nok til at vælge fra. Otte til tolv koder er som regel nok: pris, manglende funktionalitet, dårlig service eller ustabil drift, lav anvendelse, budgetnedskæring, projekt eller kontrakt afsluttet, bygget internt, skiftet til en navngiven konkurrent, virksomheden lukket eller opkøbt. Læg ét fritekstfelt til, og gør koden obligatorisk, før sagen kan komme videre. Beslut derefter, hvem der gennemgår fordelingen, og hvor ofte, for en kodeliste, ingen læser tilbage, skrider ned i den mulighed, der står øverst i dropdownen.
Byg tilbudstrappen, og læg et loft på den
Skriv trinnene i rækkefølge efter, hvad de koster jer, ikke efter hvad de føles som: en pause eller en nedgradering af abonnementet, en forlængelse af bindingsperioden til en lavere pris, servicekreditter eller udvidet leverance, og til sidst en ren prisrabat. Skriv ud for 'Er indrømmelsen inden for teamets bemyndigelse?' teamets grænse som en procentdel af den årlige aftaleværdi og en maksimal løbetid, og navngiv, hvem der godkender hvert trin derover. Nedskriv de undtagelser, der gør 'Må der gøres et fastholdelsesforsøg?' til et nej, og mål så, hvad hvert trin faktisk fastholder, fordelt på årsagskode, så trappen er ordnet efter dokumentation frem for efter, hvilken indrømmelse teamet har lettest ved at give væk.
Fastlæg reglerne for varsel og ophørsdato
Beslut, hvad der starter varslet (den dato ønsket blev modtaget, ikke den dato sagen blev oprettet), og om perioden løber i kalendermåneder eller til næste faktureringsdato. Skriv, hvad der sker, når der opsiges efter fristen for automatisk fornyelse, for det er den situation, der skaber tvister. Fastlæg derefter indholdet af 'Bekræft varsel og ophørsdato skriftligt': datoerne, serviceniveauet indtil lukning, det forventede slutbeløb, vejen til eksport af data og sletningsdatoen. Forbrugernes opsigelsesret på jeres marked kan tilsidesætte et længere aftalt varsel, så tjek reglerne, før I skriver dem ind.
Sæt urene for lukning af adgang og for opbevaring
Gør 'Luk adgangen, og fastsæt sletningsdatoen' til en tjekliste, der dækker brugerkonti, API-nøgler og tokens, integrationer, tildelinger i single sign-on, delt indhold, mailinglister og alt hardware eller alle licenser, der er udleveret sammen med ydelsen. Beslut, hvad der gemmes efter lukning, på hvilket lovligt grundlag og hvor længe (regnskabsbilag skal normalt overleve kontoen af hensyn til bogførings- og skattereglerne, mens personoplysninger ikke skal), og planlæg sletningen frem for at overlade den til en manuel beslutning måneder senere. Skriv, hvem der bekræfter, at det er sket, og hvor den bekræftelse registreres.
Aftal definitionerne på churn, gå den så igennem og udgiv den
Fastlæg, hvordan frivillig og ufrivillig churn tælles, hvilken dato en opsigelse henføres til, og hvordan en nedgradering eller en pause behandles, før nogen bygger rapporten. Skriv spærrereglerne bag 'Egnet til win-back?' og den korteste karensperiode, før en tidligere kunde kontaktes igen. Gå derefter det færdige diagram igennem med en medarbejder fra fastholdelse, en fra fakturering og den, der kører provisioneringen, ret det til det, de faktisk gør, frem for det, politikken siger, og udgiv den revision; behold de tidligere, så enhver, der åbner den senere, kan se, hvilken version de læser.
Ofte stillede spørgsmål
Hvilke trin består en kundeopsigelsesproces af?
Modtag opsigelsen ad den kanal, den nu kommer på, og log den med et tidsstempel; find kontrakten frem, og fastslå bindingsperiode, opsigelsesvarsel og dato for automatisk fornyelse; registrer årsagen ud fra en fast liste af koder, før der gives noget tilbud; afgør, om der overhovedet må gøres et fastholdelsesforsøg; giv ét tilbud fra tilbudstrappen, og eskaler til en chef, hvis indrømmelsen overstiger teamets bemyndigelse; gennemfør enten den aftalte ændring og sæt en opfølgningsdato, eller bekræft opsigelsesvarsel og ophørsdato skriftligt; beregn og afregn slutfakturaen, hvilket vil sige en forholdsmæssig refusion, et gebyr for førtidigt ophør eller ingenting; hold adgangen åben og dataeksporten tilgængelig indtil ophørsdatoen; luk adgangen dér frem for på opsigelsesdatoen, og fastsæt sletningsdatoen; send en afgangsundersøgelse; kod afgangen i CRM, og rapporter den; og beslut til sidst, om kunden må komme med i en win-back-kampagne eller skal spærres. Rækkefølgen betyder mere end listen: at fange årsagen før tilbuddet, og ophørsdatoen før lukningen af adgangen, er det, der forhindrer processen i at gå galt.
Hvad er forskellen på denne side og et flowchart for refusionsprocessen?
En refusionsproces afgør én betaling. Den spørger, om anmodningen falder inden for refusionspolitikken og fristen, om en chef vil godkende en kulanceundtagelse, om den oprindelige betaling er gennemført og ikke allerede refunderet, og om der kører en chargeback sideløbende, og den slutter, når pengene er tilbage hos kunden. Det terræn er dækket på /da/templates/refusionsproces-for-kunder. En opsigelsesproces afslutter et kundeforhold, og pengene er kun det ene ben af det. Dette diagram håndterer kontraktligt varsel, bindingsperiode og automatisk fornyelse, fastholdelsestilbuddet og hvem der må godkende det, ophørsdatoen, lukning af adgang, dataeksport og sletning, afgangsundersøgelsen, og hvordan afgangen kodes og rapporteres. De mødes ét sted: 'Hvad skyldes på ophørsdatoen?' kan give en refusion, og at udbetale den er refusionsarbejde. Skal I afgøre, om der skal gives penge tilbage på en enkelt transaktion, så brug refusionsskabelonen. Skal I afslutte et abonnement eller en kontrakt, så brug denne, og lad den kalde på refusionsdiagrammet til netop det trin.
Skal I give et fastholdelsestilbud til alle kunder, der opsiger?
Nej, og dette diagram lægger spørgsmålet før tilbuddet frem for efter. 'Må der gøres et fastholdelsesforsøg?' udelukker flere grupper: en kunde, der allerede har taget imod et fastholdelsestilbud ved en tidligere opsigelse, en kunde, der har bedt sig fri for salgshenvendelser, en kunde midt i en åben fakturerings- eller servicetvist, hvor en rabat læses som et forlig, og en virksomhed, der er lukket, opkøbt eller har mistet budgettet helt. At give tilbud ind i de sager spilder teamets tid og irriterer folk, der allerede har truffet deres beslutning. Den forretningsmæssige begrundelse for én-gangs-reglen er enklere. En kunde, der er fastholdt på pris alene, vender som regel tilbage til den samme samtale en periode senere med det nye, lavere tal som udgangspunkt, så en forretning, der giver rabat ved hver opsigelse, fastholder ikke omsætning: den omprissætter sin portefølje én kunde ad gangen. Rapporter fastholdelsesraten og den gennemsnitlige indrømmelse fordelt på årsagskode, og mønstret bliver hurtigt synligt.
Hvornår bør en opsagt kunde miste adgangen til ydelsen?
På ophørsdatoen, altså ved udgangen af den betalte periode eller ved udløbet af det kontraktlige varsel, ikke den dag, anmodningen blev sendt. Dette diagram tegner det som en beslutning, 'Er ophørsdatoen nået?', med en venteløkke bag sig, der holder kontoen åben og dataeksporten tilgængelig, indtil datoen indtræffer. At lukke adgangen for tidligt er den mest almindelige fejl i processen, og den er dyr helt ude af proportion med besparelsen: kunden har allerede betalt for tiden, skal som regel stadig have sine data ud, og en stille afsked bliver til en supportsag, en chargeback eller en offentlig anmeldelse. Undtagelserne er få og bør nævnes særskilt (manglende betaling efter et gennemført rykkerforløb, brud på vilkårene eller svindel), og de bør besluttes af en, der har bemyndigelsen til det, ikke af den, der tilfældigvis behandlede opsigelsen.
Hvad er forskellen på frivillig og ufrivillig churn?
Frivillig churn er en kunde, der beslutter sig for at gå. Ufrivillig churn er en konto, der lukker, fordi en betaling fejlede og aldrig blev inddrevet: et udløbet eller udskiftet betalingskort, en afvist transaktion, en bortfaldet betalingsaftale, en faktura, der er forsvundet inde i et indkøbssystem. De ser ens ud i ét samlet churn-tal og har intet til fælles under det. Frivillig churn besvares med arbejde på produkt, service og pris; ufrivillig churn besvares med betalingsteknik som automatisk kortopdatering, bedre timing på genforsøg og rykkertekster, der rent faktisk bliver læst, og en overraskende stor del af den kan reddes. Derfor deler diagrammet dem ved 'Frivillig opsigelse eller manglende betaling?' i modtagelsesfasen og giver vejen for manglende betaling sit eget rykker- og suspenderingsforløb, der enten ender med genåbning uden registreret churn eller kobler sig på den samme rygrad af varsling og offboarding. Kod de to hver for sig i CRM, og rapporter dem hver for sig, ellers bliver den halvdel, der kan reddes, ved med at gemme sig i gennemsnittet.
Hvor denne proces passer ind
I de fleste virksomheder følger denne proces efter Procesdiagram til at forhindre kundefrafald (akut indsats) og sender videre til Flowchart for refusionsproces (fra anmodning til pengene retur).
Den er ét trin i Kundens livscyklus.
Trin 1: Flowchart for leadkvalificering: fra MQL til accepteret lead
Trin 2: Flowchart for salgsprocessen: fra kundeemne til underskrevet ordre
Trin 3: Flowchart for salgsoverdragelse: fra vundet aftale til customer success
Trin 6: Flowchart for eskalering i kundeservice: niveau 1 til niveau 2
Swimlane-flowchart for eskalering i kundeservice: forsøg på niveau 1, dokumenteret overlevering til niveau 2, vurdering af alvorlighed og SLA samt eskalering til udvikling.
Trin 7: Flowchart for kundeopsigelse (fra anmodning til lukket konto) Du er her
Flowchart for kundeopsigelse: kontraktvilkår og opsigelsesvarsel, årsagen registreret før ethvert fastholdelsestilbud, tilbudstrappen og dens loft, slutfaktura, dataeksport, lukning af adgang og kodning af churn.
Trin 8: Flowchart for kundechurn (fastholdelsesforsøg til win-back)
Flowchart-skabelon til kundechurn: risikosignal, fastholdelsesforsøg, beslutningen fastholdt eller churn, afgangssamtale, offboarding-overlevering, win-back-egnethed og en feedbacksløjfe til churn-analyse.