Was macht Finanz- und Abrechnungsbetrieb?
Verwende diesen Skill, wenn der Benutzer Geld, Preise, Rückerstattungen, Team-Sitzlogik oder verstehen möchte, ob sich das Produkt tatsächlich so verhält, wie es die Website und die Verkaufsunterlagen suggerieren.
Dieser Skill ist umfassender als customer-billing-ops (Kundenabrechnungsbetrieb). Jener Skill ist für die Kundenbetreuung gedacht. Dieser Skill ist für die betriebliche Wahrheit: Umsatzstatus, Preisentscheidungen, Teamabrechnung und codegestütztes Abrechnungsverhalten.
Skill-Stack
Ziehe bei Bedarf diese ECC-nativen Skills in den Arbeitsablauf ein:
customer-billing-opsfür kundenspezifische Betreuung und Nachverfolgungresearch-opswenn Wettbewerbspreise oder aktuelle Marktbelege wichtig sindmarket-researchwenn die Antwort in einer Preisempfehlung enden sollgithub-opswenn die Abrechnungswahrheit von Code, Backlog oder Release-Zustand in benachbarten Repos abhängtverification-loopwenn die Antwort vom Nachweis des Checkout-, Sitzverwaltungs- oder Berechtigungsverhaltens abhängt
Wann verwenden
- Der Benutzer fragt nach Stripe-Verkäufen, Rückerstattungen, MRR oder aktuellen Kundenaktivitäten
- Der Benutzer fragt, ob Teamabrechnung, Pro-Sitz-Abrechnung oder Quotenstapelung im Code real ist
- Der Benutzer wünscht Wettbewerbspreisvergleiche oder Preismodell-Benchmarks
- Die Frage vermischt Umsatzfakten mit der Implementierungswahrheit des Produkts
Leitplanken
- Unterscheide Live-Daten von gespeicherten Schnappschüssen
- Trenne:
- Umsatzfakt
- Kundenauswirkung
- codegestützte Produktwahrheit
- Empfehlung
- Sage nicht „pro Sitz“, es sei denn, der tatsächliche Berechtigungspfad erzwingt dies
- Gehe nicht davon aus, dass doppelte Abonnements doppelten Wert implizieren
Arbeitsablauf
1. Beginne mit dem frischesten Abrechnungsnachweis
Bevorzuge Live-Abrechnungsdaten. Sind die Daten nicht live, gib den Zeitstempel des Schnappschusses explizit an.
Normalisiere das Bild:
- bezahlte Verkäufe
- aktive Abonnements
- fehlgeschlagene oder unvollständige Checkouts
- Rückerstattungen
- Streitfälle
- doppelte Abonnements
2. Trenne Kundenereignisse von der Produktwahrheit
Ist die Frage kundenspezifisch, klassifiziere zuerst:
- doppelter Checkout
- echte Teamabsicht
- defekte Selbstbedienungssteuerung
- unerfüllter Produktwert
- fehlgeschlagene Zahlung oder unvollständige Einrichtung
Trenne dies dann von der übergeordneten Produktfrage:
- existiert Teamabrechnung wirklich?
- werden Sitze tatsächlich gezählt?
- ändert die Checkout-Menge die Berechtigung?
- überzeichnet die Website das aktuelle Verhalten?
3. Überprüfe das codegestützte Abrechnungsverhalten
Hängt die Antwort von der Implementierungswahrheit ab, überprüfe den Codepfad:
- Checkout
- Preisseite
- Berechtigungsberechnung
- Sitz- oder Quotenverwaltung
- Logik zur Installation vs. Benutzernutzung
- Abrechnungsportal oder Selbstbedienungsverwaltung
4. Beende mit einer Entscheidung und einer Produktlücke
Berichte:
- Verkaufsübersicht
- Problemdiagnose
- Produktwahrheit
- empfohlene Betreiberaktion
- Produkt- oder Backlog-Lücke
Ausgabeformat
ÜBERSICHT
- Zeitstempel
- Umsatz / Abonnements / Anomalien
KUNDENAUSWIRKUNG
- wer ist betroffen
- was ist passiert
PRODUKTWAHRHEIT
- was der Code tatsächlich tut
- was die Website oder die Verkaufsunterlagen behaupten
ENTSCHEDUNG
- Rückerstattung / Erhalten / Konvertieren / Keine Aktion
PRODUKTLÜCKE
- genauer Folgepunkt zum Bauen oder Beheben
Fallstricke
- Vermische fehlgeschlagene Versuche nicht mit Nettoumsatz
- Leite Teamabrechnung nicht allein aus Marketingtexten ab
- Vergleiche Wettbewerbspreise nicht aus dem Gedächtnis, wenn aktuelle Belege verfügbar sind
- Springe nicht von der Diagnose direkt zur Rückerstattung, ohne das Problem zu klassifizieren
Verifikation
- Die Antwort enthält eine Live-Daten-Angabe oder einen Schnappschuss-Zeitstempel
- Behauptungen zur Produktwahrheit sind codegestützt
- Kundenauswirkungen und übergeordnete Preis-/Produktschlussfolgerungen sind sauber getrennt