Operations

Choosing and managing vendors without losing control

Suppliers rarely fail suddenly. They fail because nobody defined what good looked like, who was watching, or how to leave. A short set of agreements prevents most of the damage.

Choosing and managing vendors without losing control

The relationship you will actually have

Most vendor problems are not caused by dishonest suppliers. They are caused by a mismatch that was never surfaced: the buyer expected a partner who would manage the work, the vendor delivered what the contract literally stated, and nobody defined the boundary in between.

Getting this right is not about being adversarial. It is about being specific before money changes hands, and staying attentive afterwards. Both are cheap compared with replacing a supplier mid-project.

Define the requirement as an outcome

A request for a product or a service describes what you think you need. A requirement describes what has to be true when the work is finished.

Write it in three parts. First, the outcome: what will be different in the business when this works. Second, the acceptance criteria: how you will judge that the outcome has been achieved, in observable terms. Third, the constraints that are not negotiable: dates set by regulation or contract, integration with existing systems, data residency, working hours of your team, budget ceiling.

The discipline of writing acceptance criteria before you talk to suppliers does two things. It makes proposals comparable, and it exposes the places where you are not yet sure what you want, which is much better to discover during selection than during delivery.

Look beyond the headline price

Compare total cost of ownership, not the quoted figure. For each proposal, add:

  • Implementation or onboarding cost, including your own staff time.
  • Training and the learning curve for the people who will use it daily.
  • Ongoing licence, support, or maintenance fees, and how they escalate.
  • The cost of integration work with your existing systems, which is almost always larger than the proposal assumes.
  • The cost of exit: extracting data, rebuilding anything bespoke, and running both systems in parallel during a transition.

That last item is the one most often ignored and most often expensive. Ask directly: if we stopped working with you in two years, what would it take for us to leave, and what would we hold in our hands on the day we left?

Check capability with evidence

References are useful when you ask them the right questions. Do not ask whether the supplier is good. Ask: what did they get wrong, how did they handle a problem, how often did the person who sold the work appear after the contract was signed, and did they deliver on the date they promised.

Ask for two contacts you did not choose, not just the one the supplier offers. A supplier who cannot produce an alternative reference is telling you something. Where the work is significant, ask for a small paid piece of work first: a short assessment, a scoped pilot, a single module. Real work in small quantities reveals more than any presentation.

The five contract points that matter operationally

You do not need to become a contract lawyer. You do need these five things to be unambiguous:

  1. Scope and acceptance. What is delivered, in what form, and who signs it off against what criteria. Include what happens if acceptance fails and how many attempts are included.
  2. Change process. How a change is requested, estimated, approved, and recorded. Without this, changes are agreed verbally and disputed at invoicing.
  3. Service levels and remedy. For ongoing services, define the response and resolution expectations that matter to your business, and what the supplier owes you if they are missed. A service level without a remedy is a wish.
  4. Data and intellectual property. Who owns the data, who can access it, where it is stored, and what happens to it at the end of the relationship. For bespoke work, who owns what was built.
  5. Exit and portability. Notice periods, assistance during transition, and the format in which you receive your data.

If a supplier resists any of these, that is information worth having before you are dependent on them.

Manage the relationship, not just the contract

Once the work starts, the most valuable thing you can do is set up a lightweight rhythm and keep it. A short regular call with a fixed structure: what was delivered, what is next, what is at risk, what decisions are needed. Notes circulated afterwards, with actions and owners. This is not bureaucracy; it is the mechanism that prevents a minor delay from becoming a surprise.

A named person on your side should own the relationship, with the authority to make day-to-day decisions and a clear route for escalating anything they cannot settle. Vendors respond to clarity: when they know who decides, they stop hedging with three alternatives in every email.

Track commitments in one place. A simple log of what the supplier promised, when, and whether it happened is remarkably effective, because it turns a vague sense that things are slipping into a factual conversation.

Keep your leverage intact

Dependency is the quiet risk in vendor relationships. It builds through convenience: the supplier learns your quirks, holds the institutional knowledge, and becomes harder to replace each quarter.

Counter it deliberately, and cheaply:

  • Own your documentation. Processes, configurations, and access details should live in your systems, not only in theirs.
  • Keep access under your control. Where possible, accounts and credentials should be issued by you and revocable by you.
  • Know the exit cost, and refresh the number annually.
  • Avoid single-person dependency inside the supplier where the work is critical; ask who else can support your account.
  • Maintain a credible alternative. Even if you never switch, knowing what the market offers changes the tone of every renewal.

When to renegotiate, and when to leave

Renewal is a decision, not an administrative event. Before it, answer three questions: is the service delivering what it promised, is the price still consistent with the value and with the market, and has our requirement changed?

Leave when the cost of managing the relationship exceeds the value it produces, when repeated service failures affect your customers, when exit costs have quietly grown beyond what you can absorb, or when your needs have moved and the supplier cannot follow. Do not leave purely on price; migration risk and internal disruption are real costs, and the cheapest supplier is often the most expensive transition.

If you do decide to move, run the transition as a project: overlap the services, define the data you need, set a date when the old arrangement ends, and check the new one works before you cancel the old. Most failed migrations are caused by timing, not by the choice of vendor.

The short version

Write down what good looks like, price the whole relationship including the exit, check capability with evidence, define five contractual points, keep a small regular rhythm with a named owner on your side, and stay capable of leaving. None of this requires a procurement department. It requires an afternoon of specificity before signing, and thirty minutes a month afterwards.