Concepts make more sense when you watch them play out in a single sustained story. This case study follows one team — a mid-sized software company's customer support organization — from the problem that pushed them toward a knowledge graph, through the messy middle, to a measurable result. The team and details are a composite drawn from common patterns, not a single named company, but every decision and failure mode here is one that recurs in real projects.
The arc has four acts: the situation that created the need, the decision to build a graph (and the alternative they rejected), the execution including a false start, and the outcome with the lessons that generalize. If you want the principles abstracted out, our framework article formalizes the approach this team stumbled into. Here, we stay in the story.
The Situation: Answers Existed, But Nobody Could Reach Them
The support team had a recurring frustration. When a customer hit a problem, the answer often existed somewhere — in a past ticket, a documentation page, an engineer's Slack message, a known-issue tracker — but no one could connect those pieces. An agent might spend an hour rediscovering a workaround that a colleague had documented six months earlier under different wording.
The core pain was not missing information. It was disconnected information. The same product feature was called three different things across the help docs, the ticketing system, and the engineering tracker. A search for one name missed everything filed under the others.
Why Their Existing Tools Failed
- Full-text search matched words, not concepts, so the three names for one feature never linked.
- The ticketing database stored tickets as flat rows with no relationship to docs or known issues.
- Tribal knowledge lived in senior agents' heads and walked out the door when they left.
The questions they actually needed answered — "what's connected to this feature across all our systems" — were relationship-shaped. That's the signal that pointed toward a graph.
The Decision: Graph Versus Better Search
The team seriously considered just buying a better search tool. It would have been cheaper and faster to deploy. They rejected it for one reason: search would still treat the three names for one feature as three unrelated terms. It couldn't represent that a documentation page, a ticket, and a known issue were all about the same feature.
A knowledge graph could. By making each feature a single resolved node and connecting tickets, docs, and issues to it, the graph would let an agent start at a feature and reach everything related in one traversal. The deciding question was the one from our common mistakes guide: do the highest-value questions traverse multiple relationships? Here they clearly did.
The Execution: A False Start and a Recovery
The team's first attempt failed, and the failure is instructive.
The False Start
They began by ingesting everything — every ticket field, every doc, every Slack export — and modeling it faithfully. Within two weeks they had a graph with dozens of node types that mirrored their source systems and answered no question cleanly. It was the classic mistake of modeling the data instead of the questions. Queries were as painful as the silos they'd hoped to escape.
The Recovery
They stopped, deleted the model, and wrote down three questions:
- What docs, tickets, and known issues relate to this feature?
- Which features generate the most unresolved tickets?
- When a feature changes, what content needs updating?
From those, only four node types survived: Feature, Ticket, Doc, and KnownIssue. Two edge types — about and resolved-by — covered the relationships. The rebuilt graph was a fraction of the size and answered all three questions immediately. This question-first rebuild mirrors the process in our step-by-step guide.
The Hard Part: Resolving Feature Names
The real work was entity resolution. Three names for one feature had to collapse into one Feature node. The team built a small mapping — partly manual for the high-traffic features, partly fuzzy-matched for the long tail — and routed uncertain matches to a human queue. This step took longer than the modeling, exactly as it should have.
The Outcome: Measurable and Honest
After the rebuild, the team tracked one metric closely: time to find a relevant prior answer. Agents who used the graph could start at a feature node and reach related tickets and docs in a single step, instead of running separate searches across systems with mismatched terms.
The honest accounting also includes costs:
- The graph needed maintenance. New features and renamed ones required ongoing resolution; without it, the name-collision problem would have crept back.
- Aggregation questions were awkward. "How many tickets per region per month" still ran better in their existing reporting tool, so they kept it.
- Adoption required training. Agents had to learn to think in terms of starting from a feature, not typing a keyword.
The team didn't replace their warehouse or their search outright; they added a graph for the connected questions those tools handled poorly. That restraint is part of why it worked.
What Adoption Actually Looked Like
A working graph that nobody uses is still a failure, and the team nearly hit that wall. Their first instinct was to expose the raw query interface to agents, expecting them to write traversals. That flopped — agents are support specialists, not query authors, and asking them to learn Cypher under time pressure was a non-starter.
The fix was to hide the graph behind the workflow agents already used. Inside the ticketing tool, a sidebar showed "related across our systems" for the feature on the current ticket — populated by a traversal the agent never saw. The graph did the connecting; the agent just read the results. Adoption climbed only once the graph stopped looking like a database and started looking like a helpful panel.
The lesson here is one teams routinely miss: the people who build a graph think in nodes and edges, but the people who benefit from it usually shouldn't have to. The traversal is plumbing. The interface should speak the user's language, not the graph's. A graph that demands its users learn a query language will be abandoned no matter how good its answers are.
The Lessons That Generalize
Three takeaways from this story apply to nearly any first graph project. First, the question-first rebuild was the turning point — the data-first version was doomed, and starting over was cheaper than rescuing it. Second, entity resolution was the real project; the modeling was almost trivial by comparison. Third, the graph earned its place by complementing existing tools, not replacing them. A team that expects a graph to do everything will be disappointed; a team that deploys it precisely for relationship-shaped questions will see it pay off.
Frequently Asked Questions
Why did the first attempt fail so completely?
They modeled their source data faithfully instead of modeling the questions they needed answered. That produced dozens of node types mirroring their silos, which made the graph as hard to query as the systems it was meant to unify. Deleting it and rebuilding from three questions was faster than trying to salvage the sprawl.
Was entity resolution really the hardest part?
Yes, and that's typical. Collapsing three names for one feature into a single node — manually for high-traffic features, with fuzzy matching and a review queue for the rest — took longer than designing the model. In most real graph projects, resolution is where the genuine effort lives.
Why didn't they replace their existing search and reporting tools?
Because those tools were good at what they did. Search handled simple lookups and reporting handled aggregations, both of which graphs do less well. The graph was added specifically for connected, multi-hop questions the other tools couldn't answer. Replacing everything would have traded strengths for weaknesses.
How do I avoid the same false start?
Write down three to five concrete questions before modeling anything, and let only those questions justify your node and edge types. The team's recovery was exactly this move. Starting question-first would have saved them the wasted first attempt entirely.
Did the graph need ongoing maintenance?
Yes. New and renamed features required continual entity resolution, or the name-collision problem would have returned. A knowledge graph is a living system, not a one-time build. Budgeting for that maintenance is part of deciding whether a graph is worth it.
Key Takeaways
- The team's pain was disconnected information, not missing information — a classic graph signal.
- A data-first first attempt failed; a question-first rebuild with four node types succeeded.
- Entity resolution (collapsing three feature names into one node) was the real work.
- The graph complemented existing search and reporting rather than replacing them.
- Knowledge graphs require ongoing resolution maintenance to stay correct over time.