Varje löpande medlemskap i Zenamu för ett komplett internt register över varje viktig händelse: från det att det skapas, genom varje förnyelse, paus och avbokning, ända fram till eventuella återbetalningar. Det här registret är din fullständiga historik och ditt skyddsnät för att lösa tvister och hantera bokföring. Den här artikeln förklarar var du hittar ett medlemskaps aktivitet och hur du läser varje typ av händelse.
Var du hittar ett medlemskaps aktivitet
Öppna en kunds medlemskapsdetaljer i administrationen så ser du:
Medlemskapets aktuella status (aktivt, pausat, väntar på betalning, avbokat och så vidare), nästa förnyelsedatum och — om något misslyckades — detaljer om respitperioden och den misslyckade betalningen.
Avsnittet Beställningar: en lista över de dokument som utfärdats för det här medlemskapet (skapat-datum, betalt-datum, betalningsstatus, belopp, beskrivning och en länk till dokumentets detaljer). Det här är din huvudsakliga informationskälla om enskilda lyckade betalningar, och den fungerar samtidigt som underlag för din bokföring.
I sin profil (under Mina köpta medlemskap → detaljer) ser kunden samma status och samma lista över sina beställningar.
Viktigt: Zenamu har ännu ingen dedikerad ”Förnyelsehistorik”-skärm som listar enskilda händelser som pauser, variantändringar eller korrigeringar. De händelserna lagras i ett internt register i databasen och speglas i din Stripe Dashboard (under Subscriptions, Invoices och Events). I appen har du tre ställen att arbeta direkt med: medlemskapets aktuella status, listan över dokument (Beställningar) och kundens aktivitet, där de viktigaste händelserna beskrivs i klartext (förnyat, betalning misslyckades, pausat eller automatiskt pausat, återupptaget, avbokat av kunden, avbokat på Stripes sida eller vid periodens slut). För den detaljerade följden av varje enskild händelse, titta i Stripe. Nedan beskriver vi de typer av händelser systemet registrerar, så att de blir begripliga när du går och letar efter dem.
De typer av händelser systemet registrerar
Varje intern händelse har en typ, ett datum och ofta vissa extra detaljer (ett belopp, en orsak, ID:t för den relaterade posten i Stripe).
Medlemskap skapat (första köpet)
Det första lyckade köpet av ett medlemskap visas som att medlemskapet skapas (status aktivt, eller en kort stund väntar på betalning) och som det första dokumentet i avsnittet Beställningar. Av det kan du se datumet, varianten kunden valde och det första debiterade beloppet.
Lyckad förnyelse
Systemet registrerar varje lyckad återkommande debitering. En förnyelse innehåller:
Datum och tid för förnyelsen.
Det debiterade beloppet.
Den faktureringsperiod betalningen täcker (du kan spåra detta på fakturan i Stripe).
Det utfärdade dokumentet (ett kvitto eller en faktura), som du hittar i avsnittet Beställningar.
Om kunden använder en kredit (som kan komma till exempel från en tidigare återbetalning som gjorts som kredit i stället för till kortet) och den täcker hela betalningen för perioden, går förnyelsen ändå igenom — Zenamu registrerar den internt och medlemskapet fortsätter — men inget bokföringsdokument skapas för den. Ingenting debiterades kortet, så det finns inget att dokumentera. Du hittar inget dokument för den perioden i avsnittet Beställningar eller i exporten till din bokförare. Kundens kredit minskas med periodens pris.
Misslyckad förnyelse
Systemet registrerar varje försök från Stripe att dra en betalning som inte lyckades (Stripes automatiska försök, ett manuellt försök och så vidare).
Datum och tid för försöket.
Orsaken till misslyckandet (koden från banken — otillräckliga medel, avvisat, utgånget kort, verifiering krävs och så vidare).
En enda misslyckad förnyelse kan generera flera poster (Stripe gör ett antal försök under respitperioden). Det bästa stället att spåra de här försöken och deras koder är på fakturan i din Stripe Dashboard.
Starten på respitperioden är en separat intern händelse; utöver det visas datumet då respitperioden tar slut (vanligtvis 7 dagar efter misslyckandet) direkt i administrationen, som en del av varningen om misslyckad betalning på medlemskapet.
Medlemskap pausat
Det här registreras närhelst ett medlemskap pausas. Du ser att ett medlemskap är pausat direkt från dess status i administrationen. Det finns två fall:
Automatisk paus (eftersom studions plan nedgraderades). En förklarande notering som beskriver den här orsaken sparas med posten.
Manuell paus (från administrationen). Den här sparas utan en notering — ingen orsak anges.
Kundens aktivitet skiljer också på om medlemskapet pausades (manuellt) eller pausades automatiskt. Den här skillnaden är viktig, eftersom den avgör om medlemskapet förnyas automatiskt när du senare återgår till Ultimate-planen (bara automatiskt pausade medlemskap gör det).
Medlemskap återupptaget
Det här registreras när ett pausat medlemskap startas igen. Orsaken skiljer på om det var:
”Återupptaget automatiskt: studion bytte tillbaka till Ultimate” — automatiskt, efter att studion återgick till Ultimate-planen.
En manuell återupptagning från administrationen eller från kundens profil.
Variantändring
Skapas när en kund byts från en variant till en annan. I kundens aktivitet märker appen den här händelsen Variant bytt.
Datumet.
Gammal variant → ny variant.
Typen av ändring — en prishöjning, en schemalagd prissänkning, ett byte av faktureringsintervall, eller samma pris (varianten döptes om och så vidare).
Beroende på scenariot: vid en prishöjning visas en omedelbar faktura för den proportionella mellanskillnaden för de återstående dagarna (nästa förnyelsedatum förblir detsamma); vid en schemalagd prissänkning skapas inget dokument på dagen du byter — administrationen visar en banner ”Schemalagd ändring från {datum}” på medlemskapet, och ändringen tillämpas bara vid nästa förnyelse; vid ett byte av faktureringsintervall startar cykeln om och en enda nettofaktura skapas (det nya priset minus en proportionell kredit för den oanvända delen av den föregående perioden).
Du kan se vem som gjorde ändringen från kundens aktivitet i administrationen. Den skiljer på om kunden bytte varianten från sin profil eller om studion gjorde det från administrationen (för studions åtgärder sparas även medarbetarens namn).
Schemalagd variantändring avbruten
När en kund (eller studion för hens räkning) avbryter en tidigare inställd schemalagd variantändring (alltid Scenario B — en prissänkning) försvinner bannern för den schemalagda ändringen från administrationen och systemet gör en intern notering om avbrytandet. Det finns inga ekonomiska följder; medlemskapet återgår helt enkelt till sin ursprungliga variant utan ett spår.
Sällsynta situationer kring en schemalagd variantändring
Då och då schemalägger en kund en prissänkning, men något ovanligt händer mellan att hen schemalägger den och förnyelsedagen — till exempel att studion arkiverar målvarianten under tiden, eller raderar gruppen. Zenamu hanterar de här situationerna automatiskt och gör en intern notering om dem.
Vad som kan hända och vad Zenamu gör:
Vad som hände | Vad Zenamu gör |
Studion arkiverade målvarianten före förnyelsen | Ändringen tillämpas inte. Priset återgår till den ursprungliga varianten, och kunden fortsätter som om hen aldrig schemalagt sänkningen. |
Studion raderade målvarianten helt | Samma beteende som vid arkivering. |
Studion arkiverade eller raderade hela gruppen | Samma beteende; kunden stannar på den ursprungliga varianten. |
Att återställa priset lyckas inte tekniskt (t.ex. ett kort avbrott hos Stripe) | Zenamu gör en notering om situationen. Du ser en varningsstatus på medlemskapet i administrationen. I det här sällsynta fallet kan du kontrollera kundens aktuella prenumerationspris i din Stripe Dashboard och justera det manuellt vid behov. |
De här situationerna är mycket sällsynta (vanligtvis färre än 1 % av schemalagda ändringar). I de allra flesta fall går ändringen igenom precis som kunden avsåg på dagen hen schemalade den.
Pris uppdaterat
Systemet registrerar när studion tillämpade en massändring av priset på den här kunden. Posten innehåller:
Datumet.
Det gamla och det nya priset.
En notering om att det nya priset bara gäller vid nästa vanliga förnyelse.
Medlemskap avbokat
Det här registreras vid varje avbokning — manuell (kunden från sin profil, studion från administrationen, eller via Stripes kundportal) och automatisk (av Zenamu efter att den 7-dagars respitperioden tagit slut). Du ser att ett medlemskap är avbokat direkt från dess status i administrationen (eller en banner ”Uppsägning vid periodens slut” med ett datum). Utöver det innehåller den interna posten:
Datumet för avbokningen.
Sättet för avbokningen: antingen vid slutet av den nuvarande perioden, eller omedelbart.
Orsaken till avbokningen (till exempel en manuell avbokning vid periodens slut, en omedelbar avbokning, eller en automatisk avbokning efter att respitperioden tagit slut). Den här beskrivningen är bara vägledande: den lagras internt på engelska och är inte den exakta text du skulle se i appen.
Du kan se vem som gjorde avbokningen. Från både den interna posten och kundens aktivitet i administrationen kan du avgöra om kunden, studion eller systemet avbokade medlemskapet efter att respitperioden tagit slut. För åtgärder som studion tar sparas även medarbetarens namn. Vad posten inte innehåller är en länk till någon återbetalning. Den hittar du i din Stripe Dashboard under Refunds.
Bekräftelse av betalning krävs, och återbetalningar — de visas på olika sätt
Bekräftelse av betalning krävs (3D Secure) vid en förnyelse registreras som en intern händelse, men medlemskapets status förblir Aktivt. När extra verifiering behövs vid en förnyelse växlar Zenamu inte till Väntar på betalning (den statusen är reserverad för ett oavslutat första köp; se artikeln ”Medlemskapsstatusar”). Utfallet visas sedan antingen som en misslyckad förnyelse (om kunden inte slutför verifieringen och Stripe slutar försöka) eller som en lyckad förnyelse (om hen slutför den i tid).
Återbetalningar loggas inte som en separat medlemskapsaktivitet. En full återbetalning leder till att medlemskapet avbokas automatiskt; en delvis återbetalning ändrar inte medlemskapets status. Du hittar statusen för själva återbetalningen på dokumentet (avsnittet Beställningar) eller i din Stripe Dashboard.
Korrigering från en intern kontroll (sällsynta händelser)
Den här typen av post loggar en situation där en intern kontroll i Zenamu fann en avvikelse mellan sitt eget tillstånd och tillståndet i Stripe och antingen rättade den eller gjorde en notering om den för att hantera senare. De specifika typerna är:
Väntande köpbeställning — kunden köpte, Stripe bekräftade det, men Zenamu kunde inte skapa den interna beställningen. Systemet flaggar posten för att hinna ikapp senare.
Väntande förnyelsebeställning — samma sak, för en förnyelse.
Väntande återbetalning efter en kapplöpning — Zenamu avbokade ett medlemskap i precis det ögonblick Stripe drog en betalning parallellt. Den automatiska återbetalningen skedde inte direkt, men den är noterad för att hanteras senare.
Väntande variantbyte — ett variantbyte slutfördes inte rent i något skede.
Meddelande för ett medlemskap som inte längre finns — Stripe skickade ett meddelande om ett medlemskap som inte längre finns i Zenamu (kunden raderades).
Det här är ungefär de fem vanligaste; Zenamu använder flera andra specifika markörer för sällsynta kapplöpningar (när två saker händer i samma ögonblick). De här korrigeringarna körs i bakgrunden; en enskild korrigering är oftast okej i sig — problemet är samma markör som upprepas på samma medlemskap. Om du har att göra med en situation som den här, kontakta supporten.
De här korrigeringarna är informativa och visar sig i den meningen att medlemskapets status i Zenamu till slut matchar Stripe:
En engångskorrigering är okej. Små avvikelser mellan Stripe och Zenamu händer då och då.
En upprepad avvikelse för samma kund eller studio kan peka på ett djupare problem. I din Stripe Dashboard, kontrollera om ditt konto är begränsat (under Account requirements) och om alla nyligen gjorda prenumerationer för den här kunden matchar vad du ser i Zenamu. Om avvikelsen kvarstår kan du synkronisera om manuellt i Stripe (avboka och skapa en ny prenumeration).
Statusuppdateringar i realtid
I administrationen uppdateras medlemskapsstatusen och listan över beställningar automatiskt, i realtid. Det betyder:
När Stripe skickar Zenamu ett meddelande (en lyckad betalning, ett misslyckande, en avbokning) växlar Zenamu medlemskapsstatusen inom några sekunder och lägger till eventuellt nytt dokument.
Studion ser ändringen utan att behöva ladda om sidan.
En kund, i sin profil, ser den aktuella statusen först efter att hen laddat om sidan. Kundgränssnittet använder i regel inte uppdateringar i realtid. Om en kund kontaktar studion och frågar varför hen inte ser en ny betalning, föreslå att hen laddar om sidan. I vissa situationer (precis efter en betalning) kollar kundens webbläsare kort statusen i bakgrunden, men som regel: ladda om sidan = aktuell status.
I de flesta fall ser båda sidor ändringar inom några sekunder till en minut efter den faktiska händelsen på Stripes sida.
Så använder du ett medlemskaps aktivitet i praktiken
Kombinationen av medlemskapsstatusen + listan över beställningar i Zenamu och din Stripe Dashboard är användbar i flera situationer:
Förklara en specifik betalning för en kund
När en kund skriver ”Varför debiterades jag 600 kr den 14 april?”, öppna avsnittet Beställningar i hens medlemskap så ser du:
Datum och betalningsstatus.
Beloppet.
En länk till dokumentets detaljer (kvittot). Du kan spåra den faktureringsperiod betalningen täcker på fakturan i Stripe.
Du kan sedan svara kunden med de exakta detaljerna.
Förstå varför ett medlemskap avbokades
Du kan se att ett medlemskap avslutades automatiskt efter misslyckade betalningar från dess aktuella status (avbokat / obetalt) och från den saknade lyckade betalningen i Beställningar. För tidslinjen över de enskilda försöken och datumet då respitperioden tog slut (vanligtvis 7 dagar), titta på den aktuella prenumerationen och fakturorna i din Stripe Dashboard. Kunden vet då att hen hade en 7-dagars respitperiod som hen inte använde.
Återbetala en kund för en oanvänd period
I listan över beställningar ser du datumet för den senaste lyckade betalningen; du ser hur länge medlemskapet är giltigt från medlemskapsstatusen (nästa förnyelsedatum). Räkna ut det proportionella beloppet för de oanvända dagarna och gör återbetalningen i din Stripe Dashboard.
Spåra dubbla debiteringar
Om en kund hävdar att Stripe debiterade hen två gånger, öppna avsnittet Beställningar (och, för säkerhets skull, fakturorna i Stripe också). Du ser antingen bara en betalning (och kunden har fel) eller två, och då kan du återbetala en av dem.
Underlag för bokföring
Listan över beställningar matchar din Stripe Dashboard ett till ett. Om din bokförare behöver bevis på en specifik betalning, öppna dokumentets detaljer (och i Stripe hittar du den fullständiga faktureringen, förfallodatumet och skatteuppgifterna).
Vanliga frågor
En kund säger att hen inte ser sin senaste betalning i sin profil. Några möjligheter:
En kredit täckte hela betalningen (inga pengar rörde sig = inget dokument, se ovan).
Kundens profil uppdateras inte i realtid — be hen prova att ladda om sidan.
Meddelandet från Stripe var fördröjt; vänta en minut och ladda om sidan.
Kan jag exportera ett medlemskaps aktivitet? För bokföring, använd den vanliga dokumentexporten i administrationen (ISDOC eller Pohoda XML). Den innehåller alla fakturor och avbokningar din bokförare behöver. Du hittar ingen detaljerad följd av enskilda händelser (lyckade och misslyckade förnyelser, pauser, variantbyten) som en separat rapport i appen; den datan lever i databasen och i din Stripe Dashboard. I de flesta fall behöver din bokförare den inte — de arbetar med dokumenten.
Kan jag radera en händelsepost? Nej. Bokförings- och historiska poster raderas eller skrivs inte om i efterhand; nya läggs bara till vid sidan av dem. Orsaken: historiken måste förbli komplett, både för bokföringsändamål och för att lösa tvister.
Vad händer om jag ser något jag inte väntar mig i Stripe eller i medlemskapsstatusen (till exempel resultatet av en korrigering från en intern kontroll)? Det kan vara en situation där en intern kontroll i Zenamu fann en avvikelse mellan sitt eget tillstånd och tillståndet i Stripe och rättade den. Om det är en engångsföreteelse är det okej (då och då går ett meddelande från Stripe förlorat, och det interna skyddsnätet ställer det till rätta). Om avvikelsen kvarstår för samma kund, kontrollera statusen för hens prenumeration i din Stripe Dashboard och jämför den med vad du ser i Zenamu. Om den verkligen inte stämmer, kontakta supporten, eller synkronisera om manuellt i Stripe (avboka och skapa en ny prenumeration).
Relaterade artiklar
Hantera befintliga medlemmar — alla åtgärder som genererar interna händelser och ändrar ett medlemskaps status
När en betalning misslyckas — detaljerna om vad som händer när en betalning misslyckas och de relaterade händelserna
Vanliga problem och hur du löser dem — hur du hanterar de specifika situationer som de här detaljerna hjälper dig att förstå