Features of the commitment ledger
The Customer Success Manager is customer commitment tracking software. This page lists what it does today, what each feature stores and how it looks in practice.
Customer accounts
Every promise belongs to a customer account. An account has a name, an optional CRM reference you type in, free-form notes and an archived flag. You can import accounts from a CSV file and export them again.
Data it stores: Account name, CRM reference, notes, archived flag, created and updated dates.
Example: Import a CSV with the columns name and crm_ref to create 40 accounts in one step, then archive the ones that churned.
Commitment ledger
A commitment is one promise made to one customer. It records a title, details, a kind (feature, implementation, training, support, commercial or other), a priority, an owner, a reviewer and a due date. Each commitment moves through a fixed flow: potential, accepted, in progress, delivery submitted and verified. It can also end as disputed or cancelled.
Data it stores: Title, details, kind, priority, status, owner, reviewer, due date, who confirmed it and when, who verified it and when.
Example: A candidate called "Integration review document" for Northstar Labs becomes accepted on October 20 with an owner and a due date of November 12.
Capture from pasted notes
You paste a line from a meeting note and save it as a potential commitment. The text you pasted stays attached as the source excerpt, together with an optional link to the original. Nothing is accepted automatically. A teammate has to confirm or reject the candidate.
Data it stores: Source excerpt, source link, the account, the person who created the candidate.
Example: You paste "We will set up a dedicated support channel for your team" from a kickoff call and a colleague confirms it the same day.
Evidence and review
When the owner has delivered, they submit evidence as a note or a link and the commitment moves to delivery submitted. The review queue lists everything waiting for a reviewer, who verifies the delivery or reopens the commitment with a comment.
Data it stores: Evidence notes and links with who submitted them and when, plus the reviewer decision in the commitment history.
Example: The owner links the shared implementation checklist as evidence, and the reviewer verifies the commitment from the review queue.
Email reminders
Owners receive an email 7 days before, 2 days before and on the day a commitment is due. Overdue commitments produce a weekly digest. Reminders go to your own team only and never to the customer.
Data it stores: A queue of reminder emails with recipient, subject, send time and delivery status.
Example: An owner gets a reminder on November 5 for a commitment due on November 12, and another on November 10.
Overview dashboard
The overview shows what needs attention right now: accepted commitments that are overdue, commitments due in the next 7 days, deliveries awaiting verification and candidates waiting for review. It also lists upcoming due dates and accounts with open promises.
Data it stores: Nothing extra. It reads your commitments and shows counts and lists.
Example: On Monday morning the dashboard shows 2 overdue commitments and 4 due this week, and you open the overdue ones first.
Activity log and history
Every status change is written to a per-commitment history, and workspace-level events appear in the activity log. Each entry shows the person, the time and whether the action came from the web app, an MCP client or the system.
Data it stores: Previous and new status, actor, comment, timestamp and source (web, MCP or system).
Example: The log shows that a candidate was created through MCP at 09:14 and confirmed in the web app at 10:02 by a named teammate.
MCP access for AI clients
A workspace owner or member creates a bearer token, and an MCP client such as Claude can then list accounts, read commitments and briefs, create commitment candidates and draft a follow-up. The token is shown once and stored only as a hash. See the MCP page for setup.
Data it stores: Token label, a hash of the token, last used time and a revoked flag. The token itself is never stored.
Example: You ask Claude which accepted commitments for an account are still open, and it answers from your ledger.
Team and workspace
A workspace has owners, admins and members. Owners and admins can add teammates who already have an account, remove them and open the billing portal. The number of CSMs is limited by the plan: 5 on Team and 25 on Growth.
Data it stores: Workspace name, time zone, memberships with roles, and the subscription status from Stripe.
Example: A Team workspace with 5 CSMs cannot add a sixth person until the plan is changed to Growth.
Labeled demo data
You can fill a new workspace with 3 fictional accounts and 6 sample commitments to see a full ledger. Every demo record is marked with a [DEMO] prefix so it can be told apart from real data.
Data it stores: Ordinary accounts and commitments with a [DEMO] prefix in the title or excerpt.
Example: Seed the demo workspace, try the review queue, then archive the demo accounts.