Flowchart for kundeopsigelse (fra anmodning til lukket konto)

Sådan fungerer det

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.