Relationship intelligence for professional services: what it is and what it misses

If your firm is large, you probably already own something in this category. Introhive reports presence in around 40% of the top 20 law firms and 85% of the top 20 accounting firms. Affinity is established among deal-driven firms. Intapp and DealCloud have partnered with BoardEx to map relationship paths to well over a million executives.

That penetration is a fair measure of how badly firms wanted the problem solved, and the category deserves to be described accurately before it is criticised.

What it is and what it fixed

Relationship intelligence platforms sit between a firm's mail and calendar systems and its CRM. They capture interaction data automatically, build a picture of who has been in contact with whom, and infer relationship strength from the pattern and frequency of that contact. Some enrich it with external data on executives and boards.

The problem this solved is real and was the right one to attack. A CRM asks fee earners to record relationships manually, which converts billable time into administrative time, so the busiest partners maintain the thinnest records and the database is emptiest exactly where it would be worth most. Relationship intelligence removed that step entirely for the contact graph. Nobody enters anything. The graph is a by product of email that was being sent anyway.

Credit where it is due: that is the correct design instinct, and it is the same one we started from.

The category got the hard part right. Capture has to be a by product of work, not an activity beside it.

What a firm gets from it

Used well, these platforms answer a genuinely valuable question and support several decisions:

• Warm introductions. Who in the firm can introduce me to this person.
• Relationship coverage. Which client-side individuals have thin coverage, and which are single-threaded through one partner.
• Cross-practice referral signals. Which colleagues are already in contact with a client another practice group is pursuing.
• Departure risk. Which relationships would go with a person if they left.

If your firm cannot answer those today, this category is worth its price and this article is not arguing otherwise.

Where the model runs out

Three limits, in ascending order of consequence.

Frequency is a proxy for closeness, and a weak one

Interaction volume is what the data gives you, so it is what strength gets inferred from. But an associate copied on forty status reports registers strongly, and a partner who sat opposite the finance director in eight steering meetings, half of them face to face, registers weakly.

The systems are aware of this and compensate with heuristics: direction of initiation, reply latency, meeting attendance. Those help. What none of them can do is distinguish contact from delivery, because the mail metadata does not contain that distinction.

It records contact, not what the firm did

This is the substantive gap. A relationship intelligence platform can tell a partner that a colleague knows the finance director. It cannot tell them that the colleague led an eighteen month programme for that director, that the scope changed in month three, that the relationship was difficult during procurement and recovered, or that the director personally commissioned the report they still cite.

That second set is what actually prepares someone for a meeting. The first set gets you an introduction.

It has no view of capability at all

Here is the structural point, and it is the reason we did not simply build another relationship intelligence platform.

Firms ask three questions about their own work: who knows this person, have we done this before, and what should we be selling them. Relationship intelligence answers the first. It has no representation of what the firm can do, so it cannot answer the second at all, and it cannot answer the third, because whitespace requires holding a client's needs against the firm's proven capability and comparing them.

Who knows whom is half of a transactive memory system. The other half is who can do what, and the contact graph has no place to put it.

In the language of the theory this all rests on, the contact graph is a partial account of credibility, the trust that flows between people who have worked together. It says nothing about specialisation, which is the division of expertise, and specialisation is the dimension a professional services firm exists to sell.

The two categories side by side

| | Relationship intelligence | An evidence-based atlas | |---|---|---| | Primary question | Who knows this person | Who knows this person, what did we deliver, what have we never sold them | | Input | Automatic capture from mail and calendar systems | Material the team sends deliberately: forward, blind copy, upload | | Unit of record | Contact and interaction | Colleague, stakeholder, engagement and capability, linked | | Strength signal | Frequency and pattern of contact | Delivered engagements, weighted by role and breadth | | Capability | Not represented | Inferred from delivery, ranked by evidence | | Gaps | Not representable | Drawn explicitly, as whitespace | | Provenance | Interaction metadata | The document or thread behind every fact | | Integration posture | Connects to mail, calendar and CRM | No third party connection; input is sent in |

The provenance difference

One more distinction, which matters more in 2026 than it would have five years ago.

Relationship intelligence produces scores. A relationship has a strength, a contact has a tier. Those are derived numbers, and a user cannot inspect the derivation in any meaningful way. That was acceptable when the output was a suggestion about who to ask for an introduction.

It is not acceptable when systems start answering questions that get acted on directly. A partner about to walk into a meeting needs to distinguish a recorded fact from an inferred one, and the only mechanism for that is provenance: every claim carrying the document behind it, openable in one click.

This is why every link in OrgAtlas names its source, and why capabilities with nothing behind them are drawn hollow rather than omitted. A system that always produces an answer cannot be trusted on the answers you cannot independently check, which are precisely the ones you consulted it about.

Questions to ask either category

Four, and they discriminate quickly.

1. Can it tell me what we delivered for this person, or only who has been in contact?
2. Can it answer whether the firm has done a type of work before, with evidence?
3. When it makes a claim, can I see the document behind it in one click?
4. What does it do when there is no experience? Does the interface distinguish no record from no evidence?

If the honest answer to the first is contact only, you have a relationship tool, which may be exactly what you need. Just do not expect it to answer the other two questions your firm keeps failing to answer.

Next: expertise location, the other half of the map