A 16-person agency, three roles, and one knowledge base

A 16-person intellectual-property agency, seven or eight roles, could name three problems out loud: price competition, prospects who asked for a quote and then disappeared, and staff who added clients on personal WeChat so that when the staff member left, the client left too. It bought a knowledge base to fix them.

What survived, according to the record, was a boundary document signed before any building started. The knowledge base and three role-level SOPs came after that signature, not before. The share is short; most of what a case normally contains is absent, and this page marks the gaps rather than filling them. The gate itself is the finding.

What they bought, and where the money leaked

They thought they were buying a place to put the firm's documents, with a model answering from them. Framed that way the work is collection, chunking and retrieval, and the test is whether answers are correct.

None of the three symptoms points at retrieval. A prospect who leaves after hearing a price is a quoting problem. A client who follows an employee is a customer-ownership problem. A better index fixes neither.

The material does not record where this firm's profit comes from, or which service line carries it — the first section of a proper anatomy is missing here. What can be said without inventing anything: money leaks between a quote and a signature, and between the firm and the individual who holds the relationship.

Both leaks are named by the client and neither is quantified. The quote-to-signature gap is the price war: the work is priced, the prospect compares, the conversation ends. The relationship leak is the personal account: the firm pays for the lead and the employee keeps the contact. There are no amounts, percentages or time windows in the material. A case that supplied a number here would be making one up.

The three maps

Only the power map is partly visible, and that is the useful part. Three roles were singled out: front-line service, a second-line adviser, and a third adviser role. The boundary document says who may quote and who must hand a conversation to a human. That is a decision-rights map for one flow, which is more than most knowledge-base projects ever write down.

The money map is absent, and so is the list of who loses. The second absence matters more than it looks: every boundary that says "you may not quote" takes discretion from a role that had it, and the record never says who that was or what else that person does.

Where the judgement was wrong

This section is empty in the material. The share records a gate installed before any skill was written, and asserts that skipping it causes rework. It does not record a project where the gate was skipped, what the judgement was in week one, or the signal that proved it wrong.

A rule is not a postmortem. The rule is worth keeping; it cannot stand in for missing evidence, and "rework is almost certain" should be read as the sharer's claim rather than a measured rate.

What lived

Three SOPs, one per role, each paired with a skill set. Call timing and the information that must travel with a handover were written into the SOP itself. The client formed an internal AI project group, ran the real business flows through the draft, and confirmed in writing that all of them worked before construction began. The share adds that the SOPs survive a change of tool, reading that as a consequence of describing the flow rather than the software.

None of that is four-week evidence. Confirmation that flows work is a definition-stage test; the four-week rule asks whether the three roles were still using the SOPs four weeks after go-live. The material does not say.

What died

Nothing is recorded. No module was switched off, no role refused the SOP, no skill was replaced. For an anatomy this is a hole rather than a clean sheet: a case with an empty sixth section cannot tell another team what to avoid, which is the only thing that travels between deployments. The six-section anatomy is blunt about it — a case that reports no deaths is a brochure.

The likely explanation is mundane: the share is a method note, not a project log. That is a reason to read it as a rule, not as proof the rule worked.

The gate, as a checklist

Before the first skill is written, get the client to sign five lines:

1. Which role may quote, and up to what amount.
2. Which role must hand over to a human, and at which sentence.
3. What travels with the handover: customer identifier, stage, what was already promised.
4. What the receiving role does with it, in one sentence.
5. Who on the client side signs, and what "works" means — a real customer flow, not a demo.

If the client cannot name a signer, there is a sponsor, not a boundary. The failure mode to avoid is the tempting one: build the skills first, demo them, and let the demo become the boundary. Every later disagreement then turns into rework, which is exactly the cost the document exists to prevent. The personal WeChat account that started this project is a literal shadow system; the boundary document is the first attempt to bring it back inside the firm, and it is worth asking whether the SOP says where the contact lives afterwards.

Case details come from a public share and have not been independently verified.