Email is already your firm's richest record. It is just unreadable
The document store holds the artefacts. The reasoning, the relationships and the reason things were done a particular way happened in email, where nothing can find them.
A firm's document store holds finished artefacts: proposals, reports and deliverables. The reasoning behind them, the relationships that produced them and the decisions that shaped them happened in email. That makes email the richer record of what a firm actually knows, and the one no system is organised to read.
Ask a firm where its knowledge lives and it will point at the document management system. Twenty years of proposals, reports and deliverables, organised by client and matter, backed up, searchable.
That is the artefact store. It is not the knowledge, and the difference is the whole subject of this article.
What a deliverable leaves out
Take a finished report. It contains the firm's conclusions, presented for a client, at a level of polish appropriate to an external audience.
It does not contain why the scope changed in week three. It does not contain which of the client's directors pushed for a different approach and lost. It does not say that the original methodology was abandoned because the data turned out not to exist, or that the finance lead had to be brought in before anything could be signed, or that the relationship recovered after a difficult procurement because a particular partner made a particular call.
All of that is the knowledge. It is what somebody would need if they picked this client up in three years. And all of it happened in email.
The document store holds what the firm said. Email holds what the firm learned.
Three things email holds that nothing else does
The reasoning. Decisions in professional work are made in threads. The argument, the alternatives, the constraint that made one option impossible, the moment someone changed their mind: none of it survives into the deliverable, because a deliverable is a conclusion, not a record of how it was reached.
The relationships. Who was actually in the conversation, who was copied for visibility, who replied and who stayed silent, who was brought in when it got difficult. A document has an author field, which usually names whoever last saved the file. A thread has a cast.
The timeline. Documents are dated once, at the point of production. A thread shows an engagement developing: when the concern was first raised, how long it took to resolve, what the client's position was before and after. That sequence is often the most useful thing to know and exists nowhere else.
Why nothing reads it
Email is the richest source and the least usable one, for reasons that are structural rather than technical.
It is personal, not organisational. A thread lives in the mailboxes of its participants. When they leave, so does it. The firm never held it in the first place; it held a copy in several people's private space, governed by their filing habits.
It has no structure to search against. A document store has client, matter, type and date. A mailbox has a subject line that stopped describing the contents around the fourth reply, and a thread that includes three unrelated topics, two out of office replies and a lunch arrangement.
Full text search is the wrong instrument. Searching mail for a regulatory term returns every mention, including the forwarded newsletter and the colleague asking what it means. Relevance in email is not lexical, it is relational: who said it, to whom, in what capacity, about which engagement.
The volume is hostile. A single account over a year can produce tens of thousands of messages, most of them logistics. The signal is real and the ratio is terrible.
Deliberate input rather than a connected mailbox
The obvious architecture is to connect to the mail system and index everything. It is also the wrong one, for three reasons.
It puts the entire mailbox in scope, including the personal, the privileged and the irrelevant. It requires the firm to grant a third party standing access to its most sensitive system, which is a due diligence conversation most firms will not have and should not have lightly. And it optimises for volume when the problem is signal.
OrgAtlas takes the other route. Each account has its own address, and material reaches the atlas only when someone in the firm chooses to send it there:
- Blind copy the account address on the way out, so outbound correspondence is captured as it happens.
- Forward a thread that already happened, when something worth keeping has just concluded.
- Upload proposals, reports and notes in the browser, for anything that never went through a mailbox.
There is nothing to install, no mailbox to hand over, and no third party system to connect. The account team keeps working the way it already works.
This costs something and buys something. It costs completeness: material nobody sends is material the atlas does not have. It buys three things worth more. Every item in the record was deliberately contributed by someone in the firm, which is a clean answer to the question of how anything got there. The signal to noise ratio is set by people who know what matters rather than by a filter. And the scope of what the system holds is something the firm decides message by message, rather than something it has to negotiate in a contract.
A system that reads everything has to be trusted. A system that reads what you send it has to be useful.
What gets extracted
From an incoming thread or document, the atlas takes the things that answer the questions firms actually have:
- The people, on both sides, and what role each played in this piece of work.
- The engagement the material belongs to, and where it sits in the account's history.
- The capabilities it evidences, meaning what the firm demonstrably did rather than what it claims to do.
- The links between them, each one naming the relationship and carrying the document behind it.
The last part is the one that makes email usable at all. A fact extracted from a thread and left standing on its own is an assertion, and an assertion nobody can check is worth less than nothing in a firm. A fact that arrives with the thread attached can be verified in one click and corrected in two.
The practical test
Take your largest account. Ask what the firm knows about it, and then ask where each answer came from.
The engagements and the deliverables will come from the document store. Everything that makes the account intelligible, the history, the personalities, the reason the relationship is the shape it is, will come from a person, and if you push, that person will tell you they remember it from an email.
That email still exists. It is in four mailboxes, two of which belong to people who no longer work there.
Next: what a firm should record about an engagement, and what it never does
Sources
This article stands behind sheet 02 on the homepage, How it works.
Why firm CRMs fail
Low adoption is not a training problem. A CRM asks fee earners to convert billable time into administrative time, and in a firm that argument is lost before it starts.
C4What to record about an engagement
A checklist of the twelve things that turn out to matter three years later, why the finance system holds none of them, and how to capture them without a closedown form.
D1Knowledge 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.
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.