Jede fortlaufende Mitgliedschaft in Zenamu führt einen vollständigen internen Datensatz über jedes wichtige Ereignis: vom Moment der Erstellung über jede Verlängerung, Pause und Kündigung bis zu etwaigen Rückerstattungen. Dieser Datensatz ist Ihre vollständige Historie und Ihr Sicherheitsnetz, um Streitfälle zu klären und die Buchhaltung zu erledigen. Dieser Artikel erklärt, wo Sie die Aktivität einer Mitgliedschaft finden und wie Sie jeden Ereignistyp lesen.
Wo Sie die Aktivität einer Mitgliedschaft finden
Öffnen Sie die Mitgliedschaftsdetails eines Kunden im Admin-Bereich und Sie sehen:
Den aktuellen Status der Mitgliedschaft (aktiv, pausiert, wartet auf Zahlung, gekündigt und so weiter), das nächste Verlängerungsdatum und — falls etwas fehlgeschlagen ist — Details zur Karenzzeit und zur fehlgeschlagenen Zahlung.
Den Bereich Bestellungen: eine Liste der für diese Mitgliedschaft ausgestellten Belege (Erstellungsdatum, Zahlungsdatum, Zahlungsstatus, Betrag, Beschreibung und ein Link zum Belegdetail). Das ist Ihre Hauptinformationsquelle zu einzelnen erfolgreichen Zahlungen und zugleich die Grundlage für Ihre Buchhaltung.
In seinem Profil (unter Meine Mitgliedschaften → Detail) sieht der Kunde denselben Status und dieselbe Liste seiner Bestellungen.
Wichtig: Zenamu hat noch keine eigene Ansicht „Verlängerungshistorie“, die einzelne Ereignisse wie Pausen, Variantenwechsel oder Korrekturen ausführt. Diese Ereignisse werden in einem internen Datensatz in der Datenbank gespeichert und in Ihrem Stripe-Dashboard gespiegelt (unter Subscriptions, Invoices und Events). In der App haben Sie drei Stellen, mit denen Sie direkt arbeiten: den aktuellen Status der Mitgliedschaft, die Liste der Belege (Bestellungen) und die Aktivität des Kunden, in der die wichtigsten Ereignisse in einfacher Sprache beschrieben sind (verlängert, Zahlung fehlgeschlagen, pausiert oder automatisch pausiert, fortgesetzt, vom Kunden gekündigt, aufseiten von Stripe oder zum Periodenende gekündigt). Für die detaillierte Abfolge jedes einzelnen Ereignisses schauen Sie in Stripe. Unten beschreiben wir die Ereignistypen, die das System erfasst, damit sie Sinn ergeben, wenn Sie danach suchen.
Die Ereignistypen, die das System erfasst
Jedes interne Ereignis hat einen Typ, ein Datum und oft einige Zusatzdetails (einen Betrag, einen Grund, die ID des zugehörigen Datensatzes in Stripe).
Mitgliedschaft erstellt (Erstkauf)
Der erste erfolgreiche Kauf einer Mitgliedschaft erscheint als Erstellung der Mitgliedschaft (Status aktiv oder kurz wartet auf Zahlung) und als erster Beleg im Bereich Bestellungen. Daraus sehen Sie das Datum, die vom Kunden gewählte Variante und den ersten abgebuchten Betrag.
Erfolgreiche Verlängerung
Das System erfasst jede erfolgreiche wiederkehrende Abbuchung. Eine Verlängerung umfasst:
Datum und Uhrzeit der Verlängerung.
Den abgebuchten Betrag.
Den Abrechnungszeitraum, den die Zahlung abdeckt (das können Sie auf der Rechnung in Stripe nachverfolgen).
Den ausgestellten Beleg (einen Zahlungsbeleg oder eine Rechnung), den Sie im Bereich Bestellungen finden.
Nutzt der Kunde ein Guthaben (das zum Beispiel aus einer früheren, als Guthaben statt auf die Karte ausgegebenen Rückerstattung stammen kann) und deckt es die gesamte Zahlung für den Zeitraum, geht die Verlängerung trotzdem durch — Zenamu erfasst sie intern und die Mitgliedschaft läuft weiter — aber es wird kein Buchhaltungsbeleg dafür erstellt. Es wurde nichts von der Karte abgebucht, es gibt also nichts zu belegen. Für diesen Zeitraum finden Sie weder im Bereich Bestellungen noch im Export für Ihren Buchhalter einen Beleg. Das Guthaben des Kunden wird um den Preis des Zeitraums reduziert.
Fehlgeschlagene Verlängerung
Das System erfasst jeden Versuch von Stripe, eine Zahlung abzubuchen, der nicht erfolgreich war (Stripes automatische Wiederholungen, eine manuelle Wiederholung und so weiter).
Datum und Uhrzeit des Versuchs.
Den Grund des Fehlschlags (der Code der Bank — unzureichende Deckung, abgelehnt, abgelaufene Karte, Bestätigung erforderlich und so weiter).
Eine einzelne fehlgeschlagene Verlängerung kann mehrere Einträge erzeugen (Stripe unternimmt während der Karenzzeit mehrere Versuche). Am besten verfolgen Sie diese Versuche und ihre Codes auf der Rechnung in Ihrem Stripe-Dashboard.
Der Beginn der Karenzzeit ist ein eigenes internes Ereignis; darüber hinaus erscheint das Datum, an dem die Karenzzeit endet (typischerweise 7 Tage nach dem Fehlschlag), direkt im Admin-Bereich, als Teil der Warnung über die fehlgeschlagene Zahlung bei der Mitgliedschaft.
Mitgliedschaft pausiert
Das wird erfasst, wann immer eine Mitgliedschaft pausiert wird. Dass eine Mitgliedschaft pausiert ist, sehen Sie direkt an ihrem Status im Admin-Bereich. Es gibt zwei Fälle:
Automatische Pause (weil der Tarif des Studios herabgestuft wurde). Ein erklärender Vermerk zu diesem Grund wird mit dem Eintrag gespeichert.
Manuelle Pause (aus dem Admin-Bereich). Diese wird ohne Vermerk gespeichert — es wird kein Grund eingetragen.
Die Aktivität des Kunden unterscheidet ebenfalls, ob die Mitgliedschaft pausiert wurde (manuell) oder automatisch pausiert wurde. Dieser Unterschied ist wichtig, denn er bestimmt, ob die Mitgliedschaft automatisch wieder verlängert wird, wenn Sie später zum Ultimate-Tarif zurückkehren (nur automatisch pausierte Mitgliedschaften tun das).
Mitgliedschaft fortgesetzt
Das wird erfasst, wenn eine pausierte Mitgliedschaft wieder gestartet wird. Der Grund unterscheidet, ob es war:
„Automatisch fortgesetzt: Das Studio ist zu Ultimate zurückgekehrt“ — automatisch, nachdem das Studio zum Ultimate-Tarif zurückgekehrt ist.
Ein manuelles Fortsetzen aus dem Admin-Bereich oder aus dem Profil des Kunden.
Variantenwechsel
Wird erstellt, wenn ein Kunde von einer Variante zu einer anderen gewechselt wird. In der Aktivität des Kunden kennzeichnet die App dieses Ereignis als Variante gewechselt.
Das Datum.
Alte Variante → neue Variante.
Die Art der Änderung — eine Preiserhöhung, eine geplante Preissenkung, eine Änderung des Abrechnungsintervalls oder der gleiche Preis (die Variante wurde umbenannt und so weiter).
Je nach Szenario: Bei einer Preiserhöhung erscheint sofort eine Rechnung über die anteilige Differenz für die verbleibenden Tage (das nächste Verlängerungsdatum bleibt gleich); bei einer geplanten Preissenkung wird am Tag des Wechsels kein Beleg erstellt — der Admin-Bereich zeigt bei der Mitgliedschaft ein Banner „Geplante Änderung ab {{Datum}}“, und die Änderung wird erst bei der nächsten Verlängerung wirksam; bei einer Änderung des Abrechnungsintervalls beginnt der Zyklus neu und es wird eine einzige Nettorechnung erstellt (der neue Preis abzüglich eines anteiligen Guthabens für den ungenutzten Teil des bisherigen Zeitraums).
Sie sehen, wer die Änderung vorgenommen hat, in der Aktivität des Kunden im Admin-Bereich. Sie unterscheidet, ob der Kunde die Variante aus seinem Profil gewechselt hat oder das Studio es aus dem Admin-Bereich getan hat (bei Studio-Aktionen wird auch der Name des Mitarbeiters gespeichert).
Geplante Variantenänderung abgebrochen
Bricht ein Kunde (oder das Studio in seinem Namen) eine zuvor festgelegte geplante Variantenänderung ab (immer Szenario B — eine Preissenkung), verschwindet das Banner zur geplanten Änderung aus dem Admin-Bereich und das System macht einen internen Vermerk zum Abbruch. Es gibt keine finanziellen Folgen; die Mitgliedschaft kehrt einfach ohne Spur zu ihrer ursprünglichen Variante zurück.
Seltene Situationen rund um eine geplante Variantenänderung
Gelegentlich plant ein Kunde eine Preissenkung ein, aber zwischen dem Einplanen und dem Verlängerungstag passiert etwas Ungewöhnliches — zum Beispiel archiviert das Studio in der Zwischenzeit die Zielvariante oder löscht die Gruppe. Zenamu handhabt diese Situationen automatisch und macht einen internen Vermerk dazu.
Was passieren kann und was Zenamu tut:
Was passiert ist | Was Zenamu tut |
Das Studio hat die Zielvariante vor der Verlängerung archiviert | Die Änderung wird nicht angewendet. Der Preis kehrt zur ursprünglichen Variante zurück, und der Kunde macht weiter, als hätte er die Senkung nie eingeplant. |
Das Studio hat die Zielvariante vollständig gelöscht | Gleiches Verhalten wie beim Archivieren. |
Das Studio hat die ganze Gruppe archiviert oder gelöscht | Gleiches Verhalten; der Kunde bleibt bei der ursprünglichen Variante. |
Das Zurücksetzen des Preises gelingt technisch nicht (z. B. eine kurze Stripe-Störung) | Zenamu macht einen Vermerk zur Situation. Sie sehen bei der Mitgliedschaft im Admin-Bereich einen Warnstatus. In diesem seltenen Fall können Sie den aktuellen Abonnementpreis des Kunden in Ihrem Stripe-Dashboard prüfen und ihn bei Bedarf manuell anpassen. |
Diese Situationen sind sehr selten (typischerweise weniger als 1 % der geplanten Änderungen). In der überwiegenden Mehrheit der Fälle geht die Änderung genau so durch, wie der Kunde es am Tag des Einplanens beabsichtigt hat.
Preis aktualisiert
Das System erfasst, wenn das Studio eine gesammelte Preisänderung auf diesen Kunden angewendet hat. Der Eintrag trägt:
Das Datum.
Den alten und den neuen Preis.
Einen Vermerk, dass der neue Preis erst bei der nächsten regulären Verlängerung gilt.
Mitgliedschaft gekündigt
Das wird bei jeder Kündigung erfasst — manuell (der Kunde aus seinem Profil, das Studio aus dem Admin-Bereich oder über das Stripe-Kundenportal) und automatisch (durch Zenamu nach Ablauf der 7-tägigen Karenzzeit). Dass eine Mitgliedschaft gekündigt ist, sehen Sie direkt an ihrem Status im Admin-Bereich (oder an einem Banner „Kündigung zum Periodenende“ mit einem Datum). Darüber hinaus trägt der interne Eintrag:
Das Datum der Kündigung.
Die Art der Kündigung: entweder zum Ende des aktuellen Zeitraums oder sofort.
Den Grund der Kündigung (zum Beispiel eine manuelle Kündigung zum Periodenende, eine sofortige Kündigung oder eine automatische Kündigung nach Ablauf der Karenzzeit). Diese Beschreibung dient nur zur Orientierung: Sie wird intern auf Englisch gespeichert und ist nicht der genaue Text, den Sie in der App sehen würden.
Sie sehen, wer die Kündigung vorgenommen hat. Sowohl aus dem internen Eintrag als auch aus der Aktivität des Kunden im Admin-Bereich können Sie erkennen, ob der Kunde, das Studio oder das System die Mitgliedschaft nach Ablauf der Karenzzeit gekündigt hat. Bei Aktionen des Studios wird auch der Name des Mitarbeiters gespeichert. Was der Eintrag nicht enthält, ist ein Link zu einer etwaigen Rückerstattung. Diese finden Sie in Ihrem Stripe-Dashboard unter Refunds.
Zahlungsbestätigung erforderlich und Rückerstattungen — diese erscheinen anders
Zahlungsbestätigung erforderlich (3D Secure) bei einer Verlängerung wird als internes Ereignis erfasst, aber der Status der Mitgliedschaft bleibt aktiv. Ist bei einer Verlängerung eine zusätzliche Bestätigung nötig, wechselt Zenamu sie nicht zu wartet auf Zahlung (dieser Status ist einem nicht abgeschlossenen Erstkauf vorbehalten; siehe den Artikel „Status der Mitgliedschaft“). Das Ergebnis erscheint dann entweder als fehlgeschlagene Verlängerung (wenn der Kunde die Bestätigung nicht abschließt und Stripe aufhört, es zu versuchen) oder als erfolgreiche Verlängerung (wenn er sie rechtzeitig abschließt).
Rückerstattungen werden nicht als eigene Mitgliedschaftsaktivität protokolliert. Eine vollständige Rückerstattung führt dazu, dass die Mitgliedschaft automatisch gekündigt wird; eine Teilrückerstattung ändert den Status der Mitgliedschaft nicht. Den Status der Rückerstattung selbst finden Sie auf dem Beleg (Bereich Bestellungen) oder in Ihrem Stripe-Dashboard.
Korrektur aus einer internen Prüfung (seltene Ereignisse)
Dieser Eintragstyp protokolliert eine Situation, in der eine interne Prüfung in Zenamu eine Abweichung zwischen dem eigenen Zustand und dem Zustand in Stripe gefunden und sie entweder korrigiert oder zur späteren Behandlung vermerkt hat. Die konkreten Typen sind:
Ausstehende Kaufbestellung — der Kunde hat gekauft, Stripe hat es bestätigt, aber Zenamu konnte die interne Bestellung nicht erstellen. Das System markiert den Eintrag, um später nachzuziehen.
Ausstehende Verlängerungsbestellung — dasselbe, für eine Verlängerung.
Ausstehende Rückerstattung nach einem Wettlauf — Zenamu hat eine Mitgliedschaft genau in dem Moment gekündigt, in dem Stripe parallel eine Zahlung eingezogen hat. Die automatische Rückerstattung erfolgte nicht sofort, ist aber zur späteren Behandlung vermerkt.
Ausstehender Variantenwechsel — ein Variantenwechsel wurde an irgendeiner Stelle nicht sauber abgeschlossen.
Meldung für eine nicht mehr existierende Mitgliedschaft — Stripe hat eine Meldung über eine Mitgliedschaft gesendet, die in Zenamu nicht mehr existiert (der Kunde wurde gelöscht).
Das sind ungefähr die fünf häufigsten; Zenamu nutzt mehrere weitere spezifische Markierungen für seltene Wettläufe (wenn zwei Dinge im selben Moment passieren). Diese Korrekturen laufen im Hintergrund; eine einzelne Korrektur ist meist für sich genommen unproblematisch — das Problem ist dieselbe Markierung, die sich bei derselben Mitgliedschaft wiederholt. Haben Sie eine solche Situation, wenden Sie sich an den Support.
Diese Korrekturen sind informativ und zeigen sich darin, dass der Status der Mitgliedschaft in Zenamu am Ende mit Stripe übereinstimmt:
Eine einmalige Korrektur ist unproblematisch. Kleine Abweichungen zwischen Stripe und Zenamu kommen von Zeit zu Zeit vor.
Eine wiederholte Abweichung bei demselben Kunden oder Studio kann auf ein tieferes Problem hindeuten. Prüfen Sie in Ihrem Stripe-Dashboard, ob Ihr Konto eingeschränkt ist (unter Account requirements) und ob alle aktuellen Abonnements dieses Kunden mit dem übereinstimmen, was Sie in Zenamu sehen. Hält die Abweichung an, können Sie in Stripe manuell neu synchronisieren (das Abonnement kündigen und ein neues erstellen).
Statusaktualisierungen in Echtzeit
Im Admin-Bereich aktualisieren sich der Status der Mitgliedschaft und die Liste der Bestellungen automatisch, in Echtzeit. Das bedeutet:
Wenn Stripe Zenamu eine Meldung sendet (eine erfolgreiche Zahlung, ein Fehlschlag, eine Kündigung), wechselt Zenamu den Status der Mitgliedschaft innerhalb weniger Sekunden und fügt einen etwaigen neuen Beleg hinzu.
Das Studio sieht die Änderung, ohne die Seite neu laden zu müssen.
Ein Kunde sieht in seinem Profil den aktuellen Status erst nach dem Neuladen der Seite. Die Kundenoberfläche nutzt im Allgemeinen keine Echtzeit-Aktualisierungen. Fragt ein Kunde das Studio, warum er eine neue Zahlung nicht sieht, schlagen Sie ihm vor, die Seite neu zu laden. In manchen Situationen (direkt nach einer Zahlung) prüft der Browser des Kunden den Status kurz im Hintergrund, aber in der Regel gilt: Seite neu laden = aktueller Status.
In den meisten Fällen sehen beide Seiten Änderungen innerhalb weniger Sekunden bis einer Minute nach dem tatsächlichen Ereignis aufseiten von Stripe.
Wie Sie die Aktivität einer Mitgliedschaft in der Praxis nutzen
Die Kombination aus Status der Mitgliedschaft + Liste der Bestellungen in Zenamu und Ihrem Stripe-Dashboard ist in mehreren Situationen hilfreich:
Einem Kunden eine bestimmte Zahlung erklären
Schreibt ein Kunde „Warum wurden mir am 14. April 60 € berechnet?“, öffnen Sie den Bereich Bestellungen bei seiner Mitgliedschaft und Sie sehen:
Das Datum und den Zahlungsstatus.
Den Betrag.
Einen Link zum Belegdetail (dem Zahlungsbeleg). Den Abrechnungszeitraum, den die Zahlung abdeckt, können Sie auf der Rechnung in Stripe nachverfolgen.
Sie können dem Kunden dann mit den genauen Details antworten.
Verstehen, warum eine Mitgliedschaft gekündigt wurde
Dass eine Mitgliedschaft nach fehlgeschlagenen Zahlungen automatisch endete, erkennen Sie an ihrem aktuellen Status (gekündigt / nicht bezahlt) und an der fehlenden erfolgreichen Zahlung in den Bestellungen. Für den zeitlichen Ablauf der einzelnen Versuche und das Datum, an dem die Karenzzeit endete (typischerweise 7 Tage), schauen Sie sich das jeweilige Abonnement und die Rechnungen in Ihrem Stripe-Dashboard an. Der Kunde weiß dann, dass er eine 7-tägige Karenzzeit hatte, die er nicht genutzt hat.
Einem Kunden einen ungenutzten Zeitraum erstatten
In der Liste der Bestellungen sehen Sie das Datum der letzten erfolgreichen Zahlung; wie lange die Mitgliedschaft gültig ist, sehen Sie am Status der Mitgliedschaft (dem nächsten Verlängerungsdatum). Berechnen Sie den anteiligen Betrag für die ungenutzten Tage und veranlassen Sie die Rückerstattung in Ihrem Stripe-Dashboard.
Doppelte Abbuchungen aufspüren
Behauptet ein Kunde, Stripe habe ihn zweimal belastet, öffnen Sie den Bereich Bestellungen (und zur Sicherheit auch die Rechnungen in Stripe). Sie sehen entweder nur eine Zahlung (und der Kunde irrt sich) oder zwei, dann können Sie eine davon erstatten.
Belege für die Buchhaltung
Die Liste der Bestellungen stimmt eins zu eins mit Ihrem Stripe-Dashboard überein. Braucht Ihr Buchhalter einen Nachweis einer bestimmten Zahlung, öffnen Sie das Belegdetail (und in Stripe finden Sie die vollständige Abrechnung, das Fälligkeitsdatum und die Steuerdetails).
Häufig gestellte Fragen
Ein Kunde sagt mir, er sehe seine letzte Zahlung nicht in seinem Profil. Ein paar Möglichkeiten:
Ein Guthaben hat die gesamte Zahlung gedeckt (keine Geldbewegung = kein Beleg, siehe oben).
Das Profil des Kunden aktualisiert sich nicht in Echtzeit — bitten Sie ihn, die Seite neu zu laden.
Die Meldung von Stripe war verzögert; warten Sie eine Minute und laden Sie die Seite neu.
Kann ich die Aktivität einer Mitgliedschaft exportieren? Für die Buchhaltung nutzen Sie den standardmäßigen Belegexport im Admin-Bereich (ISDOC oder Pohoda XML). Er enthält alle Rechnungen und Stornierungen, die Ihr Buchhalter braucht. Eine detaillierte Abfolge einzelner Ereignisse (erfolgreiche und fehlgeschlagene Verlängerungen, Pausen, Variantenwechsel) finden Sie nicht als eigenen Bericht in der App; diese Daten liegen in der Datenbank und in Ihrem Stripe-Dashboard. In den meisten Fällen braucht Ihr Buchhalter sie nicht — er arbeitet mit den Belegen.
Kann ich einen Ereigniseintrag löschen? Nein. Buchhaltungs- und Verlaufsdaten werden nachträglich nicht gelöscht oder umgeschrieben; es werden nur neue daneben hinzugefügt. Der Grund: Die Historie muss vollständig bleiben, sowohl für Buchhaltungszwecke als auch für die Klärung von Streitfällen.
Was, wenn ich in Stripe oder im Status der Mitgliedschaft etwas Unerwartetes sehe (zum Beispiel das Ergebnis einer Korrektur aus einer internen Prüfung)? Es kann eine Situation sein, in der eine interne Prüfung in Zenamu eine Abweichung zwischen dem eigenen Zustand und dem Zustand in Stripe gefunden und sie korrigiert hat. Ist es einmalig, ist es unproblematisch (hin und wieder geht eine Meldung von Stripe verloren, und das interne Sicherheitsnetz richtet es). Hält die Abweichung bei demselben Kunden an, prüfen Sie den Status seines Abonnements in Ihrem Stripe-Dashboard und vergleichen Sie ihn mit dem, was Sie in Zenamu sehen. Passt er wirklich nicht zusammen, wenden Sie sich an den Support oder synchronisieren Sie in Stripe manuell neu (das Abonnement kündigen und ein neues erstellen).
Verwandte Artikel
Bestehende Mitglieder verwalten — alle Aktionen, die interne Ereignisse erzeugen und den Status einer Mitgliedschaft ändern
Wenn eine Zahlung fehlschlägt — die Details, was bei einer fehlgeschlagenen Zahlung passiert, und die zugehörigen Ereignisse
Häufige Probleme und ihre Lösung — wie Sie die konkreten Situationen handhaben, die diese Details verständlich machen
