Four Kitchens — Audit

For Discussion
Overview

What's in this conversation

This is a working synthesis from five conversations with your team — the sales meeting, the intake form, and three working sessions. We've pulled out the patterns we saw most clearly and organized them across five sections to anchor today's discussion. Nothing here is a commitment to build; it's the shape of what we observed and where we think the biggest wins sit.

01
Pain points
The distinct issues we heard across the conversations, anchored in what your team actually said.
02
House in order
The categories of work that, if landed first, give you the biggest step up before anything else gets built.
03
What we could build
Our initial thinking on the highest-leverage opportunities for AI and automation. Conceptual, not specific.
04
Going deeper
Two production-side surfaces where our audit came up lighter than we'd like — design AI, development AI.
05
Open questions
Gaps we'd like to close with you so the next conversation has cleaner ground to stand on.
01 · Pain points

What we heard most clearly

Twelve distinct patterns surfaced across the audit conversations. Each has a short ID we'll refer back to in the next two sections. The goal of this view is to make sure these match what you actually see day-to-day — and to flag anything we missed.

P1 · Reconciliation

The reconciliation tax

Numbers don't reconcile across sheets. Beto and Elia are the only two people who can hunt down why.

"Beto and I are, like, the only two people whose brains are wired to be able to, like, hunt those things down... it's not how either one of us should be spending our time."Elia, Meeting 3

P2 · Win/loss

Win/loss is a black box

After an RFP closes, no structured data gets captured on why it went the way it did. Colleen named this in Meeting 1 as her single biggest truth gap.

"The ability to get actual constructive feedback is rare, few and far between... we don't have enough of that data."Colleen, Meeting 1

P3 · Estimation

SiBorg has no feedback loop

SiBorg generates estimates but never sees what actually got delivered. Si and John identified this in Meeting 3 as the obvious next move — but the actuals aren't being captured anywhere today.

"Yeah, and we used to do that, Beto and I used to do that manually... So it'd be great to automate that."Si, Meeting 3

P4 · Projections

Projection updates drift late

PMs don't refresh their projections on time, and the financial picture breaks downstream as a result.

"We've been projecting that this client would pay us $20,000 for this month, but now they're only paying us $15,000, because they didn't update the projections."Elia, Meeting 3

P5 · Account view

No holistic view of any account

Project status, sentiment, engagement temperature, pipeline weighting, and revenue projection all live in separate forums.

"There's all these disparate things happening, but nothing that is kind of like... This holistic picture of this account."Elia, Meeting 3

P6 · Bus factor

Critical knowledge in too few heads

Reconciliation lives with Beto and Elia. Sentiment with Shanice. EBR with Paul. SiBorg with Si. Elia's upcoming sabbatical exposes the fragility directly — half of the reconciliation pair will be unavailable.

P7 · PM variance

Same role, different methods

Each PM uses their own client reporting template, their own stand-up agenda, their own retro structure. Elia named this in Meeting 1 as her single biggest visibility gap into how the team operates.

"It could be different depending on who you're working with — different stand-up agendas, different retro structures, different workshop formats."Elia, Meeting 1 (paraphrased)

P8 · Recording

Client meeting recording is inconsistent

Some client meetings get recorded, some don't. This blocks an entire class of downstream AI capability — sentiment analysis, action-item extraction, follow-up tracking — none of which works reliably with partial coverage.

P9 · Canonical

No canonical sources or definitions

Contract terms live in three places. Hours are canonical in Harvest by consensus but not policy. Key terms like "on-track," "at-risk," and "profitable" mean different things to different roles.

"We don't need to put it in 900 places, hoping that somebody will remember where to look for it. We can just ask the agent, you know, what are the terms in this SOW?"Elia, Meeting 2

P10 · Tool stack

The stack has accreted, and Harvest is exiting

Dead tools still nominally in the stack — Teresa's CC dashboard, legacy Coda. Parallel Notion databases of unclear necessity. Harvest is on a six-month forcing function with a rumored 5x price hike at renewal.

P11 · Onboarding

Onboarding is "HUGE"

The strongest pain language across the entire audit came from the sales call about onboarding and replacing team members on engagements — both for new hires and for sabbatical / PTO cover.

"Onboarding other team members on an engagement for coverage/replacement. Getting new people up to speed. HUGE need."Sales meeting notes

P12 · AR

AR chasing runs entirely on humans

Peke and Jade work the late-invoice queue by hand — Mondays and Thursdays — pulling Harvest exports, identifying open invoices, drafting emails, escalating to PMs.

"This is all things that could be automated, you know, when there's a late invoice in harvest with a certain time frame, it could create an email in the accounting inbox."Elia, Meeting 3

02 · House in order

The biggest moves to make first

If Four Kitchens lands these five categories of work — independent of anything we eventually build — you're in a substantially stronger operational position. We're not naming specific steps inside each category here. We're naming the categories where the highest leverage sits.

Move 01

Settle who owns what

Right now critical operational work depends on too few people, and there's no documented backup path when those people are unavailable. Elia's upcoming sabbatical exposes this directly. Naming owners — and documented backups — for the major operational processes is the single biggest move you can make to reduce fragility.

Addresses P1 Reconciliation P6 Bus factor P11 Onboarding
Move 02

Capture what isn't being captured

Several signals that should be flowing into your systems aren't — win/loss reasons after RFP close, estimation actuals at project close, projection updates on time, AR aging. The captures themselves are small. The historical record they build over time is what makes everything that comes after possible.

Addresses P2 Win/loss P3 Estimation P4 Projections P12 AR
Move 03

Declare what's canonical

Hours, contract terms, project status, and key operational terms (won, lost, healthy, at-risk, profitable) don't have a single authoritative source today. Picking one for each — and writing down what the key words mean — eliminates silent ambiguity downstream and is the precondition for anything that needs to read across your systems.

Addresses P9 Canonical P10 Tool stack
Move 04

Standardize where it matters

The PM team is solving the same problems with different templates, different agendas, different recording habits. Picking canonical versions for client reporting, stand-ups, retros, and the recording policy makes the team faster — and unlocks an entire class of automation that's blocked today by per-person variance.

Addresses P7 PM variance P8 Recording
Move 05

Externalize what lives in heads

Reconciliation logic (Beto and Elia), sentiment criteria (Shanice), EBR calculation (Paul), SiBorg's fit logic (Si) — all currently live as undocumented judgment. Writing each one down as a short document is a small ask, but it turns out to be the precondition for almost everything we'd want to help build on top.

Addresses P1 Reconciliation P6 Bus factor P11 Onboarding
03 · What we could build

Where we see the biggest wins

Five high-level opportunities that we think would deliver the biggest impact for Four Kitchens. These are concepts, not specifications — we're not getting into stages, costs, or technology details here. Each one ties back to multiple pain points from Section 1.

Build 01

An account-360 view

A single composed surface for every active engagement — project status, sentiment trajectory, engagement temperature, pipeline weighting, revenue contribution, and overall health all in one place. Includes a reconciliation agent that runs against your documented runbook and resolves the cases it can without human intervention. Lands as the working surface for the Projects Roundtable and for pipeline conversations where the holistic view doesn't exist today.

Addresses P1 Reconciliation P4 Projections P5 Account view P6 Bus factor
Build 02

An onboarding and cover agent

A conversational agent that answers the questions a new hire would ask — or that a teammate covering for someone who's out would ask. Draws on your canonical sources, the externalized tacit knowledge, and the ownership map. One surface, four real use cases: new-hire onboarding, sabbatical cover, PTO cover, same-day cover. Directly addresses what you named in the sales call as a "HUGE" need.

Addresses P6 Bus factor P9 Canonical P11 Onboarding
Build 03

SiBorg evolution

Two things stitched together. First, closing the loop — feeding estimation actuals back into Si's existing SiBorg instance so it gets smarter over time. Second, automating the remaining manual seam — Si's copy-paste from SiBorg's generated table into your brand template. SiBorg's single-instance design stays exactly as it is; this builds around it rather than replacing it.

Addresses P2 Win/loss P3 Estimation
Build 04

AR automation

An agent that watches Harvest for invoices past their terms, drafts emails into the accounting inbox or Slack-escalates to PMs per the ownership map, and surfaces a weekly snapshot to Peke and Jade. Preserves the existing oversight model — humans still approve before things send — and takes the manual work out of the loop. This is exactly the shape Elia named in Meeting 3.

Addresses P4 Projections P12 AR
Build 05

Reporting and meeting intelligence

Two things, working together as one system. First, one AI reporting agent that produces every client report from a canonical template — replacing the eleven hand-tuned variants that exist today. Second, transcript analysis across all recorded client meetings — sentiment, action items, summaries, follow-up tracking, relationship trajectory. Both depend on the standardization and recording work in Section 2 landing first.

Addresses P7 PM variance P8 Recording
04 · Going deeper

Two areas we want to dig deeper

Across our five touchpoints we focused mostly on operations, leadership, biz dev, delivery, and account management. Two production-side surfaces got lighter coverage than we'd like, and we'd appreciate the chance to dig in with you — either in the time we have today or in a follow-up.

AI in your design workflow

What we know already

Figma is in your stack. Design is not a heavy services surface for Four Kitchens, but it's still real production work that touches almost every engagement. We didn't observe anything substantive about how designers use AI in their day-to-day.

What we'd like to understand

How designers use AI tools today — what's producing leverage, what's creating friction, what's being deliberately avoided. Where AI shows up in iteration, exploration, asset generation, brand-consistency checking. Whether the design workflow is meaningfully different across senior and junior designers, or across engagement types.

Why it matters

The design surface affects what shape of brand or asset work would actually be useful from us — and how design connects to the proposal and SiBorg flow. The brand-template handoff Si currently does manually, for example, intersects with the design layer.

AI in your development work

What we know already

WordPress and Drupal are your primary CMS surfaces. We've seen AI show up in operational workflows — Joanna's Harvest aggregation, Beto's scorecard formulas — but production code workflows are largely unobserved. Si referenced the engineering-review step as where the trust dynamic around SiBorg's estimates lives, which is adjacent to dev AI but distinct from it.

What we'd like to understand

How AI shows up in code writing, code review, testing, and deployment. Team adoption patterns across senior and junior engineers. Posture on AI-written code — review depth, when it's acceptable, when it isn't. Security and client-confidentiality considerations on AI tooling that touches client codebases.

Why it matters

The development surface affects how any AI tooling we eventually build gets extended and maintained over time. It also connects to the specialist-trust dynamic Si named around SiBorg estimates — the broader posture on AI in dev work shapes whether and how that trust can be closed.

05 · Open questions

Gaps we'd like to close with you

A small set of questions that came out of working through Sections 1 through 3. Answering these — even partially — sharpens what we'd propose next and makes the next conversation more concrete.

How does Paul actually calculate per-service-line profitability?

This is the deepest tacit unknown across the engagement. Until we understand his method, we can't size what a profitability layer would look like.

What's the actual volume of late invoices?

Roughly how many per month, and what's the average aging? It affects whether AR automation is a meaningful build or a smaller one.

Have you started looking at Harvest successors?

If so, what constraints matter most — feature parity, integration depth, cost, something else? Whatever you pick affects every hours-anchored build downstream.

Is mandatory client meeting recording on the table?

Or is strongly-encouraged the ceiling? The answer shapes what's possible on the transcript-analysis side — full coverage opens up a lot, partial coverage opens up less.

How much Notion consolidation are you up for?

Of the parallel Notion databases (engagement, scorecards, client-success-scoring, partners), which feel like they need to stay distinct, and which could merge or retire?

Does Si track SiBorg accuracy informally?

Even a directional sense — "consistently within 10%" vs. "sometimes way off" — helps us calibrate how impactful the feedback loop would actually be.

The engagement-type-vs-risk pattern Beto named — true and stable?

In Meeting 3 Beto observed that bad engagements cluster in fixed-fee and T&M, while CC and Staff Aug are mostly positive. We'd like to confirm this and understand the mechanism — scope creep, expectation mismatch, something else?