Hvert løpende medlemskap i Zenamu fører en fullstendig intern oppføring av hver viktig hendelse: fra det øyeblikket det opprettes, gjennom hver fornyelse, pause og avbestilling, helt frem til eventuelle refusjoner. Denne oppføringen er din fullstendige historikk og ditt sikkerhetsnett for å løse tvister og håndtere regnskap. Denne artikkelen forklarer hvor du finner et medlemskaps aktivitet, og hvordan du leser hver type hendelse.
Hvor du finner et medlemskaps aktivitet
Åpne en kundes medlemskapsdetalj i administrasjonen, så ser du:
Medlemskapets nåværende status (aktiv, på pause, venter på betaling, avbestilt og så videre), neste fornyelsesdato, og — hvis noe mislyktes — detaljer om utsettelsesperioden og den mislykkede betalingen.
Seksjonen Ordrer: en liste over dokumentene utstedt for dette medlemskapet (opprettelsesdato, betalingsdato, betalingsstatus, beløp, beskrivelse og en lenke til dokumentdetaljen). Dette er din viktigste informasjonskilde om individuelle vellykkede betalinger, og den fungerer også som grunnlaget for regnskapet ditt.
I profilen sin (under Mine kjøpte medlemskap → detalj) ser kunden den samme statusen og den samme listen over ordrene sine.
Viktig: Zenamu har ennå ikke en dedikert «Fornyelseshistorikk»-skjerm som lister opp individuelle hendelser som pauser, variantendringer eller korreksjoner. Disse hendelsene lagres i en intern oppføring i databasen og speiles i Stripe Dashboard (under Subscriptions, Invoices og Events). I appen har du tre steder å jobbe direkte med: medlemskapets nåværende status, listen over dokumenter (Ordrer), og kundens aktivitet, der hovedhendelsene beskrives i klartekst (fornyet, betaling mislyktes, satt på pause eller automatisk satt på pause, gjenopptatt, avbestilt av kunden, avbestilt på Stripes side eller ved slutten av perioden). For den detaljerte rekkefølgen av hver enkelt hendelse, se i Stripe. Nedenfor beskriver vi hvilke typer hendelser systemet registrerer, så de gir mening når du går og leter etter dem.
Hvilke typer hendelser systemet registrerer
Hver interne hendelse har en type, en dato, og ofte noen ekstra detaljer (et beløp, en årsak, ID-en til den relaterte oppføringen i Stripe).
Medlemskap opprettet (første kjøp)
Det første vellykkede kjøpet av et medlemskap vises som at medlemskapet opprettes (status aktiv, eller kort venter på betaling) og som det første dokumentet i Ordrer-seksjonen. Fra det kan du se datoen, varianten kunden valgte, og det første beløpet som ble trukket.
Vellykket fornyelse
Systemet registrerer hvert vellykket løpende trekk. En fornyelse inkluderer:
Dato og klokkeslett for fornyelsen.
Beløpet som ble trukket.
Faktureringsperioden betalingen dekker (du kan spore dette på fakturaen i Stripe).
Dokumentet som ble utstedt (en kvittering eller en faktura), som du finner i seksjonen Ordrer.
Hvis kunden bruker en kreditt (som kan komme for eksempel fra en tidligere refusjon utstedt som kreditt i stedet for tilbake til kortet) og den dekker hele betalingen for perioden, går fornyelsen fortsatt gjennom — Zenamu registrerer den internt, og medlemskapet fortsetter — men det opprettes ikke noe regnskapsdokument for den. Ingenting ble trukket fra kortet, så det er ingenting å dokumentere. Du finner ikke et dokument for den perioden i Ordrer-seksjonen eller i eksporten for regnskapsføreren din. Kundens kreditt reduseres med prisen for perioden.
Mislykket fornyelse
Systemet registrerer hvert forsøk fra Stripe på å trekke en betaling som ikke lyktes (Stripes automatiske nye forsøk, et manuelt nytt forsøk og så videre).
Dato og klokkeslett for forsøket.
Årsaken til feilen (koden fra banken — utilstrekkelige midler, avvist, utløpt kort, verifisering kreves og så videre).
En enkelt mislykket fornyelse kan generere flere oppføringer (Stripe gjør en rekke forsøk i løpet av utsettelsesperioden). Det beste stedet å spore disse forsøkene og kodene deres er på fakturaen i Stripe Dashboard.
Starten på utsettelsesperioden er en egen intern hendelse; i tillegg vises datoen utsettelsesperioden slutter (typisk 7 dager etter feilen) direkte i administrasjonen, som en del av advarselen om mislykket betaling på medlemskapet.
Medlemskap satt på pause
Dette registreres hver gang et medlemskap settes på pause. Du kan se at et medlemskap er satt på pause direkte fra statusen i administrasjonen. Det er to tilfeller:
Automatisk pause (fordi studioets abonnement ble nedgradert). En forklarende merknad som beskriver denne grunnen, lagres med oppføringen.
Manuell pause (fra administrasjonen). Dette lagres uten en merknad — ingen grunn legges inn.
Kundens aktivitet skiller også mellom om medlemskapet ble satt på pause (manuelt) eller ble automatisk satt på pause. Denne forskjellen er viktig, fordi den avgjør om medlemskapet fornyes automatisk når du senere går tilbake til Ultimate-abonnementet (bare automatisk pausede medlemskap gjør det).
Medlemskap gjenopptatt
Dette registreres når et pauset medlemskap startes på nytt. Årsaken skiller om det var:
«Gjenopptatt automatisk: studioet byttet tilbake til Ultimate» — automatisk, etter at studioet gikk tilbake til Ultimate-abonnementet.
En manuell gjenopptakelse fra administrasjonen eller fra kundens profil.
Variantendring
Opprettes når en kunde byttes fra én variant til en annen. I kundens aktivitet merker appen denne hendelsen Variant byttet.
Datoen.
Gammel variant → ny variant.
Typen endring — en prisøkning, en planlagt prisreduksjon, en endring av faktureringsintervall, eller samme pris (varianten ble omdøpt og så videre).
Avhengig av scenarioet: ved en prisøkning vises en umiddelbar faktura for den forholdsmessige differansen for de gjenværende dagene (neste fornyelsesdato forblir den samme); ved en planlagt prisreduksjon opprettes det ikke noe dokument på dagen du bytter — administrasjonen viser et «Planlagt endring fra {{dato}}»-banner på medlemskapet, og endringen trer i kraft først ved den neste fornyelsen; ved en endring av faktureringsintervall starter syklusen på nytt, og en enkelt nettofaktura opprettes (den nye prisen minus en forholdsmessig kreditt for den ubrukte delen av den forrige perioden).
Du kan se hvem som gjorde endringen fra kundens aktivitet i administrasjonen. Den skiller om kunden byttet varianten fra profilen sin, eller om studioet gjorde det fra administrasjonen (for studiohandlinger lagres også navnet på den ansatte).
Planlagt variantendring avbrutt
Når en kunde (eller studioet på deres vegne) avbryter en tidligere satt planlagt variantendring (alltid Scenario B — en prisreduksjon), forsvinner banneret for den planlagte endringen fra administrasjonen, og systemet gjør en intern merknad om avbestillingen. Det er ingen økonomiske konsekvenser; medlemskapet går ganske enkelt tilbake til sin opprinnelige variant uten spor.
Sjeldne situasjoner rundt en planlagt variantendring
Av og til planlegger en kunde en prisreduksjon, men noe uvanlig skjer mellom det å planlegge den og fornyelsesdagen — for eksempel at studioet arkiverer målvarianten i mellomtiden, eller sletter gruppen. Zenamu håndterer disse situasjonene automatisk og gjør en intern merknad om dem.
Hva som kan skje og hva Zenamu gjør:
Hva som skjedde | Hva Zenamu gjør |
Studioet arkiverte målvarianten før fornyelsen | Endringen brukes ikke. Prisen går tilbake til den opprinnelige varianten, og kunden fortsetter som om de aldri hadde planlagt reduksjonen. |
Studioet slettet målvarianten helt | Samme oppførsel som ved arkivering. |
Studioet arkiverte eller slettet hele gruppen | Samme oppførsel; kunden blir værende på den opprinnelige varianten. |
Å tilbakestille prisen lykkes ikke teknisk (f.eks. et kort Stripe-avbrudd) | Zenamu gjør en merknad om situasjonen. Du ser en advarselsstatus på medlemskapet i administrasjonen. I dette sjeldne tilfellet kan du sjekke kundens nåværende abonnementspris i Stripe Dashboard og justere den manuelt ved behov. |
Disse situasjonene er svært sjeldne (typisk færre enn 1 % av planlagte endringer). I de aller fleste tilfeller går endringen gjennom akkurat slik kunden hadde til hensikt på dagen de planla den.
Pris oppdatert
Systemet registrerer når studioet brukte en prisendring i bulk på denne kunden. Oppføringen inneholder:
Datoen.
Den gamle og den nye prisen.
En merknad om at den nye prisen bare gjelder ved den neste vanlige fornyelsen.
Medlemskap avbestilt
Dette registreres ved enhver avbestilling — manuell (kunden fra profilen sin, studioet fra administrasjonen, eller via Stripe-kundeportalen) og automatisk (av Zenamu etter at den 7-dagers utsettelsesperioden utløper). Du kan se at et medlemskap er avbestilt direkte fra statusen i administrasjonen (eller et «Avbestilling ved periodens slutt»-banner med en dato). I tillegg inneholder den interne oppføringen:
Datoen for avbestillingen.
Måten avbestillingen ble gjort på: enten ved slutten av den nåværende perioden, eller umiddelbart.
Årsaken til avbestillingen (for eksempel en manuell avbestilling ved slutten av perioden, en umiddelbar avbestilling, eller en automatisk avbestilling etter at utsettelsesperioden utløp). Denne beskrivelsen er kun veiledende: den lagres internt på engelsk og er ikke den eksakte teksten du ville sett i appen.
Du kan se hvem som gjorde avbestillingen. Fra både den interne oppføringen og kundens aktivitet i administrasjonen kan du se om kunden, studioet eller systemet avbestilte medlemskapet etter at utsettelsesperioden utløp. For handlinger utført av studioet lagres også navnet på den ansatte. Det oppføringen ikke inkluderer, er en lenke til en eventuell refusjon. Den finner du i Stripe Dashboard under Refunds.
Bekreftelse av betaling kreves, og refusjoner — disse vises forskjellig
Bekreftelse av betaling kreves (3D Secure) på en fornyelse registreres som en intern hendelse, men medlemskapets status forblir Aktiv. Når ekstra verifisering trengs på en fornyelse, bytter Zenamu ikke til Venter på betaling (den statusen er forbeholdt et uavsluttet førstegangskjøp; se artikkelen «Medlemskapsstatuser»). Utfallet vises deretter enten som en mislykket fornyelse (hvis kunden ikke fullfører verifiseringen og Stripe slutter å prøve) eller som en vellykket fornyelse (hvis de fullfører den i tide).
Refusjoner logges ikke som en egen medlemskapsaktivitet. En full refusjon fører til at medlemskapet avbestilles automatisk; en delvis refusjon endrer ikke medlemskapets status. Du finner statusen til selve refusjonen på dokumentet (Ordrer-seksjonen) eller i Stripe Dashboard.
Korreksjon fra en intern sjekk (sjeldne hendelser)
Denne typen oppføring logger en situasjon der en intern sjekk i Zenamu fant et avvik mellom sin egen tilstand og tilstanden i Stripe og enten korrigerte det eller gjorde en merknad om det for å håndtere det senere. De spesifikke typene er:
Ventende kjøpsordre — kunden kjøpte, Stripe bekreftet det, men Zenamu kunne ikke opprette den interne ordren. Systemet flagger oppføringen for å rette det opp senere.
Ventende fornyelsesordre — det samme, for en fornyelse.
Ventende refusjon etter en race — Zenamu avbestilte et medlemskap i akkurat det øyeblikket Stripe trakk en betaling parallelt. Den automatiske refusjonen skjedde ikke med en gang, men den er notert for å håndteres senere.
Ventende variantbytte — et variantbytte ble ikke fullført rent på et eller annet stadium.
Melding for et medlemskap som ikke lenger finnes — Stripe sendte en melding om et medlemskap som ikke lenger finnes i Zenamu (kunden ble slettet).
Dette er omtrent de fem vanligste; Zenamu bruker flere andre spesifikke markører for sjeldne races (når to ting skjer i samme øyeblikk). Disse korreksjonene kjører i bakgrunnen; en enkelt korreksjon er vanligvis greit i seg selv — problemet er den samme markøren som gjentar seg på det samme medlemskapet. Hvis du håndterer en situasjon som dette, kontakt support.
Disse korreksjonene er informative og vises i den forstand at medlemskapets status i Zenamu ender opp med å samsvare med Stripe:
En engangskorreksjon er greit. Små avvik mellom Stripe og Zenamu skjer fra tid til annen.
Et gjentatt avvik for den samme kunden eller studioet kan peke på et dypere problem. I Stripe Dashboard sjekker du om kontoen din er begrenset (under Account requirements) og om alle nylige abonnementer for denne kunden samsvarer med det du ser i Zenamu. Hvis avviket vedvarer, kan du synkronisere på nytt manuelt i Stripe (avbryt og opprett et nytt abonnement).
Statusoppdateringer i sanntid
I administrasjonen oppdateres medlemskapsstatusen og listen over ordrer automatisk, i sanntid. Det betyr:
Når Stripe sender Zenamu en melding (en vellykket betaling, en feil, en avbestilling), bytter Zenamu medlemskapsstatusen i løpet av noen få sekunder og legger til et eventuelt nytt dokument.
Studioet ser endringen uten å måtte oppdatere siden.
En kunde, i profilen sin, ser den nåværende statusen bare etter å ha oppdatert siden. Kundegrensesnittet bruker generelt ikke sanntidsoppdateringer. Hvis en kunde kontakter studioet og spør hvorfor de ikke ser en ny betaling, foreslå at de oppdaterer siden. I noen situasjoner (rett etter en betaling) sjekker kundens nettleser kort statusen i bakgrunnen, men som regel: oppdater siden = nåværende status.
I de fleste tilfeller ser begge sider endringer i løpet av noen få sekunder til et minutt etter den faktiske hendelsen på Stripes side.
Slik bruker du et medlemskaps aktivitet i praksis
Kombinasjonen av medlemskapsstatusen + listen over ordrer i Zenamu og Stripe Dashboard er nyttig i flere situasjoner:
Forklar en bestemt betaling til en kunde
Når en kunde skriver «Hvorfor ble jeg trukket 600 kr den 14. april?», åpne seksjonen Ordrer i medlemskapet deres, så ser du:
Datoen og betalingsstatusen.
Beløpet.
En lenke til dokumentdetaljen (kvitteringen). Du kan spore faktureringsperioden betalingen dekker på fakturaen i Stripe.
Du kan deretter svare kunden med de eksakte detaljene.
Forstå hvorfor et medlemskap ble avbestilt
Du kan se at et medlemskap ble avsluttet automatisk etter mislykkede betalinger fra dets nåværende status (avbestilt / ubetalt) og fra den manglende vellykkede betalingen i Ordrer. For tidslinjen over de individuelle forsøkene og datoen utsettelsesperioden sluttet (typisk 7 dager), se på det relevante abonnementet og fakturaene i Stripe Dashboard. Kunden vet da at de hadde en 7-dagers utsettelsesperiode som de ikke brukte.
Refunder en kunde for en ubrukt periode
I listen over ordrer kan du se datoen for den siste vellykkede betalingen; du kan se hvor lenge medlemskapet er gyldig fra medlemskapsstatusen (neste fornyelsesdato). Regn ut det forholdsmessige beløpet for de ubrukte dagene og utsted refusjonen i Stripe Dashboard.
Spore opp dobbelttrekk
Hvis en kunde hevder at Stripe trakk dem to ganger, åpne seksjonen Ordrer (og, for sikkerhets skyld, fakturaene i Stripe også). Du ser enten bare én betaling (og kunden tar feil) eller to, og i så fall kan du refundere en av dem.
Dokumentasjon for regnskap
Listen over ordrer samsvarer med Stripe Dashboard én til én. Hvis regnskapsføreren din trenger bevis på en bestemt betaling, åpne dokumentdetaljen (og i Stripe finner du hele faktureringen, forfallsdatoen og skattedetaljene).
Ofte stilte spørsmål
En kunde forteller meg at de ikke ser den siste betalingen sin i profilen. Noen muligheter:
En kreditt dekket hele betalingen (ingen penger flyttet = ingen dokument, se ovenfor).
Kundens profil oppdateres ikke i sanntid — be dem prøve å oppdatere siden.
Meldingen fra Stripe var forsinket; vent et minutt og oppdater siden.
Kan jeg eksportere et medlemskaps aktivitet? For regnskap, bruk den vanlige dokumenteksporten i administrasjonen (ISDOC eller Pohoda XML). Den inneholder alle fakturaene og avbestillingene regnskapsføreren din trenger. Du finner ikke en detaljert rekkefølge av individuelle hendelser (vellykkede og mislykkede fornyelser, pauser, variantbytter) som en egen rapport i appen; de dataene ligger i databasen og i Stripe Dashboard. I de fleste tilfeller trenger ikke regnskapsføreren din dem — de jobber med dokumentene.
Kan jeg slette en hendelsesoppføring? Nei. Regnskaps- og historiske oppføringer slettes eller skrives ikke om i etterkant; nye legges bare til ved siden av dem. Grunnen: historikken må forbli fullstendig, både for regnskapsformål og for å løse tvister.
Hva om jeg ser noe jeg ikke forventer i Stripe eller i medlemskapsstatusen (for eksempel resultatet av en korreksjon fra en intern sjekk)? Det kan være en situasjon der en intern sjekk i Zenamu fant et avvik mellom sin egen tilstand og tilstanden i Stripe og korrigerte det. Hvis det er en engangshendelse, er det greit (en gang iblant går en melding fra Stripe tapt, og det interne sikkerhetsnettet retter det opp). Hvis avviket vedvarer for den samme kunden, sjekk statusen til abonnementet deres i Stripe Dashboard og sammenlign den med det du ser i Zenamu. Hvis det virkelig ikke samsvarer, kontakt support, eller synkroniser på nytt manuelt i Stripe (avbryt og opprett et nytt abonnement).
Relaterte artikler
Administrere eksisterende medlemmer — alle handlingene som genererer interne hendelser og endrer et medlemskaps status
Når en betaling mislykkes — detaljene om hva som skjer når en betaling mislykkes og de relaterte hendelsene
Vanlige problemer og hvordan du løser dem — hvordan du håndterer de spesifikke situasjonene disse detaljene hjelper deg å forstå