Knowledge, Supplier and Relationship Management

Most ITIL practices are about the work itself: restoring service, making changes, fulfilling requests. The three practices on this page are about the people and organizations around that work. They are less visible than incident management, but when they are missing, everything else gets slower and more fragile. The examples follow Kestrel Energy, an energy supplier with about 2,000 employees, a customer portal and mobile app, a billing system, a service desk, a network operations center (NOC) and several outside suppliers.

Knowledge management

At 08:10 on a Monday, Mei on Kestrel's service desk gets her third call that week about the mobile app refusing to log in after a phone update. Her colleague Amara solved the same thing last Thursday, but the fix lives in Amara's head and in a closed ticket nobody can find. Mei spends twenty minutes rediscovering it. Knowledge management is the practice that prevents exactly this: it makes sure useful knowledge is captured, organized, kept up to date and easy to find, so that people can make good decisions and solve problems without starting from zero every time.

Data, information and knowledge

The words are often used loosely, but the difference helps:

• Data is raw facts without context: "error 4012", "iOS 26.1", "08:10".
• Information is data given meaning and context: "since Thursday, 37 users on iOS 26.1 get error 4012 when they log in to the app".
• Knowledge is information combined with experience so that someone can act on it: "error 4012 after an iOS update means the stored login token is invalid; signing out and in again in the app fixes it".

Models such as the DIKW pyramid (data, information, knowledge, wisdom) add a fourth layer, wisdom: knowing when and why to apply what you know. You do not need the model to see the point: a dashboard full of data is not yet knowledge.

Knowledge also comes in two kinds. Explicit knowledge can be written down and shared: a procedure, a configuration value, a known workaround. Tacit knowledge sits in people's heads and hands: how Amara can tell from the sound of a call which customer is about to escalate, or which supplier contact actually answers the phone at night. Tacit knowledge is shared mostly by working together — pairing, shadowing, reviews after incidents — and part of it can be turned into explicit knowledge over time. When an experienced colleague leaves, tacit knowledge is what the team loses first.

The knowledge base and knowledge articles

A knowledge base is a searchable collection of knowledge, usually built into the ITSM tool or an intranet wiki, that agents, engineers and often users themselves consult. Its building block is the knowledge article: one short, self-contained document that answers one question or solves one issue, written so that the reader can act on it. Good articles use the words a user would use when searching, not only the internal jargon, and they show who owns them and when they were last checked.

KB-0412 Mobile app: "Error 4012" when logging in after a phone update
Status:     Published (internal + self-service)

Symptom     After updating iOS or Android, the Kestrel app shows
            "Error 4012 – session could not be verified" at login.
            Password reset does not help.
Cause       The phone update invalidates the stored login token.
            The app does not request a new token automatically
            (known error, see problem PRB-0087).
Resolution  1. In the app: Menu > Account > Sign out.
            2. Close the app completely and open it again.
            3. Sign in with the usual email address and password.
            If the error remains, log an incident and attach a screenshot.
Applies to  Kestrel app 5.3.x on iOS 26 and Android 16
Owner       Mei Chen (service desk, mobile apps)
Review date 2026-12-01
Feedback    Helpful 41 · Not helpful 3

The article links to a problem record: the problem management team is working on the cause, and until it is fixed, this article is the documented workaround. When the fix ships, the article is updated or retired.

Knowledge-Centered Service

Many knowledge bases fail the same way: someone launches a documentation project, a few hundred articles are written in a month, and a year later half of them are wrong and nobody trusts them. Knowledge-Centered Service (KCS) is a method from the Consortium for Service Innovation, a non-profit group of support organizations, that takes a different approach: knowledge is created and improved as a by-product of solving issues, by the people who solve them.

KCS describes two connected loops. The Solve Loop happens in the daily work: while handling a ticket, the agent captures the issue in the user's words, structures it into a simple article format, reuses an existing article if there is one, and improves it on the spot if something is missing or wrong ("search early, search often; reuse is review"). The Evolve Loop works at the level of the organization: looking at the health of the knowledge base as a whole, building KCS into processes and tools, measuring and coaching. In practice, KCS is a long-term change in habits, not a tool feature; organizations that adopt it usually start with one team.

Keeping knowledge current

An outdated article is worse than no article: it sends people confidently in the wrong direction. Three habits keep a knowledge base trustworthy:

• Owners. Every article has a named owner (a person or team), not "IT".
• Review dates. Articles are reviewed on a schedule that fits how fast the subject changes, and after every relevant change, release or supplier switch.
• Feedback. Readers can flag an article as wrong or unclear with one click, and those flags go to the owner, not to a mailbox nobody reads.

Measuring whether knowledge is used

The number of articles says little. More useful questions are: how many tickets were solved with an article linked; how often do users solve an issue themselves in the self-service portal after reading an article; which searches return nothing; which articles are flagged most. Knowledge is what makes shift-left possible: work that once needed second line can move to the service desk, and work that once needed the service desk can move to self-service, only when the knowledge moves with it.

Supplier management

No IT organization does everything itself. Kestrel's customer portal runs at a public cloud provider; the billing system runs on Kestrel's own servers in a rented colocation data center; a telecom carrier provides the links between the offices, the data center and the internet, and the phone lines of the customer contact center. If any of them fails, Kestrel's customers experience it as Kestrel failing. Supplier management is the practice of selecting suppliers, agreeing what they deliver, managing the relationship and their performance, and making sure the products and services bought from them support what the organization has promised its own customers. It is the practical side of the partners and suppliers dimension.

Sourcing models

Sourcing is the decision who does a piece of work:

• Insourcing: the organization's own staff do the work. It gives the most control and keeps knowledge in house, but the organization carries all the cost of skills, tools and capacity.
• Outsourcing: an external supplier performs work or provides a service that the organization used to do, or could do, itself — such as running the data center, the service desk or application maintenance. Responsibility for the outcome toward the organization's own customers stays with the organization.
• Multi-sourcing: the organization buys services from several specialized suppliers instead of one large contract — one for cloud hosting, one for the network, one for workplace support. Each supplier can be the best in its area, but someone has to make the pieces work together.

That "someone" is the subject of service integration and management (SIAM): an approach for managing many suppliers as if they delivered one integrated service. A service integrator — an internal team or an external company — coordinates processes that cross supplier boundaries, such as incident handling, changes and reporting, and holds suppliers to shared rules, so that an incident does not bounce between the cloud provider and the carrier while each says "not our side".

Contracts and underpinning contracts

A contract with a supplier is more than a price. It states what is delivered, the service levels, how performance is measured and reported, how incidents and changes are handled across the boundary, security and data protection obligations, liability, and how the contract ends. When a supplier's service is part of a service that Kestrel promises to its own customers, that contract is an underpinning contract: the agreed response time and availability in it must be good enough to support Kestrel's own service level agreements. How these agreements fit together is explained in service level management.

Supplier performance reviews

Ana, Kestrel's supplier manager for infrastructure, meets each major supplier on a fixed rhythm — monthly for the carrier, quarterly for the data center. The review looks at the agreed measures (availability, response and fix times, incidents caused by the supplier), open problems and planned changes, invoices and disputes, and what is coming next on both sides. The supplier's own reports are compared with Kestrel's measurements, because a supplier measuring itself tends to look good. A good review is a working meeting with actions and owners, not a slide show.

Supplier risks

• Dependency and lock-in. When a service is built on a supplier's proprietary features, leaving becomes expensive and slow; see vendor lock-in. That is not always wrong, but it should be a conscious choice.
• Supply chain risk. A supplier with access to your systems or software is a way in for attackers; see supply chain attacks. Ask about their security, and limit their access to what they need.
• Financial and continuity risk. A supplier can go bankrupt, be taken over or stop a product.
• Concentration risk. Several "different" suppliers may depend on the same cloud region or the same subcontractor.

Exit planning

Every supplier relationship ends one day. An exit plan, agreed while the relationship is still good, describes how data is returned (in which format, how fast), how the supplier helps during a transition, what knowledge and documentation they hand over, and what it costs. Negotiating these terms during a dispute, with a deadline, is far harder.

Relationship management

The billing department at Kestrel is unhappy with IT. Every month, the run that produces customer invoices is slow, and the IT reports say everything is green. Nobody in IT knows that the finance director plans to move billing to a software-as-a-service product next year because of it. Relationship management is the practice of building and keeping good working relationships with stakeholders: understanding what they need and value, agreeing priorities with them, and dealing with tensions before they turn into distrust.

Stakeholders

A stakeholder is any person or group that has an interest in, or is affected by, an organization, product or service — or by a decision about it. For Kestrel's IT department that includes the business units that use its services (customer contact, billing, field engineers), sponsors who pay, the users of the portal and app, suppliers, regulators, and IT's own staff. Stakeholders differ in influence and interest, and what one group values (a fast release of a new app feature) can conflict with what another values (a stable billing run at month end). A simple stakeholder map — who they are, what they care about, how much influence they have, who talks to them — is often the first useful step.

The business relationship manager

Many organizations give relationship management a face: a business relationship manager (BRM), sometimes called account manager or IT business partner. Nadia is Kestrel's BRM for finance. She meets the finance management team regularly, knows their plans and pain points, translates them into requests and priorities for IT, and explains IT's constraints back to them. She does not fix things herself; she makes sure the right people are talking about the right things. Had Nadia been in place, the billing complaint above would have surfaced months earlier.

Trust, needs and conflict

• Trust is built through doing what you said, telling bad news early and being open about what IT can and cannot do. It is lost much faster than it is gained.
• Identifying needs means asking about outcomes ("finance must send correct invoices by the 3rd of the month"), not only about features ("a faster server").
• Managing conflict means making competing demands visible and letting the people with authority decide, with the facts on the table, rather than letting the loudest stakeholder win.
• Customer satisfaction is measured with surveys after tickets, periodic reviews and, increasingly, experience measures. Low scores next to green SLA reports are a signal that the measurements miss what people care about — the watermelon effect described in service level management.

How the three connect

The three practices reinforce each other. Supplier reviews produce knowledge (how to escalate to the carrier at night, which known issues the cloud provider has) that belongs in the knowledge base. Relationship management tells IT what stakeholders need, which shapes what is bought from suppliers. And a knowledge base that users can search themselves is one of the most visible ways to build trust with them.

Where they sit in ITIL

In ITIL these are three of the 34 management practices. Study material for ITIL (Version 5) commonly lists all three among the general management practices — practices that come from general business management and apply far beyond IT — rather than among the product and service management practices. ITIL 4 also placed them in its general management group. Supplier and relationship management are part of one of the new Practice Manager certifications (Collaborate, Assure and Improve), together with service level management, continual improvement and information security management. The practices themselves are not examined individually at Foundation level.