Hvert løbende medlemskab i Zenamu fører en komplet intern registrering af hver vigtig begivenhed: fra det øjeblik, det oprettes, gennem hver fornyelse, pause og opsigelse, helt frem til eventuelle refunderinger. Denne registrering er din fulde historik og dit sikkerhedsnet til at løse tvister og håndtere regnskab. Denne artikel forklarer, hvor du finder et medlemskabs aktivitet, og hvordan du læser hver type begivenhed.
Hvor du finder et medlemskabs aktivitet
Åbn en kundes medlemskabsdetaljer i administrationen, og du ser:
Medlemskabets nuværende status (aktivt, sat på pause, afventer betaling, aflyst og så videre), næste fornyelsesdato og — hvis noget mislykkedes — detaljer om henstandsperioden og den mislykkede betaling.
Afsnittet Ordrer: en liste over de dokumenter, der er udstedt for dette medlemskab (oprettelsesdato, betalingsdato, betalingsstatus, beløb, beskrivelse og et link til dokumentdetaljerne). Det er din vigtigste kilde til information om de enkelte gennemførte betalinger, og det fungerer samtidig som grundlag for dit regnskab.
I sin profil (under Mine medlemskaber → detaljer) ser kunden den samme status og den samme liste over sine ordrer.
Vigtigt: Zenamu har endnu ikke en dedikeret "Fornyelseshistorik"-skærm, der lægger de enkelte begivenheder frem, såsom pauser, variantændringer eller korrektioner. De begivenheder gemmes i en intern registrering i databasen og afspejles i dit Stripe Dashboard (under Subscriptions, Invoices og Events). I appen har du tre steder at arbejde med direkte: medlemskabets nuværende status, listen over dokumenter (Ordrer) og kundens aktivitet, hvor de vigtigste begivenheder er beskrevet i klart sprog (fornyet, betaling mislykkedes, sat på pause eller automatisk sat på pause, genoptaget, opsagt af kunden, opsagt på Stripes side eller ved periodens slut). For den detaljerede rækkefølge af hver enkelt begivenhed skal du kigge i Stripe. Nedenfor beskriver vi de typer begivenheder, systemet registrerer, så de giver mening, når du går på jagt efter dem.
De typer begivenheder, systemet registrerer
Hver intern begivenhed har en type, en dato og ofte nogle ekstra detaljer (et beløb, en årsag, ID'et på den relaterede registrering i Stripe).
Medlemskab oprettet (første køb)
Det første gennemførte køb af et medlemskab dukker op som medlemskabet, der oprettes (status aktivt eller kortvarigt afventer betaling) og som det første dokument i afsnittet Ordrer. Derfra kan du se datoen, den variant kunden valgte, og det første beløb, der blev trukket.
Gennemført fornyelse
Systemet registrerer hver gennemført løbende opkrævning. En fornyelse omfatter:
Dato og tidspunkt for fornyelsen.
Det beløb, der blev trukket.
Den faktureringsperiode, betalingen dækker (du kan spore dette på fakturaen i Stripe).
Det udstedte dokument (en kvittering eller en faktura), som du finder i afsnittet Ordrer.
Bruger kunden en kredit (som for eksempel kan stamme fra en tidligere refundering udstedt som kredit i stedet for tilbage til kortet), og den dækker hele betalingen for perioden, går fornyelsen stadig igennem — Zenamu registrerer den internt, og medlemskabet fortsætter — men der oprettes intet bilag for den. Der blev ikke trukket noget fra kortet, så der er ingenting at dokumentere. Du finder ikke et dokument for den periode i afsnittet Ordrer eller i eksporten til din revisor. Kundens kredit reduceres med prisen for perioden.
Mislykket fornyelse
Systemet registrerer hvert forsøg fra Stripe på at trække en betaling, der ikke lykkedes (Stripes automatiske forsøg, et manuelt forsøg og så videre).
Dato og tidspunkt for forsøget.
Årsagen til fejlen (koden fra banken — manglende dækning, afvist, udløbet kort, verificering påkrævet og så videre).
En enkelt mislykket fornyelse kan generere flere registreringer (Stripe gør et antal forsøg i henstandsperioden). Det bedste sted at spore disse forsøg og deres koder er på fakturaen i dit Stripe Dashboard.
Starten på henstandsperioden er en separat intern begivenhed; derudover dukker datoen, hvor henstandsperioden slutter (typisk 7 dage efter fejlen), op direkte i administrationen, som en del af advarslen om den mislykkede betaling på medlemskabet.
Medlemskab sat på pause
Dette registreres, hver gang et medlemskab sættes på pause. Du kan se, at et medlemskab er sat på pause, direkte fra dets status i administrationen. Der er to tilfælde:
Automatisk pause (fordi studiets abonnement blev nedgraderet). En forklarende bemærkning, der beskriver denne årsag, gemmes med registreringen.
Manuel pause (fra administrationen). Denne gemmes uden en bemærkning — der angives ingen årsag.
Kundens aktivitet skelner også mellem, om medlemskabet blev sat på pause (manuelt) eller blev automatisk sat på pause. Denne forskel er vigtig, fordi den afgør, om medlemskabet fornyes automatisk, når du senere vender tilbage til Ultimate-abonnementet (kun automatisk pausede medlemskaber gør).
Medlemskab genoptaget
Dette registreres, når et pauset medlemskab startes igen. Årsagen skelner mellem, om det var:
"Genoptaget automatisk: studiet skiftede tilbage til Ultimate" — automatisk, efter studiet vendte tilbage til Ultimate-abonnementet.
En manuel genoptagelse fra administrationen eller fra kundens profil.
Variantændring
Oprettes, når en kunde skiftes fra én variant til en anden. I kundens aktivitet mærker appen denne begivenhed Variant skiftet.
Datoen.
Gammel variant → ny variant.
Typen af ændring — en prisstigning, en planlagt prisnedsættelse, en ændring af faktureringsinterval eller samme pris (varianten blev omdøbt og så videre).
Afhængigt af scenariet: ved en prisstigning dukker en øjeblikkelig faktura op for den forholdsmæssige forskel for de resterende dage (næste fornyelsesdato er uændret); ved en planlagt prisnedsættelse oprettes intet dokument på dagen, du skifter — administrationen viser et banner "Planlagt ændring fra {{dato}}" på medlemskabet, og ændringen anvendes kun ved næste fornyelse; ved en ændring af faktureringsinterval genstarter cyklussen, og en enkelt nettofaktura oprettes (den nye pris minus en forholdsmæssig kredit for den ubrugte del af den foregående periode).
Du kan se, hvem der lavede ændringen fra kundens aktivitet i administrationen. Den skelner mellem, om kunden skiftede variant fra sin profil, eller studiet gjorde det fra administrationen (for studiehandlinger gemmes medarbejderens navn også).
Planlagt variantændring annulleret
Når en kunde (eller studiet på vedkommendes vegne) annullerer en tidligere indstillet planlagt variantændring (altid Scenarie B — en prisnedsættelse), forsvinder banneret for den planlagte ændring fra administrationen, og systemet laver en intern bemærkning om annulleringen. Der er ingen økonomiske konsekvenser; medlemskabet vender blot tilbage til sin oprindelige variant uden spor.
Sjældne situationer omkring en planlagt variantændring
Af og til planlægger en kunde en prisnedsættelse, men der sker noget usædvanligt mellem, at den planlægges, og fornyelsesdagen — for eksempel arkiverer studiet målvarianten i mellemtiden eller sletter gruppen. Zenamu håndterer disse situationer automatisk og laver en intern bemærkning om dem.
Hvad der kan ske, og hvad Zenamu gør:
Hvad der skete | Hvad Zenamu gør |
Studiet arkiverede målvarianten før fornyelsen | Ændringen anvendes ikke. Prisen vender tilbage til den oprindelige variant, og kunden fortsætter, som om de aldrig havde planlagt nedsættelsen. |
Studiet slettede målvarianten helt | Samme adfærd som ved arkivering. |
Studiet arkiverede eller slettede hele gruppen | Samme adfærd; kunden bliver på den oprindelige variant. |
Tilbageførsel af prisen lykkes ikke teknisk (f.eks. et kort Stripe-udfald) | Zenamu laver en bemærkning om situationen. Du ser en advarselsstatus på medlemskabet i administrationen. I dette sjældne tilfælde kan du tjekke kundens nuværende abonnementspris i dit Stripe Dashboard og justere den manuelt om nødvendigt. |
Disse situationer er meget sjældne (typisk færre end 1 % af planlagte ændringer). I langt de fleste tilfælde går ændringen igennem præcis, som kunden havde til hensigt, på den dag, de planlagde den.
Pris opdateret
Systemet registrerer, når studiet anvendte en samlet prisændring på denne kunde. Registreringen bærer:
Datoen.
Den gamle og den nye pris.
En bemærkning om, at den nye pris kun gælder ved næste almindelige fornyelse.
Medlemskab opsagt
Dette registreres ved enhver opsigelse — manuel (kunden fra sin profil, studiet fra administrationen eller via Stripes kundeportal) og automatisk (af Zenamu efter den 7-dages henstandsperiode udløber). Du kan se, at et medlemskab er opsagt, direkte fra dets status i administrationen (eller et banner "Opsigelse ved periodens slut" med en dato). Derudover bærer den interne registrering:
Datoen for opsigelsen.
Måden, opsigelsen skete på: enten ved slutningen af den nuværende periode eller med det samme.
Årsagen til opsigelsen (for eksempel en manuel opsigelse ved periodens slut, en øjeblikkelig opsigelse eller en automatisk opsigelse, efter henstandsperioden udløb). Denne beskrivelse er kun til vejledning: den gemmes internt på engelsk og er ikke den nøjagtige tekst, du ville se i appen.
Du kan se, hvem der lavede opsigelsen. Fra både den interne registrering og kundens aktivitet i administrationen kan du se, om kunden, studiet eller systemet opsagde medlemskabet, efter henstandsperioden udløb. For handlinger udført af studiet gemmes medarbejderens navn også. Det, registreringen ikke indeholder, er et link til en eventuel refundering. Det finder du i dit Stripe Dashboard under Refunds.
Bekræftelse af betaling påkrævet og refunderinger — disse dukker op anderledes
Bekræftelse af betaling påkrævet (3D Secure) ved en fornyelse registreres som en intern begivenhed, men medlemskabets status forbliver Aktivt. Når der kræves ekstra verificering ved en fornyelse, skifter Zenamu det ikke til Afventer betaling (den status er forbeholdt et uafsluttet første køb; se artiklen "Medlemskabsstatusser"). Resultatet dukker så op enten som en mislykket fornyelse (gennemfører kunden ikke verificeringen, og Stripe holder op med at forsøge) eller som en gennemført fornyelse (gennemfører de den i tide).
Refunderinger logges ikke som en separat medlemskabsaktivitet. En fuld refundering fører til, at medlemskabet opsiges automatisk; en delvis refundering ændrer ikke medlemskabets status. Du finder selve refunderingens status på dokumentet (afsnittet Ordrer) eller i dit Stripe Dashboard.
Korrektion fra et internt tjek (sjældne begivenheder)
Denne type registrering logger en situation, hvor et internt tjek i Zenamu fandt en uoverensstemmelse mellem sin egen tilstand og tilstanden i Stripe og enten rettede den eller lavede en bemærkning om den til senere håndtering. De konkrete typer er:
Afventende købsordre — kunden købte, Stripe bekræftede det, men Zenamu kunne ikke oprette den interne ordre. Systemet markerer registreringen til at indhente senere.
Afventende fornyelsesordre — det samme, for en fornyelse.
Afventende refundering efter et kapløb — Zenamu opsagde et medlemskab i samme øjeblik, Stripe trak en betaling parallelt. Den automatiske refundering skete ikke med det samme, men den er noteret til at blive håndteret senere.
Afventende variantskift — et variantskift blev ikke afsluttet rent på et tidspunkt.
Besked for et medlemskab, der ikke længere findes — Stripe sendte en besked om et medlemskab, der ikke længere findes i Zenamu (kunden blev slettet).
Det er nogenlunde de fem mest almindelige; Zenamu bruger flere andre specifikke markører til sjældne kapløb (når to ting sker i samme øjeblik). Disse korrektioner kører i baggrunden; en enkelt korrektion er som regel fin i sig selv — problemet er den samme markør, der gentager sig på det samme medlemskab. Står du med en situation som denne, så kontakt support.
Disse korrektioner er informative og dukker op i den forstand, at medlemskabets status i Zenamu ender med at matche Stripe:
En engangskorrektion er fin. Små uoverensstemmelser mellem Stripe og Zenamu sker fra tid til anden.
En gentagen uoverensstemmelse for den samme kunde eller studie kan pege på et dybere problem. Tjek i dit Stripe Dashboard, om din konto er begrænset (under Account requirements), og om alle nylige abonnementer for denne kunde matcher det, du ser i Zenamu. Varer uoverensstemmelsen ved, kan du synkronisere manuelt i Stripe (opsig og opret et nyt abonnement).
Statusopdateringer i realtid
I administrationen opdateres medlemskabsstatussen og listen over ordrer automatisk, i realtid. Det betyder:
Når Stripe sender Zenamu en besked (en gennemført betaling, en fejl, en opsigelse), skifter Zenamu medlemskabsstatussen inden for få sekunder og tilføjer eventuelt nyt dokument.
Studiet ser ændringen uden at skulle genindlæse siden.
En kunde, i sin profil, ser den nuværende status først efter at have genindlæst siden. Kundegrænsefladen bruger som regel ikke opdateringer i realtid. Kontakter en kunde studiet og spørger, hvorfor de ikke ser en ny betaling, så foreslå, at de genindlæser siden. I nogle situationer (lige efter en betaling) tjekker kundens browser kortvarigt statussen i baggrunden, men som tommelfingerregel: genindlæs siden = nuværende status.
I de fleste tilfælde ser begge sider ændringer inden for få sekunder til et minut efter den faktiske begivenhed på Stripes side.
Sådan bruger du et medlemskabs aktivitet i praksis
Kombinationen af medlemskabsstatussen + listen over ordrer i Zenamu og dit Stripe Dashboard er nyttig i flere situationer:
Forklar en bestemt betaling for en kunde
Når en kunde skriver "Hvorfor blev jeg trukket 600 kr. den 14. april?", så åbn afsnittet Ordrer i deres medlemskab, og du ser:
Datoen og betalingsstatussen.
Beløbet.
Et link til dokumentdetaljerne (kvitteringen). Du kan spore den faktureringsperiode, betalingen dækker, på fakturaen i Stripe.
Du kan så svare kunden med de nøjagtige detaljer.
Forstå, hvorfor et medlemskab blev opsagt
Du kan se, at et medlemskab sluttede automatisk efter mislykkede betalinger, fra dets nuværende status (aflyst / ubetalt) og fra den manglende gennemførte betaling i Ordrer. For tidslinjen over de enkelte forsøg og datoen, hvor henstandsperioden sluttede (typisk 7 dage), så kig på det relevante abonnement og fakturaer i dit Stripe Dashboard. Kunden ved så, at de havde en 7-dages henstandsperiode, som de ikke brugte.
Refundér en kunde for en ubrugt periode
I listen over ordrer kan du se datoen for den seneste gennemførte betaling; du kan se, hvor længe medlemskabet er gyldigt, fra medlemskabsstatussen (næste fornyelsesdato). Beregn det forholdsmæssige beløb for de ubrugte dage, og udsted refunderingen i dit Stripe Dashboard.
Spor dobbeltopkrævninger
Hævder en kunde, at Stripe trak dem to gange, så åbn afsnittet Ordrer (og, for en sikkerheds skyld, fakturaerne i Stripe også). Du ser enten kun én betaling (og kunden tager fejl) eller to, og i så fald kan du refundere den ene.
Dokumentation til regnskab
Listen over ordrer matcher dit Stripe Dashboard én til én. Har din revisor brug for bevis for en bestemt betaling, så åbn dokumentdetaljerne (og i Stripe finder du den fulde fakturering, forfaldsdato og skatteoplysninger).
Ofte stillede spørgsmål
En kunde fortæller mig, at de ikke ser deres seneste betaling i deres profil. Et par muligheder:
En kredit dækkede hele betalingen (ingen penge flyttede = intet dokument, se ovenfor).
Kundens profil opdateres ikke i realtid — bed dem prøve at genindlæse siden.
Beskeden fra Stripe var forsinket; vent et minut og genindlæs siden.
Kan jeg eksportere et medlemskabs aktivitet? Til regnskab bruger du den almindelige dokumenteksport i administrationen (ISDOC eller Pohoda XML). Den indeholder alle de fakturaer og aflysninger, din revisor har brug for. Du finder ikke en detaljeret rækkefølge af de enkelte begivenheder (gennemførte og mislykkede fornyelser, pauser, variantskift) som en separat rapport i appen; de data lever i databasen og i dit Stripe Dashboard. I de fleste tilfælde har din revisor ikke brug for dem — de arbejder med dokumenterne.
Kan jeg slette en begivenhedsregistrering? Nej. Regnskabs- og historiske registreringer slettes eller omskrives ikke bagefter; nye tilføjes kun ved siden af dem. Årsagen: historikken skal forblive komplet, både af regnskabshensyn og for at løse tvister.
Hvad hvis jeg ser noget, jeg ikke forventer, i Stripe eller i medlemskabsstatussen (for eksempel resultatet af en korrektion fra et internt tjek)? Det kan være en situation, hvor et internt tjek i Zenamu fandt en uoverensstemmelse mellem sin egen tilstand og tilstanden i Stripe og rettede den. Er det en engangsforeteelse, er det fint (en gang imellem går en besked fra Stripe tabt, og det interne sikkerhedsnet retter op på det). Varer uoverensstemmelsen ved for den samme kunde, så tjek statussen på deres abonnement i dit Stripe Dashboard og sammenlign den med det, du ser i Zenamu. Matcher det virkelig ikke, så kontakt support, eller synkronisér manuelt i Stripe (opsig og opret et nyt abonnement).
Relaterede artikler
Administration af eksisterende medlemmer — alle de handlinger, der genererer interne begivenheder og ændrer et medlemskabs status
Når en betaling mislykkes — detaljerne i, hvad der sker, når en betaling mislykkes, og de relaterede begivenheder
Almindelige problemer, og hvordan du løser dem — sådan håndterer du de konkrete situationer, disse detaljer hjælper dig med at forstå