Technology Sourcing

A sourcing event executes a decision. It does not discover one.

Going to market is the reflex when a cost looks wrong or a renewal is close. It is also slow, it spends goodwill with providers you may want to keep, and it is an expensive way to find out your existing agreement was reasonable. Sourcing is worth running when the evidence already says change is warranted.

NarrowGateX is the Technology Intelligence Platform: software, AI workers and an accountable advisor.

Start a Technology Baseline See the Execute stage

Before any of this

Supplier outreach is not the first meaningful step.

By the time a request reaches a provider, three things should already be settled: what you have, how it compares to the market, and what decision the evidence supports. A sourcing event that begins before those exist is really a discovery exercise being run at your suppliers' expense, and it produces proposals shaped by what they sell rather than by what you need.

Only then does anything here become the right answer, and sometimes the answer is that nothing needs to change.

Vera · Sourcing coordinator

The worker who runs the event.

Verasourcing coordinatorWhat Vera does, and will not do

The approval gate is built, not promised

No message reaches a supplier until a person approves the draft. That is a property of how the platform is built. The send is blocked until the approval exists.

Your advisor owns the strategy, the negotiation and the provider relationship, and answers for how the event turns out. The rest of the workers.

On provider relationships

Who pays, and what it does not buy.

Where compensation from a provider applies to a transaction it is disclosed to the client, and it never determines the recommendation. How a recommendation is reached.

Which is why the sequence on this page is not a formality. If the recommendation is settled before the market is approached, there is nothing for provider economics to influence.

How an event runs

Six things that have to hold for a comparison to mean anything.

Requirements from the record

What you actually run, at which sites, under what obligations. Requirements written from the estate rather than from a wishlist are the difference between comparable responses and a pile of proposals.

A defined market

Which providers are asked, and why those. Chosen from what the benchmark evidence showed exists, with the incumbent included so the comparison is real.

One set of criteria

Agreed before responses arrive, so the standard cannot move to fit whoever answered best. Scoring against criteria written afterward is not scoring.

Responses, side by side

Commercial and technical differences laid out on the same basis, including the parts that are hard to compare and why they are hard.

A decision package

The recommendation, what was considered and rejected, the tradeoffs, and the reasoning. It stays attached to the record rather than expiring with the project.

Follow-through

Owners, dates and the obligations the new agreement creates, tracked after signature, when most sourcing processes go quiet.

What you are left holding

What survives the event.

Most sourcing processes leave a signed agreement and very little else. The reasoning evaporates, and the next cycle starts from nothing.

Requirements traceable to the estate they came from, not assembled from memory
Provider responses that can genuinely be compared, on criteria fixed before they arrived
A recommendation with its alternatives and reasoning preserved, that a person will defend
A record of who was approached, what they offered and why the selection went the way it did
The obligations the new agreement created, watched from the day it starts rather than rediscovered at renewal

Before the sourcing event, the evidence.

Establish what is true about your environment and how it compares, and find out whether going to market is the right move at all.

Start a Technology Baseline See the whole model