What is a customer context graph?
Most feedback tooling stores feedback as rows: a message, a tag, maybe a linked ticket. A customer context graph stores it as relationships: topics, customers, and companies linked across sources, with the original quotes attached. The difference sounds academic until you ask a question that crosses a boundary — "who else hit this, and what do they pay us?" — and the rows can't answer it.
We build Modem, which is built around a context graph, so read this as the people selling the idea explaining the idea. The concept stands on its own, though, and you can get partway there with discipline and a spreadsheet.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionThe three link types that matter
A context graph does three joins that a flat feedback list doesn't.
The same issue across channels. A complaint about export timeouts arrives as a Discord thread, two Zendesk tickets, and an offhand line in a sales call. In a list, that's four items with four tags if someone was diligent. In a graph, it's one topic with four sources — and the count is the point. Prioritization runs on "how many, and who," and a list that stores duplicates as separate rows systematically undercounts everything that arrives through more than one door.
The same person across identities. The user who emails support and the user who posts in your shared Slack channel are often the same person with two identifiers. Linking them is what makes "who asked" answerable — and closing the loop possible, because you know exactly which conversations to reply into when the fix ships.
The person to the company, and the company to its context. B2B prioritization needs the request tied to the account: plan, ARR, renewal date, open opportunities. That's what turns "12 people asked" into "12 people asked, eight of them at accounts up for renewal this quarter" — the revenue-weighted view that a standalone feedback inbox can't produce.
Why a tag taxonomy isn't a graph
Tags are labels on rows; they classify, but they don't connect. Two tickets tagged exports still don't know they're the same customer, and the tag carries no memory of what was actually said. When someone asks "what specifically breaks for enterprise customers in exports?", a tag system returns a pile of tickets to re-read. A graph returns the topic, the people on it, their companies, and the quotes — because the connections were made at capture time, not reconstructed at question time.
That's also why building one manually decays. The joins have to happen on every new message — dedupe against existing topics, match the sender to a known person, link the person to the account. Done by hand, it's the triage work that slips first in a busy week, and a graph with stale joins quietly degrades back into a list.
What having one changes
Counting becomes real. Topic sizes reflect every channel, not just the one your tooling watches, which changes what quantified feedback actually ranks.
Insight questions become lookups. "What are the top complaints from customers on the enterprise plan since the last release?" is a query against the graph, not a research project across four tools.
Agents get somewhere to stand. This is the part that's new. A coding agent asked to fix a customer-reported bug is only as good as its context. Pointed at raw channels, it burns tokens re-reading threads and still misses the Zendesk half of the story. Pointed at a context graph over MCP, it queries the merged topic — sources, repro details, affected accounts, original quotes — and starts from the full picture. The same applies to Claude Code, Cursor, or Devin answering "what do customers say about X": the graph is the difference between an answer grounded in what customers said and a confident guess.
The loop closes itself. Because requesters are linked to topics and topics to the shipped work, "tell everyone who asked" is a traversal, not an archaeology dig.
The smallest version you can start this week
You don't need software to start thinking in graph terms. Pick your top five feedback themes and, for each, write down every place it has appeared and every named person who raised it, with their company. That's a context graph with five nodes, maintained by hand — and it will change your next prioritization conversation, because you'll argue from counts and accounts instead of anecdotes.
The honest caveat is the maintenance: the hand-built version stops being true the week you stop updating it. That's the part Modem automates — the graph builds and stays current from the channels themselves — but whether you automate it or not, the structure is worth having. Feedback is only as useful as the connections between the pieces.
