Flowchart for refusionsproces (fra anmodning til pengene retur)

Hvad er flowchart for refusionsproces (fra anmodning til pengene retur)?

En refusionsproces er pengesiden af at rette op på noget. En kunde beder om sine penge tilbage, nogen afgør, om anmodningen lever op til politikken, en anden bekræfter, at den oprindelige betaling er reel og ikke allerede er refunderet, refusionen gennemføres hos betalingsudbyderen, bogføringen rettes, og kunden får at vide, hvornår pengene er fremme. Fem parter rører ved den, og kun kunden ser det hele: det er derfor, refusioner som regel ser hurtige ud indefra og langsomme ud udefra.

Det er ikke returprocessen, og forskellen er vigtig, når I skal vælge, hvilket diagram I arbejder ud fra. Returprocessen afgør, hvor varen ender: der udstedes en returnummer, pakken bliver bogført ind, varen bliver kontrolleret og klassificeret, og den bliver lagt på lager igen, repareret eller skrottet. Den proces overleverer til denne her i det øjeblik, refusion bliver den aftalte afhjælpning. Dette diagram starter ved selve anmodningen om refusion og følger kun pengene, hvilket også er grunden til, at det gælder, hvor der slet ikke kommer noget retur: opsagte abonnementer, ubrugte ydelser, dobbelte træk og digitale køb. Det er heller ikke klageprocessen. En klage spørger, om virksomheden har gjort noget forkert; en anmodning om refusion beder om et bestemt beløb tilbage.

Diagrammet dækker fem baner (Kunde, Kundeservice, Økonomi, Leder og Betalingsudbyder) fordelt på fem faser fra anmodning til bekræftelse og afslutning. Det indeholder de tre grene, refusionsprocedurer normalt lader være udokumenterede: en undtagelsesvej, hvor en anmodning uden for politikken går til en leder for kulancegodkendelse frem for at blive afvist ved skranken, en beslutning om fuld eller delvis refusion, hvor fradraget aftales med kunden, før refusionen gennemføres, og en chargeback-gren, fordi en anmodning fra en kunde, der allerede har gjort indsigelse over for sin bank, ikke må refunderes ad den normale vej.

Hvad dette flowchart dækker

I denne skabelon

• Fem baner (Kunde, Kundeservice, Økonomi, Leder og Betalingsudbyder) fordelt på fem faser: Anmodning, Berettigelse, Godkendelse, Udbetaling af refusion samt Bekræftelse og afslutning
• Modtagelsen i Kundeservice-banen: anmodningen registreres med en årsagskode fra en fast liste, og porten 'Svindelflag eller chargeback?' drejer markerede sager af, før der overhovedet flyttes penge
• Et tjek af refusionspolitik og frist, der fører ind i beslutningen 'Berettiget efter refusionspolitikken?', hvis undtagelsesgren sender anmodningen til en leder, som enten godkender en kulancerefusion eller afviser den med en begrundelse
• Verifikation af den oprindelige betaling i Økonomi-banen, som både den berettigede vej og den godkendte kulancevej løber igennem, så der aldrig refunderes mod en betaling, der ikke er gennemført eller allerede er refunderet én gang
• Beslutningen 'Fuld eller delvis refusion?', hvor den delvise gren går tilbage til kundeservice for at aftale fradraget med kunden, før refusionen gennemføres
• Gennemførelse og afslutning: refusionen gennemføres hos udbyderen retur til det oprindelige betalingsmiddel, bogføres og bekræftes over for kunden med en forventet dato, mens chargeback-grenen holder refusionen tilbage, indsender dokumentation og ender i 'Chargeback imødekommet?', hvorfra en tilbagetrukket indsigelse går tilbage til tjekket af berettigelse

Hvornår du skal bruge skabelonen

• I skriver eller omarbejder en refusionspolitik og har brug for at se, hvem der udfører hvert trin, og hvem der må godkende en undtagelse, ikke kun hvad politikken lover
• Refusioner tager for lang tid, og I har brug for at adskille den del, I selv styrer (beslutningen og gennemførelsen), fra den del kundens bank styrer (afviklingen)
• Kulancerefusioner gives inkonsekvent, eller medarbejdere godkender beløb op mod en grænse, ingen har skrevet ned
• Antallet af chargebacks stiger, og det samme team håndterer både refusioner og indsigelser uden en regel om, hvad der går forud for hvad
• I er ved at opsætte et helpdesk-, fakturerings- eller betalingssystem og vil have fordelingen mellem kundeservice, økonomi og udbyder aftalt, før noget bygges

Sådan fungerer det

1. Fastlæg testene bag beslutningen om berettigelse

   Erstat 'Berettiget efter refusionspolitikken?' med jeres reelle tests: hvilken dato der starter fristen (køb, levering eller ophør af ydelse), hvilke varer eller abonnementstyper der er undtaget, og hvilken dokumentation der kræves. Notér, hvilken version af politikken der blev anvendt på hver sag. Skriv undtagelsen eksplicit ind, for forbrugerens fortrydelsesret og reklamationsret står over jeres egen politik og bliver ikke sat ud af kraft af en kortere frist.

2. Omdøb banerne til jeres faktiske roller

   Læg Kundeservice, Økonomi og Leder oven på de funktioner, I reelt har, og slå baner sammen frem for at lade en stå tom, hvis ét team både beslutter og betaler. Behold Betalingsudbyder-banen, selv når refusionen er ét API-kald: det er en overlevering, I ikke styrer, og det er der, kundens ventetid bliver brugt.

3. Fastsæt beføjelse og grænser for kulance

   Notér ud for 'Godkendes kulancerefusion?', hvem der må godkende en refusion uden for politikken og op til hvilket beløb, og kræv at begrundelsen registreres på sagen. Rapportér derefter kulanceandelen pr. produkt og pr. årsagskode. En stigende kulanceandel er som regel et signal om, at den skrevne politik ikke længere svarer til det, forretningen er villig til at gøre.

4. Definer, hvad en delvis refusion må fratrække

   List de fradrag, der er tilladt (for eksempel allerede forbrugt ydelse, fragt ud eller et returgebyr), og skriv, hvem der må anvende hvert enkelt. Beslut, om kunden skal acceptere beløbet, før refusionen gennemføres, sådan som dette diagram forudsætter, eller får det oplyst bagefter. Delvise refusioner skaber de fleste tvister om refusion, så begrundelsen hører hjemme på sagen.

5. Peg bogføringstrinnet på rigtige konti

   Skriv, hvilken konto refusionen bogføres på, hvordan momsen reguleres, og om der udstedes en kreditnota: for i mange lande kræver momsreguleringen et bilag og ikke kun en postering. Tilføj, hvordan udbyderens afregningsrapport afstemmes, og notér, at udbyderens gebyrer på den oprindelige transaktion ofte ikke følger med retur.

6. Gå chargeback-grenen igennem med jeres udbyder

   Bekræft udbyderens indsigelsesproces: hvilken dokumentation der accepteres, hvem der samler den, og hvilken frist I har til at svare. Skriv den regel ned, som diagrammet håndhæver: at en betaling, der allerede er indsigelsesramt, holdes tilbage frem for at blive refunderet sideløbende, og aftal, hvad der sker med sagen, når indsigelsen trækkes tilbage, og anmodningen går tilbage til den normale vej.

Ofte stillede spørgsmål

Hvad er forskellen på en refusionsproces og en returproces?

En returproces afgør varen: den udsteder et returnummer, bogfører pakken ind, kontrollerer og klassificerer varen og beslutter, om den lægges på lager igen, repareres eller skrottes. En refusionsproces afgør pengene: berettigelse, godkendelse, verifikation af betalingen, selve refusionen, bogføringen og bekræftelsen til kunden. De mødes ét sted, nemlig hvor en retur er vurderet, og refusion bliver den aftalte afhjælpning. At holde dem som to adskilte diagrammer er bevidst, for rigtig mange refusioner har slet ingen vare med i billedet: opsagte abonnementer, ubrugte ydelser, dobbelte træk og digitale køb.

Skal en refusion altid gå tilbage til det oprindelige betalingsmiddel?

Som udgangspunkt ja, og dette diagram er tegnet sådan. At refundere til det kort eller den konto, der blev betalt med, er det, kortselskabernes regler normalt forventer, det er det, forbrugerreglerne forudsætter, medmindre kunden aftaler andet, og det fjerner en oplagt svindelvej, for at omdirigere en refusion til en anden modtager er en velkendt måde at hente penge ud af et stjålet kort på. Der findes reelle undtagelser (først og fremmest lukkede eller udløbne konti), og de bør håndteres som en navngiven undtagelse med registreret identitetskontrol, ikke som en tjeneste ved skranken.

Hvad skal der ske, når kunden allerede har gjort indsigelse (chargeback)?

Hold refusionen tilbage. Refunder ikke og forsvar sagen samtidig, ellers kan I ende med at miste både refusionen og det omtvistede beløb. Mange udbydere tillader slet ikke en refusion på en betaling, mens en indsigelse er åben, og hvor en refusion stadig kan gennemføres, trækker den ikke automatisk indsigelsen tilbage. Svar gennem udbyderens indsigelsesproces med den dokumentation, der efterspørges, og lad afgørelsen falde. I dette diagram lukker en imødekommet chargeback sagen med pengene ført retur gennem kortordningen, mens en tilbagetrukket indsigelse går tilbage til det normale tjek af berettigelse.

Hvem bør afgøre, om der gives en delvis frem for en fuld refusion?

I dette diagram ejer Økonomi-banen beslutningen 'Fuld eller delvis refusion?', og kundeservice aftaler det delvise beløb med kunden, før det gennemføres: så beregningen og samtalen ligger hos dem, der er bedst til hver del. Det, der får det til at fungere, er en skreven liste over tilladte fradrag med en ansvarlig for hvert enkelt, frem for et skøn fra sag til sag. Har kunden krav på refusion efter loven (for eksempel ved en mangelfuld vare eller en fortrydelse inden for fristen), er jeres mulighed for at fratrække begrænset, så tjek rettigheden, før I behandler beløbet som forhandlingsbart.

Hvor lang tid bør en refusion til en kunde tage?

Del svaret i to, for kun den ene halvdel er jeres. Den del, I styrer, løber fra anmodning til refusionen er gennemført, og det er der, et mål hører hjemme, for eksempel en afgørelse inden for et fast antal arbejdsdage og gennemførelse samme dag som godkendelsen. Den del, I ikke styrer, er afviklingen: den tid, pengene er om at stå på kundens konto, og den fastsættes af kortudsteder og løber typisk over flere arbejdsdage. Der kan gælde lovbestemte frister for tilbagebetaling ved fortrydelse på jeres marked, så tjek de regler, der omfatter jer. Brug af denne skabelon gør ikke i sig selv en proces compliant; den giver jer en dokumenteret procesbeskrivelse, I kan holde under versionsstyring med et spor for gennemgang og godkendelse.