The Client Roster is the private lifecycle authority for every relationship our operators and agents may touch. It has one job: say whether the relationship is an Active Client, Special Project, or Not Active—with enough evidence to defend that decision.
That sounds simple because it should be. A roster is a safety gate, not a dashboard. It prevents an old project, an unpaid invoice, a familiar company name, or a stray spreadsheet row from quietly becoming permission to act.
What the Client Roster owns
The roster owns lifecycle status and the identity needed to apply it to the correct relationship. It answers four questions before work begins:
- Which exact client or relationship is this?
- What is its one current lifecycle state?
- When did that state become effective?
- What authenticated evidence supports it?
It does not own every useful client fact. The Client Tracker is the authenticated current-period money and routing view. Basecamp holds projects, people, tasks, messages, files, and the working Project Overview. Measurement systems own traffic, calls, forms, bookings, sales, and revenue. The MAA turns verified movement into decisions, and the Money Tree makes the content-to-outcome structure visible.
The three—and only three—states
“Paused,” “prospect,” “unpaid,” “old client,” “XXX,” and “missing from this month” may be useful evidence notes, but they are not replacement statuses. If the relationship does not cleanly map to one of the three states, the correct operational result is UNKNOWN and an owned reconciliation—not a guess.
Minimum record for every relationship
| Field | Why it exists | Fail-closed rule |
|---|---|---|
| Stable relationship ID | Prevents a nickname or spelling change from creating a second client | Identity conflict blocks client work |
| Client / entity name | Names the relationship humans recognize | A project title alone is not identity proof |
| Exact status | Controls whether ordinary, scoped, or no work is allowed | Only the three canonical values pass |
| Status evidence | Explains who or what authorized the state | Self-report or inference is labeled, not upgraded to verified |
| Effective / verified date | Separates current truth from history | Stale evidence triggers review |
| Exact Basecamp project | Joins the status to the correct work container | A mismatch blocks routing |
| Notes / safety state | Preserves narrow exceptions and no-contact rules | A safety hold overrides ordinary cadence |
Nobody deletes a relationship simply because it stopped paying or a project was archived. Change the state, record the effective date, preserve the evidence, and keep the history. Deletion destroys the explanation an operator will need later.
How the roster differs from the Client Tracker
| Question | Owning object |
|---|---|
| May our normal client process run? | Client Roster |
| What was billed or paid for this period? | Client Tracker joined to the financial source |
| Who is accountable for the current project? | Verified Project Lead record and Basecamp Project Overview |
| What work shipped? | Authenticated Basecamp artifacts and the client Success Tracker |
| What moved in traffic, leads, sales, or revenue? | Each metric’s dated source contract |
| What should happen next? | MAA, with an owner, due date, and success measure |
The live Client Tracker is the human Operations hub because it joins current money and routing context. The roster remains the narrow lifecycle gate. This is one system with distinct owners for distinct facts—not two competing databases. A generated or repository copy is a fail-closed execution projection; it must carry its source hash and stop on unresolved drift.
Project Lead is adjacent, not inferred
An Active Client row does not tell you who currently leads the work. The Client Tracker should hold one verified Project Lead beside the exact Basecamp project, plus a dated evidence URL or receipt. The Basecamp Project Overview should show the same assignment next to the team members.
Membership is not accountability. A recent comment, a familiar agency name, or an old assignment is only a clue. When the lead is blank or sources disagree, use UNKNOWN or CONTRADICTED, preserve the last accepted work, and route one correction to Operations.
The monthly reconciliation
- Read the current private sources. Capture the roster, current-period Client Tracker, and exact Basecamp project evidence without copying secrets into reports.
- Normalize identity. Match each relationship to one stable ID and one exact project; surface aliases rather than creating duplicates.
- Reconcile status. Require one canonical state, evidence, and effective date. Payment can support a decision but does not silently make it.
- Reconcile ownership. Require one verified Project Lead or an explicit blocker.
- Hash the projection. Bind the run to the exact roster, configuration, and measurement-source versions it used.
- Process every and only eligible row. Active Clients enter the normal queue; Special Projects require current scope; Not Active stops.
- Leave a terminal receipt. Every eligible row ends rendered, onboarding required, safety hold, or failed. Missing data never disappears.
How the roster drives MAA and the Money Tree
Once a row passes the lifecycle gate, the reporting system can collect dated sources and create a private client view. The Money Tree shows which content supports which service branches. Its public version may show structure and safe totals; its authenticated private version may add traffic, leads, sales, and reconciled revenue. Not connected is never rendered as zero.
The Friday MAA report uses the latest accepted tree immediately after its executive answer, then shows sourced metric movement, verified work shipped, analysis, and two or three actions. The tree supplements the source dashboards; it does not replace them.
Common failure modes
| Failure | Why it fails | Safe response |
|---|---|---|
| Using this month’s paid tab as the roster | Payment timing and lifecycle status are different facts | Reconcile the row to the canonical roster |
| Assuming every Basecamp project is active | Projects preserve history and may outlive service | Require current status evidence |
| Guessing the lead from the member list | Membership does not identify accountability | Require a named, dated Project Lead receipt |
| Deleting old clients | It destroys the audit trail and invites duplicate identities | Keep the row and mark Not Active |
| Calling missing analytics zero | It invents a business result | Use Not connected and name the onboarding ask |
| Maintaining multiple “live” trackers | Copies drift and agents act on different cohorts | Name one canonical source; label all exports derived and dated |
Client Roster FAQ
Is the Client Roster public?
The method is public; the row-level roster is private. Client identities, status evidence, project URLs, and safety notes stay inside the authorized Operations boundary.
Does paying automatically make someone an Active Client?
No. Payment is evidence to reconcile. Active Client requires a current, evidence-backed lifecycle decision matched to the exact relationship.
Can a Special Project run the weekly client cadence?
Only when its exact current scope authorizes that cadence. Special Project is not a shortcut to ordinary retainer authority.
What happens to Not Active rows?
They remain in history, but new staffing, tickets, outreach, reporting, and client work stop.
Where does the Project Lead live?
In the live Client Tracker beside the exact project, backed by dated evidence, and reflected in the Basecamp Project Overview. The roster does not infer the lead.
What should an agent do when sources disagree?
Preserve the last-known-good state, mark the affected fact UNKNOWN or CONTRADICTED, and route one owned reconciliation. Do not guess or silently change scope.
Related: Client Tracker · Basecamp Basics · Success Tracker · MAA · Money Tree