| # | Build | What it does | Where the data lives |
|---|---|---|---|
| 01 | CKA + SiBorg refactor | 4K-tailored Client Knowledge Agent. SiBorg's knowledge layer collapses into the CKA in the same engagement; SiBorg becomes an estimation skill on top. Forecast write-back lands in scope. | ClickUpSlack — per-client internalSlack — per-client sharedGoogle Drive (SOWs · contracts · proposals · boilerplate)NotionHarvestPipedriveForecastGmailRate cardsSiBorg win/loss memory |
| 02 | Client Health Agent — Account-360 | Composes existing health signals (sentiment, engagement temperature, project red/yellow, pipeline weighting, engagement age, type) into one per-account view. Surfaces into Projects Roundtable and pipeline conversations. | Slack — per-client internalSlack — per-client sharedNotion engagement DBNotion success-scoring DBShanice's sentiment sheetProjects Roundtable notesClickUpPipedriveHarvest |
| 03 | Scorecard Updater | Automates Beto's weekly manual ETL: Harvest + Forecast exports → reconciled master sheet → typed into the Notion scorecards database. v1 scoped to Beto's rows. | HarvestForecastTeresa's CC projection sheetInvoicing spreadsheetPipeline-and-Active-Projects sheetNotion scorecards DBSlack |
| 04 | Late-Invoice / AR Automation | Scheduled Harvest query identifies late invoices. Drafts emails to the accounting inbox plus Slack escalations to PMs. Admin team reviews and sends. Always-on instead of Mon/Thu manual. | HarvestLate-payment admin sheetGmail (accounting inbox)Slack |
| 05 | Client Report Assistant | Configured per-client report templates on top of Harvest + ClickUp ingestion. Variable cadence per engagement. Handles the multi-ticket-entry case PMs clean up manually today. Per-PM template variance preserved. | HarvestClickUpGoogle Sheets templatesExisting Claude prototypes (Joanna · Shanice) |
| 06 | Pipeline → Finance HQ Automation | Kills the five-stage manual chain from PM projections to Finance HQ and ends the two-person debugging dependency. Phase 1 automates the upstream side plus a controller-side discovery sprint that firms up Phase 2's sizing. Phase 2 integrates with Finance HQ and ships the discrepancy-investigation surface. | PM one-pager projections sheetPipeline-and-Active-Projects sheetPipedriveFinance HQ (4K's controller tool)Build 3 outputQuickBooksHarvest |
canonical source of truth · in MCP family
stale / new ingestion risk: connector not in family today, or data drift
gated ingestion subject to policy or recording decision
via CKA reads through Build 1's substrate
Constraint · Harvest is moving
5x repricing at renewal. 4K probably won't be on Harvest at end of year. Every Harvest-anchored build needs a pluggable connector layer so the swap is config, not re-architecture.Elia · M3 · ~57:48
Constraint · Consolidation over addition
Every "add this" pairs with a "retire this." Cheat sheets name the retirement explicitly.Elia · M3 · ~58:25–59:14
Constraint · Hospitality layer is no-touch
Build zone is operations, finance, biz-dev, AR. The human-to-human client conversation stays out of scope.Elia · M1 · ~25:25
Constraint · Connector status open
ClickUp, Notion, Forecast are not in the productized MCP family today. Builds 1, 3, and 5 carry caveats — flagged inline on each tab.
CKA + SiBorg refactor
Tier 2
Custom Development
Confidence: High on shape
Substrate · Top pick
Why this matters
Knowledge fragments across six locations including "honestly, mostly in people's heads." The Notion engagement DB rots between updates and isn't usable for onboarding. SiBorg maintains a parallel ingestion of the same proposals, SOWs, brand assets, and rate cards the CKA would index — exactly the redundancy Elia named as the actual operational debt. Building the CKA and refactoring SiBorg's knowledge layer onto it in the same engagement is the only honest version of this work.
Elia · M2 · ~51:35 · "I would [send them there], but I would say it's probably out of date." · Elia · M2 · ~57:55 · "we don't need to put it in 900 places … we can just ask the agent what are the terms in this SOW?"How it works
- CKA substrate. 4K-tailored deployment. Standard surface — load history, search history, fetch details, recent activity. The ingestion config is what's bespoke.
- SiBorg refactor. Knowledge layer collapses into the CKA. SiBorg becomes an estimation skill that queries CKA tools for comparable proposals, rate cards, engagement history, and Harvest actuals (the loop that doesn't exist today).
- Forecast write-back. Once an estimate is accepted, the SiBorg skill writes it into Forecast on Si's behalf. Replaces the manual re-entry.
- Single-instance preserved as a permissions/scoping decision on the skill. Si stays accountable.
What it retires
- SiBorg's parallel ingestion pipeline for proposals, SOWs, rate cards, boilerplate, brand assets — collapses into the CKA.
- Notion engagement DB as canonical onboarding surface.
- Manual "where do I find this" searches across six locations.
- SOW terms duplicated across Notion engagement DB, invoicing spreadsheet, and Harvest notes.
- Si's manual Forecast re-entry after every accepted estimate.
Where the information lives
ClickUp canonical new connector
99% client-facing per Joanna. All tickets, parent-task context, milestone history, priority labels (base→1→2→3→4), icebox content. Replaces Asana from reference CKA deployments.Connector status: open question. Building this is part of the engagement.
Slack — per-client internal-only channels canonical
Team's running commentary per account: decisions taken in flow, frustrations, in-the-moment context that never makes it into Notion. The richest behavioral signal 4K has — 4K already controls these channels, no client consent needed.Beto · M3 · ~43:48 · "Public with them and without them. Most, most of the time."
Slack — per-client shared-with-client channels canonical
Client communication, response cadence, deliverable conversations. Same per-channel pattern as the internal channels but with the client present. Both modes ingested.
Google Drive — SOWs, contracts, proposals, brand assets
Source-of-truth contractual terms (the "agent that reads the SOW" Elia named directly). Plus the historical-proposal corpus SiBorg currently re-indexes separately.
Google Drive — boilerplate library + brand style guide
Currently SiBorg's local knowledge. After refactor, lives once in the CKA and SiBorg's skill queries it.
Google Drive — Zoom recording archive gated
Subject to 4K's 24-hour retention agreement. Architecture has to respect this constraint.
Notion — selectively stale
Engagement DB, partners DB, scorecards, meeting notes, working agreements, knowledge bases by team, VTO space. Ingest all; confidence-weight by recency since both engagement DB and partners DB rot or were never well-curated.Notion is not in the MCP family today.
Harvest canonical
Source-of-truth for billable hours. Becomes the actuals-feedback source for the SiBorg estimation skill — the loop that doesn't exist today.Pluggable layer required — Harvest is moving by end of year.
Pipedrive
Lead and deal history per logo, weighting toggles, status. ~65 active leads. Existing MCP connector.
Forecast undocumented API
Allocation history, tag structure (pre-sale, CC, Build, StaffAug, Pixie). Pilot required for automated read. Manual export fallback works.
Gmail
Client correspondence per engagement, response patterns, externally observable cadence.
Rate cards
Currently SiBorg pulls them from comparable projects. After refactor, the CKA holds them and SiBorg's skill queries them.
SiBorg win/loss memory layer ported
Si's accumulated 1–2-line entries from win/loss feedback after each opportunity. Migrates into the CKA as a tagged annotation layer Si still controls. Single-instance scoping enforced at the skill level.
Blockers and open questions
- ClickUp connector — first-time-for-us integration.
- Per-client Slack ingestion scoping (both modes).
- Forecast undocumented API for the read pipeline — pilot required.
- Migrating SiBorg's accumulated win/loss memory without losing the texture Si has built over 6–8 months.
- 4K data agreement on Zoom retention shapes transcript handling.
- Permissions/scoping on SiBorg-as-skill: Si-only? Si plus engineering reviewers? Confirm during scoping.
Sources: sales-notes · "HUGE" onboardingintake · knowledge_location fieldJoanna · M2 · ~58:45–59:09 (Notion · Achilles tendon)Elia · M2 · ~51:35 (engagement DB rot)Elia · M2 · ~57:55 (SOW agent)Si · M3 · ~13:43–14:10 (all-logo data wish)Si · M3 · ~16:33–18:24 (Harvest-actuals loop)Si · M3 · ~52:55–54:09 (single-instance)Beto · M2 · ~17:31–18:23 (Forecast manual re-entry)Beto · M3 · ~56:58 (partners DB)
Client Health Agent — Account-360
Tier 1+ post-Build-1
Custom Dev (light)
Confidence: High on shape
Tier note. Originally flagged Tier 2. Honest reassessment: once Build 1's substrate lands, this is composition logic + a dashboard configured to 4K's data shape + alert routing. Logic-only, no new infrastructure. Closer to a heavy Tier 1 than a typical Tier 2.
Why this matters
Every signal of account health exists. None compose. Project red/yellow lives in the Projects Roundtable. Sentiment lives in Shanice's manual scoring sheet. Engagement temperature lives in Notion. Per-client internal Slack channels carry real-time team frustration. Pipeline weighting lives in Pipedrive. Revenue projections live in the five-stage spreadsheet chain. No single surface lets leadership see the whole picture of an account before a Projects Roundtable or pipeline conversation.
Elia · M3 · ~47:09–47:50 · "There's all these disparate things happening, but nothing that is kind of like… this holistic picture of this account."How it works
- Composition layer on top of the CKA. No parallel ingestion — every read goes through Build 1's substrate.
- Per-account dashboard. Leadership-only access. Composed health signal plus the underlying components per account.
- Alert surface. Material risk shifts (sentiment drop, recurring late deliverables, engagement-age threshold, yellow→red transition) trigger notifications instead of being buried in a weekly forum.
- Projects Roundtable integration. The composed view lands automatically on the Roundtable's weekly agenda.
- Pipeline conversation integration. Risk status surfaces alongside pipeline weighting where it currently doesn't appear.
- Per-logo attrition forecasting as a downstream feature once enough engagement-age and sentiment signal accumulates. Replaces the flat 90% recurring-revenue toggle.
What it retires
- Disparate dashboards reviewed individually in the Projects Roundtable.
- Shanice's manual scoring as the surface leadership goes to — it stays as an input, but the agent becomes where the answer lives.
- The flat 90% recurring-revenue toggle (replaced by logo-by-logo signal as attrition forecasting layers in).
- The implicit "Beto and Shanice's heads" health surface — formalizes what they already know into something queryable.
Where the information lives
Most reads flow through the CKA from Build 1 — no duplicate ingestion. The composition logic is what's bespoke.
Slack — per-client internal-only via CKA
Real-time team-side frustration, decisions, in-the-moment context per account. The cleanest sentiment surface — 4K already controls these channels.
Slack — per-client shared-with-client via CKA
Client communication cadence, response times, deliverable disputes. Observable signal even where consent narrows what we can analyze deeply.
Notion — engagement database via CKA stale
"Temperature" field manually managed by Shanice; engagement-type flag; risk notes. The field exists; the DB rots so the composition logic confidence-weights on recency.
Notion — client-success scoring DB via CKA
Shanice's separate database for 1:1 check-in summaries, distinct from the engagement DB.
Shanice's manual sentiment sheet via CKA
1–10 gut-reaction score per 1:1, ~15 min per scoring entry, cadence biweekly / monthly / quarterly per engagement.Si · M3 · ~46:13 · "we'd love to be able to get to a place where it's seeing those conversations, it's picking up on that sentiment analysis, and it's scoring for us instantaneously."
Projects Roundtable meeting notes
Weekly cadence. Red/yellow per project. Onboarding / offboarding decisions. Sales opportunities surfaced from the same forum.Beto · M3 · ~41:45 · "When I'm really alarmed, it's when there's a really unhappy client on a meeting."
ClickUp via CKA
Ticket cadence, milestone slips, priority-label drift, engineering velocity per account. Behavioral signal beyond the explicit health surfaces.
Pipedrive via CKA
Per-deal weighting toggles (likely / very likely). ~65 active leads.
Harvest via CKA
Engagement age, billable rhythm per account, hours-vs-plan drift. The temporal signal.
Pipeline-and-Active-Projects sheet
Revenue projection and weighting context per account. Reads cleanly if Build 6 (Phase 1) also ships.
Zoom client meeting transcripts gated
Sentiment-from-transcripts as a downstream extension. Gated by recording-policy decision in progress; subject to 4K's 24-hour Zoom retention agreement.
Engagement-type tags via CKA
CC vs. Build vs. StaffAug vs. T&M vs. Fixed Fee correlates with risk. Beto in M3: bad engagements cluster in {Fixed Fee, T&M with start/end dates}; CC and Staff Aug retainers are mostly positive.
Blockers and open questions
- Direct dependency on Build 1 — Client Health Agent can't ship without the CKA in place. Sequencing is rigid.
- Recording-policy decision gates sentiment-from-transcripts. Without it, the agent reads behavioral signal (Slack, ticket cadence, response patterns) but not literal sentiment from voice.
- PM-consistency observation from M1 must stay leadership-only access — never surfaces in any view the named PMs can see. Build the access permissioning around this from day one.
- The Notion engagement DB "temperature" field updates infrequently — composition logic has to confidence-weight, not treat as live.
Sources: Elia · M3 · ~47:09–47:50 (headline)Beto · M3 · ~37:38–44:48 (Projects Roundtable)Beto · M3 · ~43:48 (per-client Slack)Beto · M3 · ~41:30–42:48 (risk threshold)Beto · M3 · ~43:50–44:48 (engagement-type vs risk)Shanice · M2 · ~55:55–56:51 (Notion temperature)Shanice · M2 · ~56:25 (separate scoring DB)Si · M3 · ~45:27–47:08 (Shanice sentiment workflow)Si · M3 · ~50:55–52:55 (attrition want)
Scorecard Updater
Tier 1
Foundations
Confidence: High on shape
Connector caveat
Connector caveat. Reads Forecast (undocumented API · new connector) and writes Notion (not in the MCP family per existing-builds.md). If we have to build either from scratch, this is honestly Tier 2 not Tier 1. Check connector status before pitching.
Why this matters
Beto's weekly process is a manual ETL pipeline. Pull a Harvest report → export Forecast → paste into a master sheet → reconcile name-format mismatches and re-add archived-project data → layer in CC numbers from Teresa's separate sheet → layer in pre-sale assumptions → type results into the Notion scorecards database one cell at a time, per metric, per week. He does it twice if numbers shift between Tuesday Delivery L10 and Wednesday Leadership L10. The 5-minute number Beto cites is just the export-paste step — the Notion entry, CC import, and revenue-projection entry sit on top. Named verbatim on the intake form as "Updating Fucking Scorecards."
Beto · M2 · ~06:09–13:15 (full process) · ~20:30 (5 min current, 30 min historical) · ~42:51 (L10 cadence)How it works
- Connector-driven pipeline replaces Beto's hand-run ETL.
- Reads Harvest + Forecast + Teresa's CC sheet + invoicing sheet + Pipedrive pipeline tab.
- Applies the reconciliation formulas (migrated from the master sheet).
- Pushes to the Notion scorecards database via the existing metric / department / week-number schema.
- Runs ahead of each L10. Beto reviews and approves before the meeting — same review pattern, no input step.
What it retires
- Beto's weekly export-paste cycle from Harvest and Forecast.
- Manual reconciliation formula maintenance when source-system name formats drift.
- Manual CC-numbers copy from Teresa's sheet.
- Manual revenue-projection entry from the invoicing sheet.
- Per-metric, per-week typing into Notion scorecards cells (for Beto's rows).
- Mid-week double-update before Wednesday L10 (becomes a single automated sync).
- Beto's manual pre-Q1 archived-project backup workaround.
Where the information lives
Harvest canonical
Actual billable hours by person, engagement, work-type. Source for "actual billable hours last/this week" and per-person plan-vs-actual variance. Pluggable layer required.
Forecast undocumented API
Planned/scheduled hours, pre-sale "pink" allocations, engagement-type tags (pre-sale, CC, Build, StaffAug, Pixie). Two recurring frictions: archived projects drop out of exports (Beto keeps a manual pre-Q1 backup), and Harvest and Forecast use different name conventions (Beto has a reconciliation formula). Pilot required for automated read.
Beto's master sheet (current ETL surface)
Reconciliation formulas, planned-vs-actuals computation, sold/booked hours split CC vs. non-CC, 3–4 month forward projections, per-person plan-vs-actuals view. Becomes a reference/audit surface after automation — formulas migrate into the pipeline.
Teresa's CC projection sheet
Separate Google Sheet maintained by Teresa. Monthly contracted hours per CC engagement + 5-hour security/updates buffer per tier (CC15 = 15 contracted + 5 buffer). Rolls up monthly. Beto copies monthly numbers in manually because there's no automated fetch and CC projections shift continuously with sales activity.
Invoicing spreadsheet
Google Sheets maintained by the delivery team. Feeds the separate revenue-projection scorecards loop. Currently disconnected from sales pipeline and Harvest — Beto's "what's kind of the vibe that we get?" surface. Worth ingesting even with that quality posture.
Pipeline-and-Active-Projects sheet — Open Pipeline tab
Google Sheets, synced from Pipedrive with weighting toggles. Source for the pre-sale assumptions Beto drops into the master sheet.
Notion — scorecards database (destination) new connector
Each row is one scorecard metric, tagged by department (Delivery / Projects / Company-Leadership), with target field and week-number field. Surfaces on three different scorecards via the department tag. Current entry pattern: open filtered view, find the week's row, type the numbers into the week's cell — per-metric, per-week, manually, for every row Beto owns.Notion is not in the productized MCP family.
Slack
Beto's pre-meeting socialization channel. Posts the relevant slice ahead of L10 so the team reacts before the meeting. Pattern preserved — automation changes what gets posted, not how.
L10 meetings
Delivery Tuesday, Leadership Wednesday. Consumption points. Engineering leadership also has read access via a separate engineering-team scorecard sheet they're starting to own.
Blockers and open questions
- Harvest pluggable layer (forcing function).
- Forecast undocumented API on the read side — pilot required.
- Notion connector — not in the productized family. If built from scratch this work is Tier 2.
- Notion scorecards-database schema mapping per metric — need the metric / department / week-number contract per row Beto owns.
- Teresa's CC sheet: connect to its current form, or push Teresa's workflow into the same automation? Beto cited it as continuously shifting with sales activity — automating it means automating her input flow too.
- Scope question: more than Beto owns scorecard rows. v1 probably scopes to Beto's rows only — name that explicitly.
Sources: intake form · hand_off field ("Updating Fucking Scorecards")Beto · M2 · ~06:09–13:15 (scorecard process)Beto · M2 · ~20:30 (5 min current, 30 min historical)Beto · M2 · ~37:41–39:50 (Teresa's CC sheet)Beto · M2 · ~52:33–54:05 (invoicing-projection disconnect)Beto · M2 · ~42:51 (L10 cadence)Audit Findings · scorecard-update-process.md
Late-Invoice / AR Automation
Tier 1
Foundations
Confidence: High on shape
Why this matters
Two admin team members (Peke and Jade) split monitoring — one Monday, one Thursday. Workflow: pull a Harvest report → copy into a sheet weekly → identify late invoices → draft emails to clients or Slack-escalate to PMs. Elia named the build target nearly verbatim in M3. Workflow shape is generic. Volume not yet captured — a 15-minute follow-up sizes it.
Elia · M3 · ~31:32–31:50 · "All things that could be automated, you know, when there's a late invoice and Harvest with a certain time frame, you know, it could create an email in the accounting inbox."How it works
- Scheduled Harvest query identifies invoices over a configurable threshold (days overdue, optionally weighted by invoice size).
- Generates a draft email for the accounting inbox per flagged invoice.
- Slack message to the PM responsible for escalation.
- Admin team reviews and sends. Monitoring runs always-on.
- Snapshot log of flagged invoices for audit trail.
What it retires
- Mon/Thu manual monitoring cadence (becomes always-on).
- Late-payment admin sheet as the primary surface (becomes review log).
- Manual draft-email composition for routine late-invoice scenarios.
Where the information lives
Harvest canonical
Open and late invoice data, payment status, invoice metadata. Source of truth. Pluggable layer required — Harvest is moving.
Late-payment admin sheet
Google Sheets — Peke and Jade's weekly snapshot with formulas, draft-email actions, and Slack-escalation triggers. Becomes review log after automation.
Gmail — accounting inbox
Destination for draft emails. Standard Google Workspace integration.
Slack
Escalation channel from admin team to the PM responsible for the engagement. Existing channel pattern.
QuickBooks
Cross-check destination for accounting-side accuracy. Not in the live flow but referenced for reconciliation.
Blockers and open questions
- Harvest pluggable layer required (forcing function).
- Late-invoice volume per month not captured — 15-min follow-up with Peke or Jade.
- If Harvest is replaced before delivery, this becomes Tier 2 because the pluggable layer becomes the harder part.
- Threshold-tuning policy: who decides how many days overdue triggers the workflow? Same policy across engagement types or per-client?
Sources: Elia · M3 · ~29:45–32:54 (full workflow)Elia · M3 · ~31:32–31:50 (verbatim build target)roadblocks.md · late-invoice line item
Client Report Assistant
Tier 1
Foundations
Confidence: High on shape
ClickUp connector caveat
Connector caveat. ClickUp is not in the MCP family today. If we build the connector from scratch as part of this engagement, the work is Tier 2 not Tier 1. The connector also lands as part of Build 1 if both ship — natural pairing.
Why this matters
All client reports pull from Harvest, formatted in Google Sheets. Joanna already runs Harvest exports through Claude to aggregate ticket totals; manual cleanup happens on multi-ticket entries. Monthly reports take 30–60 minutes; daily reports 15 minutes per day. Shanice keeps a Stanford quarterly burndown template saved in Claude. Each PM maintains their own template variant. The pattern is one workflow; the templates are the variance.
Joanna · M2 · ~21:00–30:00 (workflow) · ~23:10–26:14 (existing AI prototype)How it works
- Configured per-client report templates riding on Harvest + ClickUp ingestion.
- Smarter aggregation handles the multi-ticket-entry case PMs clean up manually today.
- Variable cadence per engagement (daily / weekly / monthly / quarterly).
- Per-PM template variance preserved — consolidation is opt-in, not forced (Pattern 4: process literacy unevenly distributed).
- Optional: pull richer engagement context through Build 1's CKA surface once available.
What it retires
- Manual Harvest-export cleanup (multi-ticket triple-checking).
- Per-PM template duplication where consolidation makes sense.
- The export-paste-clean cycle as a recurring task.
Where the information lives
Harvest canonical
Billable hours per ticket, per engagement, per cadence window. The data spine for every report. Pluggable layer required.
ClickUp canonical new connector
Ticket-level detail, parent-task context, milestone status, priority labels (base→1→2→3→4). The strategic-context layer behind the hour numbers.Same connector status as Builds 1 and 3.
Google Sheets — current report templates
Daily, monthly, and quarterly variants per client. Joanna, Fabi, and Shanice each maintain their own. Source for per-client template configuration — some consolidate naturally, some stay client-specific.
Existing Claude prototypes
Joanna's Harvest-to-tickets aggregator and Shanice's Stanford burndown template — already in production. These are the patterns the build formalizes and extends.
Forecast undocumented API · optional
Allocation context — pre-sale vs. confirmed flagging, engagement-type tagging. Optional ingestion for richer report context.
CKA via Build 1 if available
If Build 1 is live, the Report Assistant can pull engagement context (recent client correspondence, ticket-velocity from internal Slack) through the CKA's surface rather than direct integrations. Not a hard dependency.
Blockers and open questions
- ClickUp connector status — determines Tier 1 vs Tier 2.
- Per-PM template logic must be accommodated, not forced into uniformity.
- Total reports-per-month not aggregated across portfolio — sizing follow-up needed.
- Harvest pluggable layer.
- Multi-ticket-entry handling: engineers logging multiple tickets in a single Harvest entry is the messy case. The build needs a clean disambiguation rule.
Sources: Joanna · M2 · ~21:00–30:00 (workflow)Joanna · M2 · ~23:10–26:14 (AI prototype)Shanice · M2 · ~27:21–27:44 (Stanford template)Joanna · M2 · ~58:45–59:09 (ClickUp / Notion)
Pipeline → Finance HQ Automation
Tier 2
Custom Development
Confidence: High on shape
Two-phase · discovery in Phase 1
Why this matters
Five-stage manual chain from PM projections to Finance HQ. Every join is manual. The $20K → $15K example was a 25% miss on a single client's monthly projection — multiplied across 31–50 active clients, the financial planning surface is operating with material noise. Bad projections compound into bad cash-flow plans, hiring decisions, and pipeline-weighting decisions. The reconciliation depends on two specific people maintaining context that exists only in their heads. [SENSITIVE-ADJACENT]: two-person debugging dependency — system-level framing in any artifact.
How it works · two phases
Phase 1 — Upstream automation + controller-side discovery. ~2–3 weeks.
- Automated pull from the PM one-pager projections sheet.
- Sync from Pipedrive with existing weighting toggles preserved (existing MCP connector).
- Consolidated pipeline view replaces Beto's manual Active Projects transfer.
- Parallel: short discovery sprint on 4K's controller tool plus the per-line EBR mechanism it runs.
- Phase 1 output: working upstream automation, documented financial-system surface, firm sizing on Phase 2.
Phase 2 — Finance HQ integration + discrepancy surface. Sized after Phase 1 completes.
- Finance HQ write integration (surface understood after Phase 1).
- Discrepancy-investigation surface: shows the drift, names the missing update, links to the responsible person.
- Per-service-line profitability dashboard rides on the same Phase 1 discovery (currently in additional candidates — earns its way out of that bucket when Phase 1 lands).
What it retires
- Beto's weekly manual transfer of PM projections into the Active Projects tab.
- Manual reconciliation between the pipeline sheet and Finance HQ.
- The Sherlock-Holmes debugging tax that lands on two specific people.
- The structural dependency on two specific people for financial reconciliation.
- The invisibility of upstream PM update lag — once Phase 1 ships, late projections become a real-time signal rather than a forensic discovery.
Where the information lives
PM "one-pager" projections sheet
Google Sheets, PM-maintained. Active non-CC projects only. PMs are supposed to update after invoicing or scope changes — the manual update layer is where discrepancies originate. The $20K → $15K example traced back to a missed projection update here.
Pipeline-and-Active-Projects sheet — Open Pipeline tab
Google Sheets, already synced from Pipedrive with weighting toggles applied. Partially automated today.
Pipeline-and-Active-Projects sheet — Active Projects tab
Google Sheets. Beto's manual recreation of what PM teams have said — the second manual transfer in the chain. Phase 1 automates this.
Pipedrive existing connector
Source for the Open Pipeline tab. Weighting toggles per deal already in place.
Finance HQ — 4K's controller tool unknown surface
4K's name for the financial-forecast tool. Receives data from the Pipeline-and-Active-Projects sheet. Calculates per-service-line EBR in some manual way 4K's own operations leadership can't fully describe.Phase 1 discovery documents the surface and the mechanism; Phase 2 integrates against it.
Notion scorecards database (via Build 3)
Destination for the resulting metrics. Build 3 already automates the Notion-side entry — Build 6's outputs feed Build 3's pipeline naturally if both ship. Cleanest pitched as a coupled pair.
QuickBooks
Financial source of truth for accounting. Out of the projection chain but referenced for cross-check in the discrepancy-investigation surface.
Harvest canonical
Realized billable hours, contextual signal for projection-vs-actuals reconciliation. Pluggable layer required.
Blockers and open questions
- Per-line EBR mechanism inside the controller tool — undocumented today; 4K's own operations leadership can't fully describe it. Phase 1 discovery produces the documentation 4K doesn't have.
- Finance HQ surface and API — unknown until Phase 1 completes. Phase 2 sizing depends on Phase 1 output.
[SENSITIVE-ADJACENT]: two-person debugging dependency. System-level framing only in any artifact.- Tier could shift to 3 on Phase 2 if Finance HQ needs a new MCP family member to connect to.
- Behavioral: root cause of discrepancies is PMs not updating projections on time. The build catches the drift but doesn't change PM behavior. Surfaces the structural issue rather than solving it — honest in the pitch.
- Pairing with Build 3 (Scorecard Updater): cleanest if both ship together. Phase 1's consolidated pipeline view feeds Build 3's input naturally.
Sources: Elia · M3 · ~21:24–25:04 (five-stage walkthrough)Elia · M3 · ~25:58–26:23 ($20K → $15K)Elia · M3 · ~33:56–34:38 (SENSITIVE-ADJACENT)Beto · M2 · ~53:48–54:05 (scorecard disconnect)Audit Findings · scorecard-update-process.md
Tech Stack — MCP & API Reference
Per tool: what 4K uses it for, MCP server availability, public API availability, current Newfangled MCP family membership, and which builds depend on it. Use as feasibility cross-check during the conversation.
| Tool | 4K usage | MCP server | Public API | NF family | Builds |
|---|---|---|---|---|---|
| Time, operations, resource planning | |||||
| Harvestmoving by end of year | Canonical billable hours, invoicing | ✓ Newfangled MCP | ✓ REST v2 | Yes | 1, 3, 4, 5, 6 |
| Forecastforecastapp.com (Harvest) | Resource planning, pre-sale allocation tags | ✗ None | ⚠ Undocumented only | No | 1, 3, 5, 6 |
| Project & task management | |||||
| ClickUp99% client-facing per Joanna | Tickets, parent-task context, milestones, priority labels (base→1→2→3→4) | ✓ Official (mcp.clickup.com) | ✓ REST API | No | 1, 2, 5 |
| Knowledge, documentation, files | |||||
| Notion | Engagement DB, scorecards DB, partners DB, meeting notes, VTO, working agreements | ✓ Official (hosted) | ✓ Notion API | No | 1, 2, 3 |
| Google Drive | SOWs, contracts, proposals, brand assets, Zoom recording archive | ✓ Community | ✓ Drive API | Workspace patterns | 1 |
| Google Sheets | Scorecard source sheet, report templates, projection sheets, late-payment admin sheet | ✓ Community | ✓ Sheets API | Workspace patterns | 3, 4, 5, 6 |
| Communication | |||||
| Slackper-client channels: internal AND shared | Team communication; per-client channels in both internal-only and shared-with-client modes | ✓ Official (Feb 2026) | ✓ Web API | No | 1, 2, 3, 4 |
| Gmail | Client correspondence, accounting inbox destination | ✓ Community | ✓ Gmail API | Workspace patterns | 1, 4 |
| Zoom24-hour retention agreement | Meetings and transcripts (gated by 4K data agreement) | ✓ Official | ✓ Zoom API | No | 1 (gated), 2 (gated) |
| Fathomnamed in intake, not yet observed in workflow | Meeting notes alternative; not currently used in any captured workflow | Composio integration | ✓ Public API + SDKs | No | — |
| CRM & pipeline | |||||
| Pipedrive~65 active leads | Sales pipeline, weighting toggles, lead history | ✓ Newfangled MCP | ✓ REST API | Yes | 1, 2, 6 |
| Finance & accounting | |||||
| QuickBooks Online | Accounting source of truth | ⚠ Official (early preview, sandbox only) | ✓ Intuit API | No | 4, 6 |
| Finance HQ4K's controller tool | Financial-forecast tool; per-line EBR calculation | N/A — internal tool | ⚠ Unknown surface | N/A | 6 |
| AI & internal tooling | |||||
| SiBorgSi's Claude Team project | RFP-to-proposal end-to-end agent built on Claude; single-instance by Si's design | N/A — Claude project | N/A | N/A | 1 |
| ClaudeTeam plan, standard seats | Hosts SiBorg, Joanna's aggregator, Shanice's burndown template | Host platform | ✓ Anthropic API | Native | 1, 2, 5 |
| Other / not directly in scope | |||||
| CMS — WordPress, Drupal | Client-facing CMS work (4K's service offering) | ✓ Community (multiple) | ✓ REST / JSON:API | No | — |
| Figma | Design — light usage; 4K doesn't do much design work | ✓ Official | ✓ Figma API | No | — |
| Google Analytics 4 | Website analytics (for 4K's own marketing site) | ✓ Newfangled MCP | ✓ GA Data API | Yes | — |
| Earth Class Mailcandidate, not yet adopted | Virtual mailbox candidate from sales meeting | ✗ None | ✓ REST API | No | — |
Legend. ✓ Official first-party MCP server maintained by the vendor · ✓ Newfangled MCP already built and productized in our connector family · ✓ Community reputable third-party MCP servers exist · ⚠ exists but with caveats (early preview, undocumented, unknown surface) · ✗ None no MCP server found · N/A not applicable (internal tool or host platform).
NF family = currently in existing-builds.md as a productized Newfangled MCP connector. Per the catalog: Harvest, Google Analytics, paid media, Act-On, Insight Engine, Client Knowledge Agent, Pipedrive, and Sanity. Workspace tools (Drive / Sheets / Gmail) reuse standard Google Workspace patterns rather than a dedicated NF connector.
Practical read for the regroup. Three tools at the heart of the proposal are not in our productized family today: ClickUp, Notion, and Forecast. The first two have official vendor-maintained MCP servers — adoption is integration work, not invention. Forecast is the real exception — no MCP, no public API, undocumented surface only. Any build that depends on it (1, 3, 5, 6) carries Forecast-specific integration risk that does not reduce as the rest of the proposal lands.