Build a Knowledge Graph From Calls

To build a knowledge graph is to store knowledge as a network of nodes and named relationships rather than as a list. Nodes are the things that matter; for customer conversations that means calls, questions, objections, answers, audiences and outputs. Relationships are the verbs between them: a call contains an objection, an answer addresses it, an FAQ uses the answer. Properties such as date, frequency, reviewer and source location hang on both. The build takes five steps: write down the questions the graph should answer; turn the nouns in them into node types; turn the verbs into relationship types; define properties; test the model with a handful of sample data to check that every question can be answered. The graph earns its place where a table becomes awkward: Which objection appears in which audience, which reviewed answer belongs to it, and which FAQ or sales assets already use that answer?

My starting point is not a pile of unchecked transcripts. It is a maintained register. The article on the pattern register for call analysis explains how questions, objections and the clearest answers you have actually given are extracted. This guide starts one step later and turns those entries into a network of named relationships. Which role handles which task in my business is collected under AI employees.

What makes a knowledge graph different

A table records rows and columns. A knowledge base makes content searchable. A knowledge graph also puts the relationships between things at the center. Siemens describes the difference this way: in a relational database, relationships between entities are implicit; in a knowledge graph they are explicitly defined. In a graph, the connection is a record of its own, with direction, type and properties, not a reference number in a column.

Neo4j describes a property graph through three building blocks:

• Nodes represent things such as a call, question, objection, answer or FAQ. A node carries one or more labels that assign it to a group, such as Call or Pattern.
• Relationships connect two nodes with a verb such as “was asked in,” “answered by” or “is used in.” According to Neo4j, a relationship always has a start node, an end node, exactly one type and a direction.
• Properties are key-value pairs on nodes and relationships. They store values such as date, frequency, reviewer, validity and source location.

In practice this means the graph can show the calls in which an objection appeared, the answer after which no follow-up question came, the date that answer was reviewed, and the website sections that depend on it. Those are questions along connections, and connections are what a graph stores natively.

Build a knowledge graph in five steps, from question to model

In its modeling tutorial, Neo4j names the use cases as the first step, not the software, in its own words: “What questions are you trying to answer?” The nouns in those questions become nodes, the verbs become relationships:

1. Write down the questions. Three to five questions that cost you work today: Which frequent objections still have no reviewed answer? Which assets depend on an answer I am about to change? Which objection comes up in which audience?
2. Mark the nouns. Objection, answer, asset, audience: those are your node types. Call joins them because every source location sits inside a call.
3. Mark the verbs. “has an answer,” “depends on,” “comes up in.” These become the relationship types, named as narrowly as possible. Neo4j explicitly advises specific names; “belongs to” is almost always too broad.
4. Assign properties. Anything you want to filter or sort by becomes a property: date, frequency, status, last review. Anything you only want to read stays as text on the node.
5. Test with sample data. Five calls, ten patterns, three answers are enough. Then put every question from step 1 to the model. If one remains unanswerable, a node, a relationship or a property is missing.

The model is finished before any tool is installed. You do not have to find the three questions from step 1 alone: in the calls of my community we work through models like this together.

The smallest useful data model

Five node types are enough for a first call register:

The relationships get a direction, a type and, where it helps, properties of their own: a call contains a pattern, with the minute in the conversation on the edge. A pattern affects an audience. An answer addresses a pattern, with the signal on the edge, such as “no follow-up.” An output uses an answer, with the date on the edge. And an answer replaces an older answer. The last one is what tables rarely give you: the chain is preserved, and later you can see which output still hangs on the old version.

Knowledge graph example: from a call to a reusable answer

The following example is constructed with explicitly fictional demo data. Assume five demo calls from a trade business. Three contain the objection, “I don't have time for the setup right now.” The register also contains a demo answer I have reviewed: “We do not start with your entire business. We begin with one narrow workflow and only add the next once the first is stable.”

The five calls become a graph with eleven nodes: five calls, one pattern with the property “frequency 3 of 5, reviewed 21 Sept 2026,” one answer with “version 2, approved,” one audience “trade business, ten to twenty staff” and three outputs: FAQ answer, objection card, content idea. Plus eight relationships: demo calls 01, 03 and 05 contain the objection, each edge with the minute in the conversation. The objection affects the audience trade business. The reviewed demo answer addresses the objection; the edge carries the signal: no follow-up in two of the three calls. FAQ answer, objection card and content idea use the answer. Every edge leads back to a source location or a human approval. The graph does not invent a new truth. It connects evidence-backed elements.

Now the queries you built all this for. In Cypher, Neo4j's query language, nodes are written in round brackets and relationships in square brackets. The question “Which outputs depend on an answer that has not been reviewed for more than six months?” looks like this as a pattern:

MATCH (o:Output)-[:USES]->(a:Answer)
WHERE a.reviewed < date() - duration('P6M')
RETURN o.channel, a.text, a.reviewed

Three questions the demo model answers in one pass:

• Which answers are active in several channels? Answer nodes with more than one incoming “uses” relationship. In the demo graph: one, with three outputs.
• Which frequent objections still have no approved answer? Patterns above your frequency threshold with no incoming “addresses” relationship. In a real register these are the entries with status “open.”
• What do I have to touch when I change the answer? From the answer backwards along “uses” to every output. In a table these are filters with reference numbers and intermediate lists; in a graph it is a path.

Knowledge graph from text: what the model proposes and what you check

Nobody types the nodes and edges in by hand. A language model can make proposals from the pseudonymised register entry: this is a pattern, this is its answer, this call is the source location. That is how a knowledge graph from text comes about. Three rules keep it clean:

1. The model proposes edges, you confirm them. A proposed relationship “addresses” is a hypothesis until someone has read the source location. Uncertain proposals stay flagged.
2. Only from reviewed entries. The graph is built from the register, not from the raw transcript. What is not in the register is not in the graph.
3. Sample check after every run. Models smooth language and like to connect things that merely sound similar. Read ten random edges against their source locations before the run is accepted.

Register, knowledge base or graph?

You do not automatically need a graph database.

• Register: best when a small team maintains a manageable list and filters it by category.
• Knowledge base: best when people ask questions and expect answers with sources. See building an AI knowledge base from calls.
• Knowledge graph: best when the relationships themselves matter, including sources, audiences, dependencies and reuse.

A clean model in a table with a second sheet for the relationships is often enough at the beginning; graph software pays off once its queries create real value.

Five rules for a dependable graph

1. Transfer reviewed entries only. A line does not make a model error true.
2. Name relationships precisely. “Belongs to” is usually too vague, and without direction and date you will later not know what depends on what.
3. Keep sources and approval. Every expert answer needs an origin, owner and review date.
4. Limit personal data. Pseudonymised conversation data remains personal data while attribution is possible.
5. Test real questions. If the graph improves no decision, it is decoration.

For call data, consent and legal basis still come before recording. Local transcription shortens the data path but does not create a legal basis. Read the legal rules for transcribing conversations.

Where Gustav fits

Gustav is my AI employee before the graph. He transcribes locally with Whisper, runs the fixed pseudonymisation pass and builds the pattern register in batches of ten to twenty calls, with a sample review after every batch. He also keeps a ledger that always shows which call belongs to which person, so a deletion request can be carried out. For the graph this means: every call node has a path back to the ledger, and when a call is deleted you can see along the edges which patterns and answers are affected. The knowledge graph is one view of that register. Which tool holds it is your decision: a table, a note system or a graph database, the model stays the same.

The same core produces practical assets: objection handling from real calls, FAQs from customer conversations and a maintained process for AI knowledge management.

Frequently asked questions

What is the difference between a knowledge graph and a knowledge base?

A knowledge base answers questions with a source; a knowledge graph shows what is connected to what. In the knowledge base you search for “no time for setup” and get the reviewed answer with its source location. In the graph you ask in which calls the objection came up and which FAQ sections depend on the answer. Both can grow out of the same register.

What is a knowledge graph, in simple terms?

A network of things and named connections. The things are called nodes, the connections relationships, and both can carry properties such as date or frequency. The difference from a table: the connection is a record of its own with direction and type, not a reference number in a column.

Can AI build a knowledge graph from text?

Propose, yes; decide, no. A language model can propose nodes and edges from a pseudonymised register entry. Whether the edge is correct is checked by a person at the source location, because models like to connect things that merely sound similar. The input is the reviewed register, not the raw transcript.

Which software do I need to build a knowledge graph?

None for the model, and for operation one that matches your queries. Node types, relationship types and properties come together on paper or in a table with a second sheet for the relationships. Only when questions like “What depends on this answer?” come up regularly does a graph database pay off; Neo4j with the query language Cypher is one example.

Is a knowledge graph built from conversations anonymous?

No, as long as attribution exists. Role, industry, date and a verbatim quote can together make a person identifiable again, and the ledger that maps calls to people keeps the personal reference alive in any case. The graph therefore needs a purpose, access control and a deletion deadline just like the register. You only call it anonymous after the attribution is deleted and a reidentification check is passed.

How to carry on

Take three questions your register cannot answer for you in one pass today and write them down. Mark the nouns and the verbs. Then take five entries from your register and lay them out as nodes and edges on a sheet of paper. If the sheet answers the three questions, you have your model; if not, a node type or a relationship is missing.

The register before it is kept by Gustav in my business, with the pseudonymisation pass, batch review and ledger. His package is in my community, and you do not build the first graph there alone: in the calls we work through models together, and a question in a post usually finds someone who has already asked the same three questions. Everything about it is under Community.