Your Business Runs on Preferences Nobody Wrote Down

Last week I wrote about the knowledge base our tools sit on. This week I watched a full-day meeting prove how much never makes it in.

The agenda said vendor quality claims, profit leaks, client onboarding, scaling our support team. That's not what the meeting was about. Every error we reviewed traced back to the same thing: a preference somebody held in their head that nobody had written down.

Three kinds of preferences, specifically.

How each account manager works. One of our AMs has specific apparel tiers for a major client and never uses fitted caps with them. A support teammate pulled fitted caps for a presentation because nothing in the system told her not to. She didn't lack skill. She lacked context that existed in exactly one head.

What each vendor quietly requires. One supplier network routes purchase orders through two corporate entities. Send the order to the wrong one and it bounces back silently, waiting for someone to notice and re-route it through a rep. Nothing warns you. On a rush order, that silence is expensive.

The one that cost us: our best stole vendor changed fabric and color mid-production on a college order because we hadn't specified exact PMS values. We'd assumed them. The vendor covered the redo, but the rule lived nowhere until it cost a reorder: this vendor needs color specs on everything. We opened several quality claims this week alone, and we have no shared record of which vendors have a pattern.

What each client expects without saying. Specific embroidery thread codes so logos match across orders and vendors. Clients who should never see a minimum fee in a presentation. Schools that treat a shade-off stole as a redo, not a discount.

The cost isn't just rework. Our most experienced AMs still process business-card orders because they're the only ones holding this knowledge. Senior people stuck in transactions is the most expensive form of knowledge storage there is.

And it caps growth. Our proof that transfer works is also our bottleneck: one senior AM spent two years teaching her support teammate the preferences and the reasoning behind them. It worked. That teammate now runs claims and sourcing independently. It also means every new hire starts a two-year apprenticeship from zero.

The research says we're typical. Most organizational knowledge is tacit. It lives in people, not repositories. MIT's NANDA study found 95% of enterprise AI pilots showed no measurable P&L impact, and the barrier wasn't model quality or talent. It was systems that don't retain feedback or adapt to context. A lawyer in the study used ChatGPT daily for drafts but refused it for sensitive contracts because it forgets client preferences and repeats the same mistakes. For high-stakes work, she said, she needs "a system that accumulates knowledge and improves over time."

The dividing line isn't intelligence. It's memory.

So we're not launching a documentation push. Documentation projects die. They ask people to stop working in order to describe work, and the descriptions go stale the moment the workflow changes. We're building ingestion instead: capturing preferences inside work that's already happening.

A weekly vendor highs-and-lows call. Thirty minutes, recorded. The transcript gets processed into structured incident records: vendor, PO, issue type, resolution, cost. A claim becomes data instead of a Slack thread that scrolls away, and a vendor with three strikes will trigger a warning the moment someone creates the next PO. The stole rule becomes a prompt at the point of action, not lore you learn by losing money.

Public channels for each AM-and-support pair. The two-year apprenticeship happened in DMs, invisible and unsearchable. In public channels, the daily preference-teaching becomes a corpus that builds itself as a byproduct of work.

Per-AM memory in our sourcing tool. It searches 200+ vendor catalogs. The plan is for the same search to return different results depending on whose work it's supporting, because the right answer is different. Those apparel tiers. No fitted caps for that client.

Years of client presentation decks, pulled in via API. What we showed a client at a given price point becomes a query instead of somebody's memory.

Nobody is asked to stop and document anything. The system listens to the meeting, reads the channel, ingests the deck, and structures what was already being said.

A general knowledge base can't do this. A knowledge base anybody can use is a knowledge base built for nobody in particular. The value shows up when the system knows how this AM works, what this vendor requires, what this client expects. Not just what the company knows. How each person works, and who they're working with.

This is capacity through context. Nobody's job gets automated. The two-year apprenticeship is the benchmark: the system exists to reproduce what those two people built, at scale, without requiring two years per person. The support team gets that context in months. Senior AMs get out of transactions and back to relationships.

We have about 60 days before busy season to get the core running. I'll report back on what holds up and what doesn't.

Someone has to design how knowledge gets in. At most companies, nobody owns that job yet.