Four Kitchens — Build Packages

Three packageable units, ranked by natural coupling. Building-block view of the recommendations — pitchable independently or in combination. Individual build detail at fourkitchens-findings.data.newfangled.com.
Pkg Package Story Builds included Effort Primary stakeholder
A Financial Operations Stack Tier 1 · Tier 1 · Tier 2/3 End the manual financial-ops chain. Three coupled builds that share the same data infrastructure and compound when delivered together. 3 · 4 · 6 ~6–10 weeks Beto · leadership
B Knowledge & Intelligence Foundation Tier 2 · Tier 1+ Build the AI substrate, then the first agent on top. CKA plus the SiBorg refactor it absorbs, plus the Client Health Agent that rides on it. The strategic AI bet. 1 · 2 ~8–11 weeks Si · leadership · everyone
C Client Reporting Tier 1 · cheapest entry Modernize the client reporting workflow. Standalone Tier 1 quick win. Operates on its own data spine — independent of Packages A and B. 5 ~2–3 weeks PMs · Joanna · Shanice

Upsell paths · how the packages compound

Start with C → grow to B

Client Reporting is the cheap entry point. Lets 4K experience working with us before bigger commitments. The natural follow-on is Package B — the CKA makes those same reports richer (engagement-level context) and unlocks future client-facing AI work.

Start with A → grow to B

Financial Operations Stack solves Beto's pain without buying into the AI-substrate story. The natural follow-on is Package B — once the CKA is in place, Build 6's discrepancy investigation can read engagement context, not just the manual chain.

Start with B → everything compounds

Knowledge & Intelligence Foundation is the most expensive single package and the most strategic. Once shipped, Package A's builds become smarter (CKA-aware), Package C's reports become richer, and the additional-candidate items (attrition forecasting, inside-sales pattern detection) earn their way into scope.

Constraints that shape every package

Harvest is moving

5x repricing at renewal. Every Harvest-anchored build needs a pluggable connector layer.Elia · M3 · ~57:48

Consolidation over addition

Every "add this" pairs with a "retire this." Each package's retire-list is named explicitly inside.Elia · M3 · ~58:25–59:14

Hospitality layer is no-touch

Build zone is operations, finance, biz-dev, AR. Human-to-human client conversation stays out of scope across all three packages.Elia · M1 · ~25:25

Connector status open

ClickUp, Notion, and Forecast aren't in the productized MCP family today. Affects Packages A, B, and C in different ways — see Tech Stack tab.

A

Financial Operations Stack

~6–10 weeks Beto · operations · leadership Tier 1 · 1 · 2/3

Why this package

4K's financial operations run on a manual ETL chain Beto maintains by hand. Three pieces — scorecard updating, late-invoice monitoring, and the pipeline-to-Finance-HQ flow — share the same data infrastructure (Harvest, Forecast, sheets, Notion scorecards) and benefit the same primary stakeholder. Built together they form a single operational refactor; built separately they duplicate the same connector and reconciliation work across three engagements.

The pitch is "end the manual financial-ops chain," not three independent automations. The package solves the structural fragility leadership has self-named — the two-person debugging dependency — while also automating the recurring weekly tax Beto absorbs.

Builds in this package

Build Description Tier Effort
03
Scorecard Updater
Automates Beto's weekly Harvest+Forecast → master sheet → Notion scorecards ETL. v1 scopes to Beto's rows.
Full cheat sheet ↗ 		Tier 1 (caveated) ~2–3 weeks
04
Late-Invoice / AR Automation
Scheduled Harvest queries identify late invoices and draft emails + Slack escalations. Replaces Mon/Thu manual monitoring.
Full cheat sheet ↗ 		Tier 1 ~1–2 weeks
06
Pipeline → Finance HQ Automation
Two-phase. Phase 1: upstream pipeline automation + controller-side discovery. Phase 2: Finance HQ integration + discrepancy-investigation surface.
Full cheat sheet ↗ 		Tier 2 (Phase 2: 2/3) ~3–5 weeks total

How the builds compound

  • Build 6 Phase 1's consolidated pipeline view feeds Build 3's input cleanly. Built together, the projection-to-scorecard handoff goes from manual to automatic in one engagement instead of two.
  • Build 4 reuses the Harvest pluggable layer that Builds 3 and 6 also build. Building it as part of the package amortizes the connector work across three deliverables.
  • All three reduce pressure on Beto's weekly cycles. Build 6's discrepancy surface explicitly addresses the two-person debugging dependency leadership named in M3.

What this package retires

  • Beto's weekly Harvest/Forecast export-paste cycle
  • Manual Notion scorecards data entry (Beto's rows)
  • Teresa's CC sheet manual transfer into the scorecard
  • Manual revenue-projection entry from the invoicing sheet
  • Beto's weekly manual transfer of PM projections into the Active Projects tab
  • Manual reconciliation between projection sheets and Finance HQ
  • The Sherlock-Holmes debugging tax (two-person dependency)
  • Mon/Thu manual late-invoice monitoring cadence
  • Late-payment admin sheet as primary surface (becomes review log)

Where the information lives — consolidated across the package

Harvest canonical · NF family
The data spine for all three builds. Billable hours (Build 3), open/late invoices (Build 4), realized hours for projection-vs-actuals (Build 6). Pluggable layer required — Harvest is moving by end of year. The package builds it once.
Forecast undocumented API
Planned/scheduled hours (Build 3), engagement-type tags. Same pilot work serves Build 3 and Build 6. Build 4 doesn't depend on it.
Google Sheets — master sheet, projections, admin sheet
Beto's master sheet (Build 3 source), PM one-pager projections (Build 6 source), late-payment admin sheet (Build 4 origin), Pipeline-and-Active-Projects sheet (Build 6 source).
Notion — scorecards database new connector
Destination for Build 3. Build 6 outputs also feed here naturally. Notion not in NF MCP family today. Connector work is shared across the package, not Build-3-only.
Teresa's CC projection sheet
Build 3 ingests monthly CC numbers. Currently a separate manual sheet — automation either reads or replaces Teresa's input flow.
Invoicing spreadsheet
Build 3 ingests for the revenue-projection scorecard loop. Currently disconnected from sales pipeline and Harvest.
Pipedrive NF family
Feeds the Pipeline-and-Active-Projects Open Pipeline tab (Build 6). Weighting toggles already in place.
Finance HQ — 4K's controller tool unknown surface
Build 6 Phase 2 integration target. Phase 1 discovery sprint documents the surface and per-line EBR mechanism.
Gmail — accounting inbox
Build 4 destination for drafted late-invoice emails.
Slack
Build 4 escalation channel to PMs. Build 3 pre-meeting socialization channel (Beto's existing pattern preserved).
QuickBooks
Cross-check for accounting accuracy in Build 6's discrepancy surface.

Blockers and open questions

  • Forecast undocumented API affects Builds 3 and 6 — pilot is the variance driver. The package amortizes the pilot risk across both builds.
  • Notion connector — not in NF family. Adds to library after Build 3 lands.
  • Controller tool surface unknown — Phase 1 of Build 6 produces the documentation 4K doesn't have today.
  • [SENSITIVE-ADJACENT] two-person debugging dependency. System-level framing only in any artifact.
  • Behavioral: root cause of pipeline discrepancies is PMs late on projection updates. The package surfaces the symptom; it doesn't change PM behavior.
Total effort
~6–10 weeks
Tier mix
1 · 1 · 2/3
Primary stakeholder
Beto · ops
Standalone?
Yes
Natural follow-on
Package B
Build detail at Build 3 ↗Build 4 ↗Build 6 ↗
B

Knowledge & Intelligence Foundation

~8–11 weeks Si · leadership · everyone Tier 2 · 1+

Why this package

4K's knowledge fragments across six locations including "honestly, mostly in people's heads." SiBorg maintains a parallel ingestion of the same proposals and SOWs that a properly-built Client Knowledge Agent would index — exactly the redundancy Elia named as the actual operational debt. And the Account-360 gap from M3 — the single most important strategic finding of the audit — can't be solved without a substrate underneath.

Package B builds both: the substrate plus the first agent that rides on it. They're architecturally locked together. Pitched separately, the substrate looks like infrastructure overhead and the Account-360 build looks like it's missing a foundation. Together, the package answers "where do we sit AI long-term?" while delivering an immediately visible leadership-facing dashboard.

Builds in this package

Build Description Tier Effort
01
CKA + SiBorg refactor
4K-tailored Client Knowledge Agent deployment. 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. The substrate.
Full cheat sheet ↗ 		Tier 2 ~5–7 weeks
02
Client Health Agent — Account-360
Composition layer on top of the CKA that produces a per-account health view. Surfaces into the Projects Roundtable and pipeline conversations. The M3 headline finding's answer.
Full cheat sheet ↗ 		Tier 1+ (post-Build-1) ~3–4 weeks

How the builds compound

  • The CKA is the substrate; Build 2 cannot ship without it. Packaging them as a unit reflects the architectural reality and removes the conversation about "can we just have Build 2."
  • SiBorg refactor inside Build 1 has direct value to Si independent of the substrate's other consumers — making the package valuable across stakeholders (biz dev, leadership, account management).
  • Build 2's composition logic is most of what's unique to "account health." The CKA does the heavy data plumbing. Built together, the package's price honestly reflects that Build 2 is structurally light when its foundation is delivered.
  • Downstream features ride on this package: per-logo attrition forecasting, inside-sales pattern detection, sentiment automation from transcripts. They're earning their way out of "additional candidates" once Package B lands.

What this package retires

  • SiBorg's parallel ingestion pipeline (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 sheet + Harvest notes
  • Si's manual Forecast re-entry after every accepted estimate
  • Disparate dashboards reviewed individually in Projects Roundtable
  • Shanice's manual scoring as the leadership-access surface (stays as input)
  • Flat 90% recurring-revenue toggle (replaced by logo-by-logo signal as attrition forecasting layers in)

Where the information lives — consolidated across the package

ClickUp canonical · official MCP
99% client-facing per Joanna. Both builds depend on it. Connector is new for NF family but the vendor maintains an official MCP — integration work, not invention.
Slack — per-client internal-only channels canonical · official MCP
Team-side running commentary, decisions, in-the-moment context. The richest behavioral signal 4K has. 4K controls the channels directly; no client consent needed.
Slack — per-client shared-with-client channels canonical
Client communication cadence, response times, deliverable conversations. Both modes ingested.
Google Drive — SOWs, contracts, proposals, brand assets, boilerplate
Source-of-truth contractual terms. Plus SiBorg's historical-proposal corpus that collapses into the CKA. Plus brand style guide, boilerplate library, previous context briefings.
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, VTO, knowledge bases by team, temperature field, client-success scoring DB. Ingest all; confidence-weight by recency.
Harvest canonical · NF family
Source-of-truth for billable hours. Becomes the actuals-feedback source for the SiBorg estimation skill. Engagement age, billable rhythm per account, hours-vs-plan drift for the Client Health Agent.
Pipedrive NF family
Lead and deal history per logo, weighting toggles. ~65 active leads. Existing connector.
Forecast undocumented API
Allocation history, tag structure. Pilot required. Read-only ingestion via batched scraping at worst.
Gmail
Client correspondence per engagement, response patterns, externally observable cadence.
Shanice's manual sentiment sheet
1–10 gut-reaction score per 1:1, ~15 min per scoring entry, cadence biweekly / monthly / quarterly. Composition input for the Client Health Agent.
Projects Roundtable meeting notes
Weekly red/yellow per project, onboarding/offboarding decisions, sales opportunities surfaced from the same forum.
SiBorg win/loss memory layer ported
Si's accumulated 1–2-line entries from win/loss feedback. Migrates into the CKA as a tagged annotation layer Si still controls. Single-instance scoping enforced at the skill level.
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.

Blockers and open questions

  • ClickUp connector — new for NF (official vendor MCP exists, integration work not invention).
  • 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 decision on SiBorg-as-skill access: Si-only? Si plus engineering reviewers?
  • Recording-policy decision (Si/Julie conversation) gates sentiment-from-transcripts on Build 2.
  • PM-consistency observation from M1 must stay leadership-only access on Build 2.
Total effort
~8–11 weeks
Tier mix
2 · 1+
Primary stakeholder
Cross-functional
Standalone?
Yes
Unlocks
A · C compound · 7+ candidates
Build detail at Build 1 ↗Build 2 ↗
C

Client Reporting

~2–3 weeks PMs · Joanna · Shanice Tier 1 Cheapest entry

Why this package

All 4K client reports pull from Harvest, formatted in Google Sheets. Joanna already has a working AI prototype that aggregates ticket totals; Shanice keeps a Stanford burndown template in Claude. Each PM maintains their own template variant. The pattern is one workflow; the templates are the variance.

Standalone Tier 1 build with a clean data spine and an existing proof point. Fastest visible win in the proposal. Doesn't ride on the CKA and doesn't connect to the financial-ops chain — operates independently. The cheapest entry point if 4K wants to start with a low-risk engagement before committing more.

Build in this package

Build Description Tier Effort
05
Client Report Assistant
Configured per-client report templates riding on Harvest + ClickUp ingestion. Handles variable cadence (daily / weekly / monthly / quarterly). Smarter aggregation handles the multi-ticket-entry case PMs clean up manually today. Per-PM template variance preserved.
Full cheat sheet ↗ 		Tier 1 (caveated) ~2–3 weeks
Why this is standalone. Operates on its own data spine — Harvest + ClickUp + Google Sheets templates. Doesn't ride on Package B's CKA. Doesn't connect to Package A's financial-ops chain. Independent of every other build's success or sequencing. Selling it as part of a bigger package would be dishonest — it's a quick win and pitched as one.

How this fits with the other packages

  • Optional CKA hook — if Package B also ships, the Report Assistant can pull richer engagement context (recent client correspondence, ticket-velocity from internal Slack) through the CKA's surface rather than direct integrations. Not a hard dependency.
  • ClickUp connector shared — Builds 1 and 5 both need it. If the connector is built for Package B, Package C inherits it. If Package C ships first, the connector lays groundwork for Package B.
  • Harvest pluggable layer shared — every package builds against the same pluggable Harvest layer. Whichever package ships first builds it; the others reuse.

What this package 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 · NF family
Billable hours per ticket, per engagement, per cadence window. The data spine for every report. Pluggable layer required.
ClickUp canonical · official MCP
Ticket-level detail, parent-task context, milestone status, priority labels (base→1→2→3→4). The strategic-context layer behind the hour numbers. Connector status: new for NF — same caveat as Package B.
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.
Existing Claude prototypes
Joanna's Harvest-to-tickets aggregator and Shanice's Stanford burndown template — already in production. 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 optional · via Package B
If Package B is also live, pull engagement-level context 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. Shared with Package B.
  • Per-PM template logic must be accommodated, not forced into uniformity (Pattern 4: process literacy unevenly distributed).
  • 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. Build needs a clean disambiguation rule.
Total effort
~2–3 weeks
Tier
1 (caveated)
Primary stakeholder
PMs
Standalone?
Yes — fully
Natural follow-on
Package B
Build detail at Build 5 ↗

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 package(s) depend on it. Use as feasibility cross-check during the conversation.

Tool 4K usage MCP server Public API NF family Packages
Time, operations, resource planning
Harvestmoving by end of year Canonical billable hours, invoicing ✓ Newfangled MCP ✓ REST v2 Yes ABC
Forecastforecastapp.com (Harvest) Resource planning, pre-sale allocation tags ✗ None ⚠ Undocumented only No ABC
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 BC
Knowledge, documentation, files
Notion Engagement DB, scorecards DB, partners DB, meeting notes, VTO, working agreements ✓ Official (hosted) ✓ Notion API No AB
Google Drive SOWs, contracts, proposals, brand assets, Zoom recording archive ✓ Community ✓ Drive API Workspace patterns B
Google Sheets Scorecard source sheet, report templates, projection sheets, late-payment admin sheet ✓ Community ✓ Sheets API Workspace patterns AC
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 AB
Gmail Client correspondence, accounting inbox destination ✓ Community ✓ Gmail API Workspace patterns AB
Zoom24-hour retention agreement Meetings and transcripts (gated by 4K data agreement) ✓ Official ✓ Zoom API No B (gated)
Fathomnamed in intake, not yet observed Meeting notes alternative; not currently 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 AB
Finance & accounting
QuickBooks Online Accounting source of truth ⚠ Official (early preview) ✓ Intuit API No A
Finance HQ4K's controller tool Financial-forecast tool; per-line EBR calculation N/A — internal tool ⚠ Unknown surface N/A A
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 B
ClaudeTeam plan, standard seats Hosts SiBorg, Joanna's aggregator, Shanice's burndown template Host platform ✓ Anthropic API Native BC
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 (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.

Packages column shows which package(s) the tool supports. A Financial Operations Stack · B Knowledge & Intelligence Foundation · C Client Reporting.

Practical read. Harvest, Forecast, and Slack appear in Packages A and B both — meaning each pluggable connector layer built in one package is reusable in the other. ClickUp is critical to B and C. Forecast remains the single biggest integration risk (no MCP, no public API) and touches all three packages.