Every organisation buys things it could, in theory, do itself, cleaning, payroll, cloud servers, a whole call centre. The decision to buy rather than build, and the job of keeping that supplier honest afterwards, is one of the least glamorous and most consequential parts of running operations. Do it well and you free your team to do what only it can do. Do it badly and you have simply moved the problem outside your walls, where you can see it less and fix it slower.

The quick version

  • Vendor and supplier management is the ongoing work of selecting, contracting with, and overseeing the outside parties that deliver goods or services to you, so you get what you paid for, at the quality you need, without nasty surprises.
  • Outsourcing is the bigger decision underneath it: handing an entire function or process to an external provider instead of running it in-house. The classic frame is "make or buy."
  • A service level agreement (SLA) is the part of the contract that says, in measurable terms, what "good service" means, uptime, response time, resolution time, and what happens when the provider misses.
  • The trap is the "watermelon" SLA: green on the dashboard, red underneath. Hitting every target while the people who rely on the service are quietly miserable.

The idea in depth: make or buy is a real economic decision

Outsourcing can feel like a simple cost question, is it cheaper to do this ourselves or pay someone else? It is not. The most durable way to think about it comes from the economist Oliver Williamson, who built transaction cost economics and was awarded the 2009 Nobel Memorial Prize in Economic Sciences "for his analysis of economic governance, especially the boundaries of the firm" (Nobel lecture, 2009). His insight: the price on the invoice is not the whole cost of buying from someone else. There are also the costs of finding the right supplier, writing the contract, monitoring whether they deliver, and the risk of being held to ransom once you depend on them. Those are transaction costs, and they are what tip a decision from "buy" to "make."

Williamson's framework predicts where work should sit using a few attributes of the transaction, chiefly asset specificity (how specialised the thing is to your needs), uncertainty, and frequency. When what you need is generic, easily specified, and widely available, standard cloud storage, office cleaning, the market does the job cheaply and you should buy. When it is highly specific to you, hard to pin down in a contract, and you would be exposed if the supplier walked away, internal production tends to win, because the costs of governing an outside relationship swamp the savings (Williamson, "Outsourcing: Transaction Cost Economics and Supply Chain Management," Journal of Supply Chain Management, 2008).

So the move is: before you outsource anything, ask Williamson's question, not the accountant's. Not "is the invoice cheaper?" but "how specific is this to us, how hard will it be to specify and monitor, and how exposed are we if this supplier fails?" The more you answer "very" to those, the more an apparently cheaper outside price hides a bill you will pay later in management overhead and risk. Generic and easy to monitor: buy. Specific, fuzzy, and high-stakes: think hard before you let it leave the building. This is the same logic the Toolkit explores from the buyer's seat in supply chain, procurement & sourcing and as a standalone choice in build vs buy vs partner.

flowchart TD
  A(["A function to source"]) --> B{"Generic & easy
to specify?"}
  B -->|"Yes"| C{"Easy to monitor
& switch supplier?"}
  B -->|"No, highly specific"| F(["Lean toward MAKE
(keep in-house)"])
  C -->|"Yes"| D(["BUY
(outsource on a clear SLA)"])
  C -->|"No, you'd be exposed"| E(["BUY with care
(deep contract, exit plan)"])
A make-or-buy screen in Williamson's terms, specificity and monitorability, not just price. Leaders Loop

An honest limitation. Transaction cost economics is a powerful lens, but it is not a calculator. The terms, asset specificity, uncertainty, are real but hard to measure precisely, and the theory has been criticised for assuming people behave more opportunistically than they often do; trust and reputation between long-standing partners do real work the model underweights. Use it to structure the decision and surface the hidden costs, not to produce a single "make" or "buy" verdict you then defend against all evidence.

What an SLA is, and the number it quietly distorts

Once you have decided to buy, the SLA is how you keep the relationship honest. A service level agreement defines the level of service expected from a supplier, the metrics by which it is measured, and the remedies or penalties if those levels are missed (CIO, "What is an SLA?"). SLAs emerged as IT outsourcing took off in the late 1980s precisely because "we'll look after your systems" is meaningless until someone writes down what "look after" means in numbers. A workable SLA names the services in scope, the performance targets (uptime, response time, resolution time), how they are measured and reported, the consequences of missing them, and a schedule for review.

It helps to keep three terms straight, because they are routinely muddled. A KPI is a metric you track. An SLA is a metric you have committed to, with a consequence attached. And the related OLA (operational level agreement) is the internal back-to-back promise, your own teams agreeing the response times they need to hit so the external SLA is even possible. An SLA you cannot support internally is a promise made of paper.

Now the warning. There is a well-known failure mode in service management called the watermelon effect: an SLA dashboard that is green on the outside and red on the inside. Every target is met, every report looks healthy, and the customer is still frustrated, because the metrics measured the machine, not the experience (Joe the IT Guy, "How to Recognize and Deal with Watermelon SLAs"). A help desk can hit "resolved within target" on almost every ticket by closing them fast and reopening the same problem tomorrow. The number is met; the user is no better off.

A watermelon SLA is green on the outside and red on the inside, every target met, every customer unhappy.

So the move is: measure at least one thing the customer actually feels, alongside the operational metrics. A satisfaction score (CSAT) on resolved tickets, or a measure of repeat contacts, sits beside uptime and response time and stops the dashboard from lying to you. Some organisations formalise this as an "experience level agreement," but you do not need the acronym, you need one metric in the contract that goes red when the customer is unhappy even though the servers were up. Write the SLA so that gaming it would require actually serving the customer well.

flowchart LR
  A(["Operational SLAs
uptime, response, resolution"]) --> C(["The dashboard"])
  B(["Experience metric
CSAT, repeat-contact rate"]) --> C
  C --> D{"All green
AND customer happy?"}
  D -->|"Yes"| E(["Healthy relationship"])
  D -->|"Green but unhappy"| F(["Watermelon, fix the
metric, not just the score"])
Pair operational targets with one experience measure so a green dashboard can't hide a red customer. Leaders Loop

A worked example

Take a mid-sized retailer, call it Harbourline, outsourcing its customer-support desk to a third-party provider. (Illustrative figures throughout; this is a teaching example, not a real account.) The pitch was compelling: the provider quoted, say, an illustrative £18 per resolved contact versus an estimated £30 to run the desk in-house, a 40% saving on paper. Harbourline signs a standard SLA: answer 80% of calls within 30 seconds, resolve 90% of tickets within 24 hours.

Six months in, the dashboard is a wall of green. Both SLA targets are met every week. Yet complaints to Harbourline's own social channels are climbing, and repeat customers are quietly drifting to a rival. When the operations lead digs in, the watermelon is obvious: the provider hits "resolved within 24 hours" by closing tickets with a templated reply and letting customers re-raise the same issue, which counts as a fresh, freshly-resolved contact. Every reopened ticket is also another £18. The 40% saving is eaten by volume the provider has an incentive to create.

Applying the lens above, Harbourline does two things at the next review. First, it adds an experience metric to the SLA, a CSAT score on resolved tickets and a cap on repeat-contact rate, with the service credit tied to those, not just speed. Second, it recognises this was always a high-specificity, high-uncertainty transaction (its support quality is core to the brand), so it keeps a small in-house escalation team rather than outsourcing the whole thing. The renegotiated SLA costs slightly more per contact but fewer contacts overall, and the dashboard now goes red the moment customers are unhappy, which is the only time the number was ever worth watching.

Frequently asked questions

What's the difference between a vendor and a supplier?

In everyday use the terms overlap, and many organisations use them interchangeably. Where people draw a line, "supplier" tends to mean a source of goods or components further up the supply chain (often a longer-term, deeper relationship), while "vendor" often means whoever sells you a finished product or service, sometimes more transactionally. The management discipline, select, contract, monitor, review, is the same regardless of the label.

What should every SLA contain?

At minimum: the services in scope and out of scope; the specific, measurable targets (with definitions of how each is calculated and over what window); how performance is reported and how often; the consequences of missing targets, usually service credits or escalation rather than instant termination; a review-and-change process; and an exit plan. The exit clause is the one people skip and regret, it is what stops a supplier holding you hostage once you depend on them.

Are SLA penalties actually worth having?

They matter, but not for the reason people assume. The point of a service credit is rarely to recover money, the credit is usually small relative to the damage a real failure causes. Its value is as a signal and a trigger: a missed SLA that costs the provider something gets attention inside their organisation, and it gives you a contractual hook for a serious conversation. A penalty so harsh it threatens the provider's margin, though, tends to backfire, they defend the metric instead of fixing the service, which is how watermelons grow.

Isn't outsourcing just about cutting costs?

Cost is the usual headline, but it is often the weakest reason. The stronger cases are access to capability you cannot build economically yourself (specialist skills, 24/7 coverage, scale) and the focus that comes from handing off work that is not your core. Transaction cost economics is the reminder that the cost case is also frequently overstated, because the bill for governing the relationship, monitoring, coordinating, managing the risk of failure, is real and rarely in the original business case.

How much oversight does an outsourced function need?

Enough to verify the SLA honestly and no more, but "no more" is higher than most people expect. Outsourcing transfers the work, not the accountability; if the provider fails, your customers still blame you. Match the intensity to the stakes: a generic, low-risk service needs a quarterly review of a few numbers, while something core to your brand or safety needs active relationship management, real audit rights, and a tested exit plan. The failure mode is "set and forget", signing the contract and looking away until something breaks.

Related in the Toolkit

Where to go next