Data vs Information vs Knowledge: The Difference, With Examples

Data vs information vs knowledge is easiest to see in one example. A contact center logs 450 tickets on a Tuesday, and that number is data. Thirty-five percent of them are password resets between nine and eleven in the morning, which is information. The reason is that the Monday night release changed the login screen. The fix is a one-line banner on the login page plus a script for agents, and that is knowledge. Same tickets, three different things.

The data vs information vs knowledge distinction sounds academic until a team confuses the three, which happens constantly. People call dashboards full of data insight. They call a knowledge base full of information knowledge, and then wonder why agents still ask the person next to them. This guide keeps the three apart with one running example, a comparison table, and eight more examples from ordinary work.

Data vs information vs knowledge in one sentence each

Start with data. It is any recorded fact with no context: a number, a timestamp, a transcript, a click. Once someone organizes that data so it means something, such as a count by category or a trend over time, it is information. And information a person can act on, because they understand why it is true and what to do about it, is knowledge.

The three sit in a hierarchy, and each level depends on the one below. You cannot have information without data to organize, or knowledge without information to understand. People usually draw the hierarchy as a pyramid with data at the bottom. Some versions add a fourth level, wisdom, for knowing which knowledge to apply. Most business work happens on the first three, so this guide stays there.

The difference between data, information and knowledge

Two rows in that table cause most of the trouble. The first is “where it lives”. Systems can hold data and information. Knowledge lives in people until someone writes it down in a form that another person can follow, which is the entire job of knowledge management. The second is “shelf life”. Numbers move and the information goes stale. When the product, the policy or the customer changes, the knowledge goes stale too, and nothing in the data warns you.

Eight examples of data vs information vs knowledge

Each example runs the same fact through all three levels, so the jump from one to the next is visible.

Examples 1 to 4: recordings, analytics, sensors and surveys

1. Call recordings. The data is two thousand hours of audio; the information is that average handle time rose from six to eight minutes in July; the knowledge is that the rise came from one new billing plan whose terms agents could not explain, so the fix is a plan comparison article rather than a coaching program.
2. Website analytics. Here the data is forty thousand page views; the information is that the refund policy page is the second most visited page after the home page; the knowledge is that customers cannot find the refund button in the app, so the page is a symptom and the app is the fix.
3. A thermometer. In this case the data is 23, 30, 28, 35; the information is that last week’s average was 29 degrees, five above normal; the knowledge is that at this temperature the server room cooling fails within two hours, so the maintenance window must move.
4. Survey responses. Start with twelve hundred satisfaction scores as the data; the information is that scores drop by two points when an agent transfers the call; the knowledge is that transfers happen because tier one cannot see order history, so give tier one the view and the transfers stop.

Examples 5 to 8: chats, stockrooms, searches and wards

1. Chat transcripts. Again the data is plain text, nine thousand chats of it; the information is that the phrase “still waiting” appears in one chat in eight; the knowledge is that the delay is the identity check, which asks three questions where one would do, so the check is the thing to redesign.
2. A retail stockroom. This time the data is barcode scans; the information is that item 4471 sold out in three stores on Saturday; the knowledge is that it sells out every time a particular show airs, so order ahead of the next episode.
3. Agent searches. For a knowledge base, the data is fifteen thousand search queries; the information is that the top query returns zero results; the knowledge is that agents use the customer’s word for the product rather than the internal name, so the article needs a synonym, not a rewrite.
4. Hospital readmissions. Finally, the data is admission and discharge dates; the information is that readmissions within 30 days are highest for one ward; the knowledge is that this ward’s discharge instructions are the only ones nobody translated, so translation, not clinical change, is the intervention.

In every case the data was already there and the information took an afternoon, but the knowledge took someone who understood the operation. That is the level a knowledge base has to capture, and it is the level most of them miss.

How data becomes information, and information becomes knowledge

The first jump is mostly mechanical. Collection, cleaning, grouping and analysis turn data into information, and software does most of it. A report that shows tickets by category and hour is information, and producing it needed no human judgment.

The second jump is not mechanical. It happens when a person interprets the information, tests the interpretation, and writes down what to do. The password reset example needed someone who knew about Monday’s release. The chat example needed someone who had sat through an identity check. Analytics tools cannot supply that step, though they can shorten the path to it by making the information findable.

This is why a knowledge management process has a capture stage separate from a reporting stage. Reporting turns data into information on a schedule. Capture turns what experienced people know into articles and guided steps that a new person can follow. Skip capture and the knowledge stays in the heads of the ten people who have been there longest, which is fine until two of them leave in the same month.

Why the difference matters for a knowledge base

Ask what a knowledge base holds and most people say knowledge. Look inside one and it usually holds information: product specifications, policy text, feature lists. All true, all organized, and none of it tells an agent what to do when a customer with plan B asks for a plan A feature.

The gap shows up in the numbers. The McKinsey Global Institute estimated in its 2012 report on the social economy that interaction workers spend nearly 20 percent of the workweek looking for internal information or tracking down colleagues who can help, and that a searchable record of knowledge could cut that search time by as much as 35 percent. Tracking down a colleague is what people do when the knowledge base has information but not knowledge. Customers do the same thing in reverse: in a Gartner survey of 5,728 customers, 43% of failed self-service attempts happened because the customer could not find relevant content, so they picked up the phone.

Closing the gap means writing articles at the knowledge level. A knowledge-level article names the situation, says what to do, and explains the one exception that catches people out. In a contact center this often takes the form of a guided workflow rather than a document, because a procedure with branches is knowledge in an executable form. Good knowledge base software supports both, and the distinction between the two is the difference this whole article is about.

Different kinds of knowledge also need different containers. Explicit knowledge, such as a refund rule, fits an article. Tacit knowledge, such as hearing that a caller is about to churn, only transfers through examples and practice. The guide to the types of knowledge in an organization covers which container fits which kind.

Data vs information vs knowledge inside a knowledge management system

A knowledge management system handles all three levels. The good ones keep them visibly separate. Search logs and article views are data. The analytics screen that turns them into “most searched, least found” is information. The article an owner writes in response, and the guided workflow that walks an agent through the fix, are knowledge.

That separation is worth checking when you evaluate knowledge management software, because vendors tend to demo the middle level. A dashboard is easy to show. It looks impressive. The harder questions are whether the system makes it easy for an expert to capture what they know as a step-by-step procedure, whether it tells that expert when the procedure has gone stale, and whether an agent can reach the right step during a live call rather than after it. Those are knowledge-level features, and they are the ones that move handle time and first contact resolution.

A quick test for which level you are looking at

Three questions place any document, dashboard or message that lands in front of you.

Does it need interpretation before anyone could use it? If so, it is data. A log file, a raw export and an unlabeled chart are data even when they look sophisticated.

Does it answer “what” or “how many” but not “so what”? If so, it is information. Most dashboards stop here, and that is fine, because that is their job.

Could a competent new hire read it and act correctly without asking anyone? If so, it is knowledge. If the honest answer is “they would still need to ask Priya”, it is information waiting for Priya to turn it into knowledge, and the organization is one resignation away from losing it.

Run that test over your own knowledge base and the results are usually humbling. It is also the fastest way to decide what to write next.

Frequently asked questions about data vs information vs knowledge