There's a common misunderstanding about collaboration diagnosis: surely, to diagnose how a team communicates, you need to read the conversations?
You don't. And if you do, the conclusions usually get worse.
What a diagnosis actually needs
Collaboration diagnosis needs structure, not content. Concretely, these fields:
- Who initiated an interaction with whom
- Through which channel (group chat / email / meeting / ticket / observation note)
- Frequency or strength
- Time (timestamp or period)
That's it. No message bodies, no email subjects, no attachments, no meeting minutes.
Why this holds technically
The core measures in collaboration network analysis — density, degree centrality, betweenness, structural holes, weak ties — depend on exactly two things: the topology between nodes and edge weights.
Content is not a variable in any of their mathematical definitions. Feed message bodies in and not one of them becomes more accurate; you only introduce noise unrelated to structure.
Put differently, reading content is not the stricter option. It's a no-op. An analysis that has seen only metadata and one that has read every message will produce identical structural measures — the former just didn't expose anyone's conversations to a third party along the way.
Why this is required for compliance
Collaboration diagnosis handles data about how employees work. That's a category requiring care even in the most permissive jurisdictions, and wherever personal data protection is taken seriously there's a governing principle called data minimisation: collect the narrowest set of data that achieves the purpose.
"We read the content too, while we were at it" has never been a selling point. It adds nothing to the conclusion while putting the organisation under an unnecessary data liability — and once that content touches personal data, trade secrets or customer records, the exposure is wildly out of proportion to the benefit.
There's a more practical layer too: trust. If adopting collaboration diagnosis requires handing an entire company's chat history to a vendor first, then in most teams the project dies at procurement and never reaches analysis. The boundary isn't a compliance burden. It's the precondition for this work getting done at all.
What it rules out
Being upfront about the limits is more useful than being vague about them. From metadata alone, these are not visible:
- Tone and sentiment. Whether a conversation was warm or tense isn't in the metadata.
- Whether commitments were kept. Someone said "Friday" in a meeting and didn't deliver; frequency and direction won't tell you.
- Decision quality. Whether a decision was right is a content-layer judgement.
- Semantic duplication. What we compute is structural repetition — high-frequency back-and-forth between the same pair, information handed along multiple hops, the same change pushed through several channels. "These two messages are saying the same thing" would require reading them, and is out of scope.
These are deliberate boundaries, not features still to come. A tool claiming to solve structural and content problems at once usually does neither well — and you have no way of knowing what it actually read.
Deployment: content never has to leave your network
A boundary is only meaningful if it can be verified. So where collection happens matters.
The sensible shape: the collection script runs inside your network or on your own machines, and only the relationship JSON is sent to the diagnosis engine. The raw material — chat logs, email, meetings — never leaves your network.
That difference isn't packaging. It decides whether this sentence can go into a contract:
Raw communication content never leaves your network. Collaboration diagnosis reads metadata only: who interacted with whom, when, through which channel, and how often.
Most cloud SaaS vendors can't offer that sentence, because their product shape requires the data to be uploaded first. Which is why putting collection on the customer's side isn't a compromise — it's the default this kind of analysis should have had all along.
In one line
Collaboration diagnosis cares whether the channels between people are open, whether they're single points of failure, and whether they've disappeared. Structure answers all of that.
As for what flows through those channels — that's the team's asset, and it doesn't need to pass through us.
Curious what your own team looks like structurally?
Run it on your own relationship data. Provide members' work relationships, we will analyze only the collaboration' content.