Funktionen des Zusagen-Registers
The Customer Success Manager ist eine Software, die Kundenzusagen nachverfolgt. Diese Seite zeigt, was sie heute kann, welche Daten jede Funktion speichert und wie das in der Praxis aussieht. Die App-Oberfläche ist auf Englisch, die Seitennamen wie Settings oder Agent Setup nennen wir deshalb im Original.
Kunden-Accounts
Jede Zusage gehört zu einem Kunden-Account. Ein Account hat einen Namen, eine optionale CRM-Referenz, die du selbst einträgst, freie Notizen und eine Archiv-Markierung. Accounts importierst du aus einer CSV-Datei und exportierst sie wieder.
Gespeicherte Daten: Account-Name, CRM-Referenz, Notizen, Archiv-Markierung, Erstell- und Änderungsdatum.
Beispiel: Du importierst eine CSV mit den Spalten name und crm_ref, legst so 40 Accounts in einem Schritt an und archivierst danach die abgesprungenen Kunden.
Zusagen-Register
Eine Zusage ist ein Versprechen an einen Kunden. Sie hält Titel, Details, eine Art (Feature, Implementierung, Training, Support, Kommerzielles oder Sonstiges), eine Priorität, einen Verantwortlichen, einen Reviewer und ein Fälligkeitsdatum fest. Jede Zusage durchläuft einen festen Ablauf: möglich, bestätigt, in Arbeit, Lieferung eingereicht und verifiziert. Sie kann auch als strittig oder storniert enden.
Gespeicherte Daten: Titel, Details, Art, Priorität, Status, Verantwortlicher, Reviewer, Fälligkeitsdatum, wer wann bestätigt hat, wer wann verifiziert hat.
Beispiel: Ein Kandidat namens "Integration review document" für Northstar Labs wird am 20. Oktober bestätigt, mit Verantwortlichem und Fälligkeit am 12. November.
Erfassen aus eingefügten Notizen
Du fügst eine Zeile aus einer Meeting-Notiz ein und speicherst sie als mögliche Zusage. Der eingefügte Text bleibt als Quellenauszug angehängt, auf Wunsch zusammen mit einem Link zum Original. Nichts wird automatisch angenommen. Eine Kollegin oder ein Kollege muss den Kandidaten bestätigen oder ablehnen.
Gespeicherte Daten: Quellenauszug, Quellenlink, der Account und die Person, die den Kandidaten angelegt hat.
Beispiel: Du fügst "We will set up a dedicated support channel for your team" aus einem Kickoff-Call ein, und eine Kollegin bestätigt den Eintrag noch am selben Tag.
Belege und Review
Hat die verantwortliche Person geliefert, reicht sie einen Beleg als Notiz oder Link ein, und die Zusage wechselt auf "Lieferung eingereicht". Die Review-Queue listet alles, was auf einen Reviewer wartet. Der Reviewer verifiziert die Lieferung oder öffnet die Zusage mit einem Kommentar erneut.
Gespeicherte Daten: Belegnotizen und Links mit Person und Zeitpunkt der Einreichung sowie die Entscheidung des Reviewers im Verlauf der Zusage.
Beispiel: Die verantwortliche Person verlinkt die gemeinsame Implementierungs-Checkliste als Beleg, und der Reviewer verifiziert die Zusage in der Review-Queue.
E-Mail-Erinnerungen
Verantwortliche erhalten eine E-Mail 7 Tage vor, 2 Tage vor und am Tag der Fälligkeit einer Zusage. Für überfällige Zusagen gibt es eine wöchentliche Übersicht. Erinnerungen gehen nur an dein eigenes Team, nie an den Kunden.
Gespeicherte Daten: Eine Warteschlange mit Erinnerungs-E-Mails samt Empfänger, Betreff, Versandzeit und Zustellstatus.
Beispiel: Für eine Zusage, die am 12. November fällig ist, kommt die erste Erinnerung am 5. November und die zweite am 10. November.
Übersicht
Die Übersicht zeigt, was jetzt Aufmerksamkeit braucht: bestätigte Zusagen, die überfällig sind, Zusagen mit Fälligkeit in den nächsten 7 Tagen, Lieferungen, die auf Verifizierung warten, und Kandidaten, die auf Prüfung warten. Dazu listet sie anstehende Fälligkeiten und Accounts mit offenen Zusagen.
Gespeicherte Daten: Nichts zusätzlich. Die Übersicht liest deine Zusagen und zeigt Zahlen und Listen.
Beispiel: Am Montagmorgen zeigt die Übersicht 2 überfällige und 4 diese Woche fällige Zusagen, und du öffnest zuerst die überfälligen.
Aktivitätsprotokoll und Verlauf
Jede Statusänderung landet im Verlauf der jeweiligen Zusage, Ereignisse auf Workspace-Ebene erscheinen im Aktivitätsprotokoll. Jeder Eintrag zeigt Person, Zeitpunkt und ob die Aktion aus der Web-App, von einem MCP-Client oder vom System kam.
Gespeicherte Daten: Vorheriger und neuer Status, Akteur, Kommentar, Zeitstempel und Quelle (Web, MCP oder System).
Beispiel: Das Protokoll zeigt, dass ein Kandidat um 09:14 Uhr über MCP angelegt und um 10:02 Uhr in der Web-App von einem namentlich genannten Teammitglied bestätigt wurde.
MCP-Zugriff für KI-Clients
Ein Owner oder Mitglied des Workspaces erzeugt ein Bearer-Token. Damit kann ein MCP-Client wie Claude Accounts auflisten, Zusagen und Briefings lesen, Zusagen-Kandidaten anlegen und eine Nachfass-Nachricht entwerfen. Das Token wird einmal angezeigt und nur als Hash gespeichert. Die Einrichtung steht auf der MCP-Seite.
Gespeicherte Daten: Token-Bezeichnung, ein Hash des Tokens, Zeitpunkt der letzten Nutzung und eine Widerrufs-Markierung. Das Token selbst wird nie gespeichert.
Beispiel: Du fragst Claude, welche bestätigten Zusagen eines Accounts noch offen sind, und es antwortet aus deinem Register.
Team und Workspace
Ein Workspace hat Owner, Admins und Mitglieder. Owner und Admins können Kolleginnen und Kollegen hinzufügen, die bereits einen Account haben, sie entfernen und das Billing-Portal öffnen. Die Zahl der CSMs hängt vom Plan ab: 5 bei Team und 25 bei Growth.
Gespeicherte Daten: Workspace-Name, Zeitzone, Mitgliedschaften mit Rollen und der Abo-Status von Stripe.
Beispiel: In einem Team-Workspace mit 5 CSMs lässt sich eine sechste Person erst hinzufügen, wenn du auf Growth wechselst.
Gekennzeichnete Demo-Daten
Du kannst einen neuen Workspace mit 3 fiktiven Accounts und 6 Beispiel-Zusagen füllen, um ein vollständiges Register zu sehen. Jeder Demo-Datensatz trägt das Präfix [DEMO] und lässt sich so von echten Daten unterscheiden.
Gespeicherte Daten: Normale Accounts und Zusagen mit dem Präfix [DEMO] im Titel oder Auszug.
Beispiel: Du befüllst den Demo-Workspace, probierst die Review-Queue aus und archivierst danach die Demo-Accounts.