Mapping a client account: a worked example
What actually happens between forwarding a year of correspondence and having an account you can navigate. Walked through on the demo account, step by step, including what it cannot do.
Mapping a client account means assembling the colleagues, client-side stakeholders, engagements and capabilities on that account from material the team already produces, linking them to each other, and attaching to every link the document or thread that establishes it. The result is navigable rather than searchable.
The homepage carries a working atlas of a demo account, Northwind Utilities. This article is the commentary on it: what goes in, what comes out, what each stage is doing, and what the process cannot do.
Stage one: what goes in
Northwind is built from 41 documents and 216 emails. That is roughly what an active account produces in a year, and it is not a large corpus by any technical measure. The material is ordinary:
- Proposals, including the ones that lost.
- Delivered reports and the decks that accompanied them.
- Correspondence about scope, timetable and the things that went wrong.
- Internal threads where the team worked out what to recommend.
- Meeting notes, where anyone wrote them.
It arrives three ways, all initiated by someone in the firm. Outgoing mail blind copied to the account's own address. Threads forwarded in after the fact. Documents uploaded in the browser. There is no mailbox connection and no third party system involved, which means the account team decides what the atlas holds, message by message.
Stage two: what gets extracted
From each piece of material, four kinds of thing.
People, on both sides. Colleagues who did the work, and client-side individuals involved in it. Role matters here and is extracted with the person: leading an engagement is different evidence from being copied on it.
The engagement. Which discrete piece of work this material belongs to, and where it sits in the account's history.
Capabilities. What the work demonstrates the firm can actually do, expressed generally enough to be useful in a different context. "Regulatory price control submission", not "Project Meridian phase two".
The links between all of them, each one naming what the relationship is, and carrying the document behind it.
That last part is the difference between an index and an atlas. A fact with nothing behind it is an assertion, and in a firm an assertion nobody can check gets discounted to zero the first time one turns out to be wrong.
Stage three: what it looks like assembled
Open Northwind and there are four groups: colleagues, stakeholders, engagements, capabilities. Every item carries a reference, F1 or S3, so the panel and the board always name the same thing.
Three things are worth noticing, because they are what the assembly bought you.
The running order is meaningful. Within each group, items are ordered by how much proven evidence stands behind them. The colleague who led four engagements sits above the one copied on one. Nobody adjudicated that.
One item is drawn hollow. Decommissioning appears in the capabilities group with nothing behind it. Northwind's own material shows the need. The firm has no delivery evidencing it. Rather than omit the capability, the atlas draws it as a gap, which is the only way an absence can be seen.
Connections light up individually. Open an item and only its own links illuminate, each naming the relationship and its source. This is not a visual flourish. A graph that shows everything at once is a hairball, and the useful operation is almost always "show me this one thing's neighbourhood".
The point of the map is not that it contains everything. It is that you can get from any point on it to the evidence in one step.
The three questions, answered on this account
The test of any of this is whether the three questions become answerable. Walk them through.
Who has worked with this stakeholder? Open the stakeholder. Their links run to the engagements they were involved in, and from those to the colleagues who delivered them. Three hops, each naming a document. What comes back is not "these people are connected", it is a chain of specific facts a partner can check before a meeting.
Have we done this before? Open the capability. Its links run to the engagements that evidence it and the colleagues who led them, ordered by weight. If the answer is no, the capability is hollow and says so, which is the answer that a system built on similarity search cannot reliably give.
What are we not selling them? Compare the capabilities the client's own material shows they need against those the firm has evidence of having delivered for them. The difference is drawn on the map. Decommissioning is that difference, on this account.
What it cannot do
Four honest limits, because an article that only describes what works is marketing.
It does not capture judgement. A partner's read of a room, their instinct about which sponsor actually carries weight, the pattern matching behind a good call: none of that survives, and no system built on documents will preserve it. What survives is the layer beneath, which is who did what, for whom, with what evidence.
Coverage is only as good as the habit. An account team that blind copies diligently gets a rich atlas. One that sends nothing for two months has a two month hole, and the atlas cannot tell you it is there.
Extraction is not perfect. Names get conflated, roles get misread, a capability gets described too broadly. This is why every fact is openable and correctable in two clicks, and why the design does not depend on extraction being right the first time.
A year is not a decade. Northwind is a year of material. An account with fifteen years of history has fourteen of them in mailboxes that will never be forwarded. The atlas starts from the point the firm starts sending, and gets more useful from there.
What the account looks like a year later
The compounding effect is the part that does not show in a demo.
At three months the atlas is a useful reference: who is on the account, what is live. At a year it is the account's memory, and it starts answering questions nobody could answer before, particularly about people who have moved on. At three years it is doing the thing the whole exercise is for, which is telling a partner who has just picked up the account what their firm knows about it.
That last case is the one worth designing for. Average knowledge-worker tenure is around four years, so on any long-running account the person holding the relationship will be replaced several times over its life. The atlas is what the next person inherits instead of a folder and a phone call.
Next: the weekly brief, and why a map nobody opens is worth very little
Sources
This article stands behind sheet 03 on the homepage, The live demo.
Knowledge graphs, explained
Why the questions firms ask about their own work are relationship questions, why relationship questions need a graph, and what that means in practice rather than in architecture diagrams.
D3Proven versus claimed capability
Every capability statement a firm writes says it can do everything. Weighting each claim by the evidence behind it is what makes a capability record able to discriminate at all.
E4The weekly account brief
A system nobody opens is worth nothing. The brief is the answer to that, and there are five things it should contain and several it should not. A working template.
See the argument running.
The homepage carries a working atlas of a demo account, with every fact tied back to the document it came from. Or book a call and we will walk through an account you know.