The Client Tracker is our authenticated monthly money view. Each row must reconcile a billed relationship to a client, project, Project Lead, service, payment state, and source period. It does not decide who is an active client. The canonical Client Roster owns lifecycle status; the tracker helps Operations turn that roster into accountable work and reconciled reporting.
Most agencies keep this in someone’s head. Or in a CRM nobody updates. Or spread across five tools where no two numbers agree.
We keep the money view in one controlled Google Sheet and require every row to resolve back to the systems that own the underlying facts. Authorized operators and agents use it as an index, not as permission to invent missing values. It is deliberately boring. Boring is the point — boring is what scales.
This is the definitive article on what the Client Tracker is, how it is governed, and how it connects to MAA and the Money Tree. The operating rules are public. Client names, ledger values, account identifiers, authenticated report URLs, and client-specific performance remain private.
What the Client Tracker actually is
The Client Tracker is the monthly financial and routing projection of the canonical Client Roster. A reconciled row answers questions an owner, operator, or authorized agent asks repeatedly: Which roster entity is this? Which Basecamp project carries the work? Who is the verified Project Lead? What service and period does the charge cover? What payment or revenue record supports the value?
It is not a CRM, a client-status database, or a public directory. It is a spreadsheet on purpose, but authenticated, least-privilege access is still required. A new operator or an authorized agent can use it after onboarding; client billing and source-system links are never anonymous-read data.
It’s easy to confuse three things we use every day, so let’s separate them cleanly:
| Tool | What it answers | Level |
|---|---|---|
| Client Roster | Which relationships are Active Client, Special Project, or Not Active? | Lifecycle authority |
| Client Tracker | How does the current-period money view reconcile to the roster, project, lead, service, and source receipts? | Private financial projection |
| Success Tracker | What did we do for THIS client this week, and can we prove it? | One client |
| Basecamp | What’s the actual work — tasks, files, updates, conversations? | The execution |
The Client Tracker does not sit above those authorities. It is a projection that joins them. A tracker row is valid only when it maps to a canonical roster entity and, when work is in scope, to the exact Basecamp project. Work evidence belongs in Basecamp or the client-level Success Tracker; lifecycle status belongs in the roster; financial facts belong to their source records.
Which system owns each fact?
A shared spreadsheet becomes dangerous when people treat every cell as equally authoritative. This map makes the ownership boundary explicit:
| Fact or object | Owning source | How the Client Tracker uses it |
|---|---|---|
| Client lifecycle status | Canonical Client Roster | Copies the exact status; never infers it from payment, a project title, or an old month tab |
| Current-period billing and payment | Authenticated ledger or payment source | Shows a reconciled private value and source period |
| Project Lead | Explicit current assignment with dated evidence | Names the lead and evidence URL, or says UNKNOWN |
| Project members and work | Exact Basecamp project, overview, tasks, messages, files, and recordings | Links to the correct private project; membership alone is not lead evidence |
| Traffic, leads, bookings, sales, and revenue | Each metric’s authenticated source contract | Stores connection state, owner, period, and private report URL; Not connected is never converted to zero |
| Weekly decision loop | MAA — Metrics, Analysis, Action | Uses sourced movement plus verified work to choose owned, due-dated actions |
| Content-to-money structure | The Money Tree | Maps branches and supporting content publicly; adds private metrics only in an authenticated client view |
A Basecamp name, payment checkbox, old spreadsheet tab, or team-members list is evidence to investigate — not permission to overwrite the roster, name a Project Lead, or claim revenue. When the owning source is missing or conflicts, preserve UNKNOWN or CONTRADICTED and assign the reconciliation.
The columns: what every row shows
Each current-period row must map to one stable roster entity. These are the required governance fields and the private money fields they control:
| Column | What it holds | Why it’s there |
|---|---|---|
| Roster ID / Client | The stable roster entity and display name | Prevents two spellings from becoming two clients |
| Roster Status | Active Client, Special Project, or Not Active | Copied from the roster with an as-of date; never calculated from this sheet |
| Period | The month or explicit service interval | Keeps a current money view from masquerading as lifetime truth |
| Basecamp Project | The exact authenticated project name and URL | Ties the row to the work without exposing the private URL publicly |
| Project Lead | One verified accountable lead, or UNKNOWN | Gives every review and exception a real owner |
| Lead Evidence | Dated source URL and verification date | Stops project membership, an old config, or a guessed agency prefix from becoming ownership |
| Agency / Service Type | The operating group and documented service | Routes the work and maps the service to its current SOP |
| Amount / Payment State / Frequency / Method | Private ledger fields for the selected period | Supports reconciliation; values and account details never belong in the public article |
| Source Contract State | Connected, Not connected, Failed, or the documented state used by the reporting system | Makes missing analytics visible without fabricating zero |
Project naming helps route work — it does not create authority
The Basecamp Project column is a hinge because it points to the real work. A consistent name can suggest the tier, service, or operating group and is governed by Naming Projects and Threads in Basecamp. But a name is a routing convention, not lifecycle, billing, or Project Lead evidence. Verify those facts in their owning sources.
Tiers tell you the size
A project name may include a tier. Treat the label as a routing aid and confirm the current service against the tracker and scope record:
| Tier label | Name pattern | What to verify |
|---|---|---|
| Platinum | Clients 1 – Platinum: Company | Current scope, period, and Project Lead |
| Gold | Clients 2 – Gold: Company | Current scope, period, and Project Lead |
| Quickstart | Clients 4 – Quickstart: Company | Current scope, period, and Project Lead |
The historical reason for the numbering lives in the Basecamp naming guide. A project title such as Special Project: is still not enough to change the roster: current status must be reconciled with the canonical roster and its evidence.
The agency prefix is a routing hint
An operating-group prefix can make routing legible across a network:
Roof Launch Marketing’s Clients 4 – Quickstart: …HVAC Growth’s Clients 4 – Quickstart: …Ensiteful Marketing’s Clients 4 – Quickstart: …
The prefix is not proof of who currently leads the project, who owns the client relationship, or whose revenue it is. Those are separate facts. Reconcile the operating group in the Client Tracker, record the verified Project Lead explicitly, and use the ledger source for financial attribution.
Client lifecycle has exactly three canonical values: Active Client, Special Project, and Not Active. XXX, paused, prospect, unpaid, and missing-from-this-month are not replacement statuses. Keep the history, record the nuance as evidence, and use the roster’s exact current value.
Grouping the money view does not change who owns the facts
Operations can group the private sheet by operating group, service type, payment state, or period and can total the rows that pass reconciliation. Those groupings make exceptions visible and support the two-sided network. They do not establish client status, Project Lead, margin, or revenue attribution by themselves.
A total is publishable internally only when its rows use the same period and definition and reconcile to source receipts. A blank source is missing. Not connected is not zero. A forecast, pipeline value, invoice, sale, and collected or recognized revenue are different facts and stay different.
Project Lead is a required field, not a guess
Every working client project needs one current Project Lead: the person accountable for coordinating the project, preparing the client conversation, and closing the owned actions. This is the Accountable role in the RACI model. The Project Lead may delegate individual tasks, but the field holds one verified name.
The Client Tracker must store the Project Lead beside the exact Basecamp project, plus a dated evidence URL and verification date. The Basecamp project overview should show the same assignment alongside the team members. A person being a project member, appearing in an old configuration, or being associated with the agency is not enough. If no explicit current assignment can be verified, the value is UNKNOWN and Operations gets an owned reconciliation task.
| Project Lead check | Acceptance test |
|---|---|
| Identity | One current person is named; spelling matches the authenticated Basecamp member |
| Scope | The assignment names the exact client and project, not only an agency or department |
| Evidence | A dated source URL supports the assignment and can be read by an authorized reviewer |
| Propagation | The live tracker and Basecamp project overview agree; generated views inherit the field rather than copying it by hand |
| Unknowns | Missing or conflicting evidence stays UNKNOWN or CONTRADICTED with an owner and due date |
Source contracts keep analytics and revenue honest
The Client Tracker can point to traffic, leads, sales, and revenue, but those numbers belong to their source systems. Each private source contract records the source owner, authenticated property or account, owner URL, metric definition, period, timezone, attribution rule, connection state, and last successful receipt. The public article links the governing documentation; it never exposes a client’s property ID, account ID, report URL, or value.
| Metric family | Owning source and contract reference | Boundary |
|---|---|---|
| Owned search | Exact Search Console property · Search Analytics API contract | Clicks, impressions, CTR, and position are not third-party rank estimates |
| Website acquisition | Exact GA4 property · GA4 Data API contract | Preserve property timezone, source, landing page, and requested period |
| Business Profile intent | Exact GBP location · Business Profile Performance API contract | Call clicks are not connected calls, leads, or sales |
| Calls | Client’s named phone or call-tracking report | Keep call ID, source, answer state, duration, and disposition; the authenticated owner URL stays private |
| Forms, leads, bookings, and sales | Client’s named form log and CRM · HighLevel API reference when HighLevel is the selected source | A form submit is not automatically a qualified lead, booking, or sale |
| Paid media | Exact ad account · Google Ads reporting contract | Preserve account attribution settings and do not substitute platform conversions for collected revenue |
| Revenue | Client’s reconciled CRM, payment, or accounting record | Label collected or recognized revenue explicitly; opportunity value is not revenue |
Publish the definitions, governance, and public-safe Money Tree. Keep the ledger, client-specific analytics, authenticated source URLs, lead evidence, and private Money Tree inside the authorized client boundary. Transparency means the method can be inspected — not that confidential client records are exposed.
Every package ties to a defined SOP
The Service Type field maps the current scope to a written, agent-runnable SOP. The tracker should link the live scope or SOP instead of freezing a price or deliverable in article copy that can drift:
| Service Type | Current commercial source | The SOP behind it |
|---|---|---|
| AI agent setup | Live pricing or signed scope | AI Agents Set Up for Your Business |
| Maps Visibility System (MVS) | Live pricing or signed scope | The Maps Visibility System |
| Conversion Engine | Live pricing or signed scope | The Conversion Engine Package |
Documented delivery makes the work repeatable for a new operator or authorized agent. Every service should point at one canonical article or SOP, and the current commercial terms should point at the signed scope or live pricing page. The Skill Pack Library is the runnable layer; the Client Tracker is the routing and money projection.
How agents actually use the tracker
This is where the boring spreadsheet earns its keep. Authorized agents use the roster and tracker together on a schedule:
- Cohort selection pulls every and only exact
Active Clientrow from the canonical roster. Special Projects require their documented scope; Not Active rows stop. - Measurement reads each connected source contract. A missing connector becomes
Not connectedwith a named onboarding ask, not a zero or estimate. - The weekly Friday MAA combines sourced metric movement, verified work shipped, analysis, and two or three owned actions. The tracker supplies routing and money context; it does not replace the source dashboards.
- The Money Tree turns the same evidence into a visual decision aid. The public version shows structure and safe totals; the authenticated private version may add traffic, leads, sales, and reconciled revenue.
- Ownership routing assigns review to the verified Project Lead. If the lead or internal destination is unknown, the run blocks and asks Operations to reconcile the mapping.
The joined system is what makes the work legible to an agent. The roster defines the cohort. The Client Tracker supplies current-period financial context and routing. Basecamp holds the work and review. Source contracts support the metrics. MAA turns evidence into decisions, and the Money Tree makes the relationship between content and outcomes visible.
Why centralized infrastructure wins
Shared infrastructure is useful only when its authority boundaries are clear. Operators can use the same naming rules, SOPs, reporting format, and reconciliation method without giving every person or agent access to every client’s data.
Eligible AI Builders can work in provisioned Basecamp projects and follow the same skill library, knowledge base, naming rules, and meetings checklist. Their access is scoped to the work they are authorized to see. The Client Tracker remains a controlled Operations surface, and any disseminated view must be derived from it rather than maintained as a competing copy.
That lets an agency owner inherit working process while still knowing which person and source owns each fact. They can spend more time on the two things that matter most: the relationship and the work.
Shared infrastructure is leverage when there is one roster, one controlled money view, one explicit Project Lead per project, and one source contract per metric. The Client Tracker is the seam where those controls meet each authorized agency view.
Intrapreneurs, not lone entrepreneurs
The people running these agencies are mostly young adults building real books of business — but they’re not doing it alone in a garage. They’re intrapreneurs: building their own agency inside a system that already has the rails laid down.
An entrepreneur starting cold has to build the infrastructure, win clients, and define accountable reporting. An intrapreneur on our network can inherit the infrastructure, get coached on the work, and inspect the financial projection they are authorized to see. The AI Builder Program and our agencies use these shared rails.
Why we publish this openly
We publish the method openly and keep the records that require a login behind the right client and team boundary. The model is a two-sided network — local service businesses on one side and agencies serving them on the other — and trust requires both clear rules and responsible confidentiality.
So the rules are public. Basecamp Basics explains where work lives. The Meetings Checklist turns a call into deliverables. RACI names accountability. MAA turns evidence into action. The Money Tree makes structure and outcomes legible. This article explains how the Client Tracker joins those objects without replacing them.
Centralize work in Basecamp. Keep lifecycle status in the canonical roster. Keep the private money projection in the Client Tracker. Tie every service to an SOP, every metric to a source contract, and every project to one verified Project Lead. Do that, and humans and agents can operate the same system without guessing or leaking client data.
That’s the Client Tracker: a controlled, current-period money and routing view that is useful precisely because it knows which facts it does not own.
Client Tracker FAQ
Is the Client Tracker the client roster?
No. The canonical Client Roster owns the three lifecycle states: Active Client, Special Project, and Not Active. The Client Tracker is the authenticated monthly money view and must reconcile to the roster.
Can a project name or XXX decide whether a client is active?
No. A project name is a routing convention. XXX, unpaid, paused, a prospect label, or absence from the current month cannot replace the roster’s exact status.
How do we know who the Project Lead is?
The required Client Tracker record names one Project Lead and stores dated evidence for the exact project. The Basecamp project overview should agree. Membership alone is not proof; missing or conflicting evidence remains UNKNOWN or CONTRADICTED.
Can the Client Tracker be shared publicly?
No. Publish the method, definitions, and public-safe Money Tree. Keep client names, ledger data, authenticated Basecamp and source-system URLs, account identifiers, and private performance inside the authorized boundary.
What happens when analytics are not connected?
The source contract says Not connected and names the exact onboarding ask. It never turns missing access into zero, an estimate, or an outcome claim.
How do MAA and the Money Tree use the tracker?
MAA uses sourced metric movement and verified shipped work to choose actions. The Money Tree visualizes the content-to-money structure. Both use the Client Tracker for routing and current-period context while preserving the source dashboards as evidence.
Want to run your agency on these rails?
This is how the two-sided network operates — start with the foundation, then plug in.
See the AI Builder Program How It WorksRelated reading: MAA — Metrics, Analysis, Action · The Money Tree · Basecamp Basics · Naming Projects & Threads in Basecamp · The Meetings Checklist · Practice RACI Always · The Success Tracker · The Skill Pack Library · The Two-Sided Network · How It Works