Ingka Group acquires Locus! Built for the real world, backed for the long run. Read here>Read the full story>
Ingka Group acquires Locus! Built for the real world, backed for the long run. Read the full story

Buy the Change, Not Just the TMS How to scope, price and negotiate an all-mile transportation transformation that survives contact with your network

A buyer-side field guide August 2026 7 min read

Every TMS proposal is comparable on one number, the subscription fee, and on almost nothing underneath it. Workflows have to be configured. Interfaces have to be built and tested against systems your own team owns, which quietly puts your ERP release calendar on the critical path. Carrier and rate master data has to be cleaned and effective-dated before anything can be planned on it. Planners and dock supervisors have to be trained, then released from the day job long enough to use the training. And somebody has to answer the phone at two in the morning when a linehaul leg fails.

The fee is the part that fits on a slide, so that is where the negotiating hours go, and it is rarely where the overrun starts.

This guide is a method for making all of it visible before you sign. It names no providers and recommends none.

Fig. 1 What an all-mile TMS agreement actually covers

One operating flow. Six kinds of work inside it. All of it arriving as a single agreement.

The all-mile operating flow and the six kinds of work inside one agreement Across the top, five stages of the operating flow: plan and procure, first mile, linehaul and hub, last mile, and settle and learn. Beneath them, the six kinds of work that a single TMS agreement contains: platform, client layer, integration, bespoke build, delivery and adoption, and run and AI. The flow is what the business does. The six work types are what is actually being bought, and they do not behave alike. THE OPERATING FLOW Plan & procure First mile Linehaul & hub Last mile Settle & learn Rates, contracts,capacity Pickup, ASN,yard Legs, cross-dock,sort Route, slot,proof Freight audit, claims,cost-to-serve THE SIX KINDS OF WORK INSIDE ONE AGREEMENT 010203 040506 Platform Client layer Integration Bespoke build Delivery Run & AI The flow is what your business does. The six work types are what you are actually buying, and they do not behave alike.

Work types in section 2. Pricing mechanisms in section 3.

1Where the money and the risk actually sit

The ledger you are actually signing

Most guides help you choose a system. Very few help you structure the deal.

There is no shortage of good advice on selecting a TMS. Define the end state, weight the requirements, script the demos, model total cost. All sound, and all of it stops at the shortlist, which is roughly where the money starts moving.

Selection gets you a name on a contract. What that name has committed to is a separate exercise, and most buying teams never run it.

A TMS commitment contains at least six kinds of work, and they do not behave alike. Some are knowable at signature. Integration is knowable only one flow at a time, a carrier tender and the acceptance that comes back against it, and each flow carries a counterparty, a failure mode and a reconciliation question that nobody sees until somebody lists it. Bespoke engineering is not knowable until somebody has looked. Adoption depends more on you than on the provider, and consumption on volumes neither party can forecast.

Pricing all six the same way does not remove the uncertainty. It parks it in the line nobody is tracking, which in an all-mile deal is almost always consumption.

The bands below come from one all-mile program. Most of the multi-year commitment sits in metered usage, priced per transaction and per user. Two of the six work types, client-layer configuration and bespoke build, appeared nowhere on the price sheet. Both got built, billed inside delivery days and integration effort, where nobody was tracking them as scope.

Fig. 2 A real all-mile ledger, in bands

Two of the six work types never appeared on the price sheet. Both got built anyway.

A real all-mile ledger, anonymized and rounded to bands Panel A is a single stacked bar of one program's multi-year commitment: metered platform usage 60 to 70 percent, delivery and rollout 15 to 20 percent, network design 5 to 10 percent, application support under 5 percent, integration engineering under 5 percent. Two further work types, client layer and bespoke build, are drawn as empty dashed outlines because they were never priced as scope, though both were built and billed inside delivery days and integration effort. Panel B plots the metered line as a share of each year's spend: negligible in the early years, then rising to most of the annual bill later in the term. A WHERE THE MONEY ACTUALLY GOES Anonymized and rounded to bands. Shape, not figures. 60 to 70% 15 to 20% NEVER PRICED Metered platform usage 60 to 70% Delivery and rollout 15 to 20% Network design 5 to 10% Application support under 5% Integration engineering under 5% Client layer and bespoke build: never priced as scope. Both were built, and billed inside delivery days. B THE METERED LINE AS A SHARE OF THAT YEAR'S SPEND ALL OF IT HALF NONE Small enough at signature to feel like a rounding item. Large enough later to be most of the annual bill. EARLY YEARS LATER YEARS

One all-mile program, anonymized and rounded to bands by the author. Shape, not figures.

2The scope architecture

You are buying six things, not one

Six work types. One agreement. Each one priced for the uncertainty it carries.

Providers will package these together, which is reasonable and often efficient. Your job is to keep them separate in your own head, because the questions you need to ask are different for each one.

Configuration is where buying teams commonly err in the opposite direction. Your dock rules, your carrier allocation logic, your exception paths and your approval chains are the operating model. Encoding them is the point of the exercise. The question is not whether to adapt the platform, but whether that adaptation sits in a governed configuration layer that survives an upgrade, or in code your own team inherits at the next release.

Work typeWhat you must define before a price means anythingCommercial intent
PlatformEntitlements, modules, environments, service levels and release assumptions.A predictable recurring foundation.
Client layerConfigured workflows, rule ownership, design authority, auditability and release path.Fund flexibility deliberately. Do not bury it in license or in code.
IntegrationBusiness corridor, events, system of record, latency, retries, exceptions, reconciliation.Price and accept a working business flow, not a nominal API.
Bespoke buildThe differentiated need configuration cannot safely express, plus lifecycle and portability.Discovery, increments and a cap. Never an open-ended promise.
Delivery and adoptionPhases, your own dependencies, data, training, rollout and hypercare.Milestones tied to verifiable readiness and acceptance.
Run and AISupport boundary, consumption unit, data controls, model policy and evolution rhythm.Recurring usage that is observable and reconcilable.

3The price architecture

Fixed price is not the safe option

Match the mechanism to the uncertainty, then put a guardrail on it.

Fixed price is not automatically safer. On scope nobody has examined, it gets you a number that both sides then re-litigate through change control for the next year. Consumption pricing carries less risk than it looks, provided you can see the meter and cap the downside. Match it to what you know about each work type, not to the template that arrived with the proposal.

Fig. 3 Match the mechanism to the uncertainty

Two questions place all six work types: how open is the scope, and how hard does the volume swing.

Pricing mechanism by scope certainty and volume variability A two by two matrix. The vertical axis runs from known scope to genuinely open scope. The horizontal axis runs from stable volume to volume that swings hard. Top left, open scope and stable volume: buy learning before you buy build, with time-boxed discovery and a ceiling, holding bespoke build. Top right, open scope and swinging volume: meter it, cap it, reconcile it, with an included budget, overage cap, anomaly alert and audit right, holding client layer and run and AI. Bottom left, known scope and stable volume: fix the price per defined unit, per corridor or workflow band with an acceptance test, holding integration and delivery and adoption. Bottom right, known scope and swinging volume: subscribe on written entitlements, with named modules, growth tiers, indexation and renewal rules, holding platform. HOW OPEN IS THE SCOPE? HOW VARIABLE IS THE VOLUME? GENUINELY OPEN KNOWN STABLE SWINGS HARD Buy learning before you buy build Meter it, cap it, reconcile it Fix the price per defined unit Subscribe, on written entitlements Time-boxed discovery with a ceiling. Then fixed increments, or the right to stop. Included budget, overage cap, anomaly alert and an audit right. Per corridor or per workflow band, each with an acceptance test attached. Named modules and environments, growth tiers, indexation and renewal rules. Bespoke build Client layer Run & AI Integration Delivery & adoption Platform

Guardrails in full below.

Work typeThe guardrail that makes the mechanism safe
PlatformList what is included. Define renewal, indexation, and how new entities, modes and environments are treated.
Client layerDesign authority, promotion and release governance, support ownership, and a change rate card.
IntegrationA fixed price on their side of the boundary only. Settle now what happens when your own system team slips.
Bespoke buildAgree now what happens if discovery ends and the scope is still open: a second box, a descope, or the right to walk.
Delivery and adoptionPrice your own dependencies visibly. Require a joint plan, controlled change, and an explicit hypercare boundary.
Run and AIDefine the consumption unit in business terms before signature. A meter counting calls or tokens is never reconciled to shipments afterwards.

4The negotiation playbook

Discount is the cheapest thing they can give you

Press the lever that resolves the risk. Then ask for something specific in return.

Discount is the cheapest thing a provider can give you and the easiest thing to over-index on. A rep absorbs a point against quota and recovers it on expansion. The levers below are worth more. A cap, a rate protection, an audit right or a fixed price per corridor moves real variance onto the provider balance sheet, which means the person across the table almost certainly cannot grant them alone. Raise them early and in writing, so they reach the deal desk while there is still time to answer.

The situation in the roomThe lever to pressMake the concession conditional on
The subscription is low and delivery is vague.Separate subscription from delivery. Insist on the six-work-type scope map.A signed scope boundary, your dependencies named, and milestones led by evidence.
Integration is quoted per API.Reframe around the business corridor and the critical event sequence.An accepted end-to-end flow with retries, reconciliation, fallback and clear ownership.
The provider asks for a longer term.Use term to buy predictability rather than a headline reduction.Rate protection, growth tiers, a capped uplift, roadmap and support commitments, or a renewal review right.
Bespoke work is uncertain.Buy the learning first. A time-boxed discovery with a ceiling.A usable backlog, an architecture decision, the option to stop, and fixed or capped next increments.
Usage or AI consumption is variable.Ask for transparent meters and three-case forecasting.An included budget, an overage cap, an anomaly alert, an audit right and a scheduled commercial review.
You want a fixed go-live date.Trade schedule certainty for disciplined scope and your own readiness.Agreed data, access and decision dependencies, freeze dates, and formal change control.
The provider wants broad change control.Separate configuration, integration evolution and bespoke code.Pre-priced bands, stated response times and a governance forum instead of surprise estimates.

The language, side by side

A weak askA better ask
Can you reduce the price?If we commit the forecast and a three-year term, what cap, growth tier or roadmap commitment can we have in return?
Is integration included?Show me the business corridor: event owner, latency, recovery, reconciliation and acceptance evidence. Then price that.
Can you customize it?Which part is configured in the client layer, which part needs code, and who owns each of them after go-live?

5The buyer workflow

Run it as one sequence, not two

Most buying teams run selection and commercial negotiation on separate tracks, then discover at contract stage that the two describe different programs. Running them as one sequence keeps the commercial conversation tied to the operational reality it has to fund.

Fig. 4 Six moves, then four gates

One sequence, not two. The commercial conversation and the operational one advance together, and no gate clears on a status update.

The six buyer moves and the four gates that follow them Top row, the six moves in sequence: set the operating case, map the real work, classify and price, stress-test proposals, trade conditionally, gate on proof. Below them, the four gates: G1 scope lock, G2 design accepted, G3 build and data ready, G4 go-live accepted, each labelled with the signed artifact that clears it. SIX MOVES, IN SEQUENCE 123 456 Set theoperating case Map thereal work Classifyand price Stress-testproposals Tradeconditionally Gate onproof FOUR GATES. EACH CLEARS ON A SIGNED ARTIFACT, NOT A STATUS UPDATE. G1 Scope lock G2 Design accepted G3 Build and data ready G4 Go-live accepted Signed scope map, and anamed owner per workflow Solution design signed byboth design authorities Migrated data reconciled,meters live, defects agreed Acceptance passed, firstvalue review dated

Who owes what at each gate is in section 6.

MoveWhat you carry forwardDo not advance until
1 Set the operating caseOutcome statement, baseline, target, in-scope network and strategic constraints.The baseline is a number from a named source system: cost per shipment, on-time percentage, planner hours, failed deliveries.
2 Map the real workA decision and exception map for planners, carriers, sites, drivers, customers and systems.You can point at the handful of decisions that drive cost and service, and name who owns each one today.
3 Classify and priceThe six-work-type scope map, the price architecture and your own dependencies.Every priority workflow is classified, owned and commercially treated.
4 Stress-test proposalsCommon demo scenarios and a three-case cost model.Each finalist has run the same scenarios on comparable assumptions.
5 Trade conditionallyA negotiation ledger: give, get, owner, evidence, decision date.No concession sits in the ledger without a reciprocal, documented commitment.
6 Gate on proofReadiness, acceptance, hypercare and a 30, 60 and 90 day value plan.The agreement contains operational evidence, not statements of intent.

6Readiness and acceptance

Most of the slippage is yours

Make your own commitments as visible as theirs.

When a TMS program slips, the cause is very often on the buyer side: data that was never cleaned, a routing decision nobody would sign, access that took eleven weeks, planners who were promised and never released. Squeezing the provider will not move any of it. It is your data and your people. Put your own dependencies in the agreement, priced and dated, next to everything you are asking them to commit to.

Fig. 5 Who owes what, and when the money moves

Every gate has three parties owing something. The row most likely to slip is the top one.

What the buyer, both parties jointly, and the provider each owe at every gate A grid of four gates against three parties. At G1 scope lock before RFP, the buyer commits baseline, target and in-scope network signed; jointly the six work types are classified and owned; the provider states assumptions, exclusions and dependencies. At G2 solution design accepted, the buyer names decision rights and design authority; jointly an acceptance test is written per corridor; the provider documents the release and upgrade path. At G3 build and data ready, the buyer cleans master data and grants system access; jointly defect classes and remedies are agreed; the provider has environments, meters and reporting live. At G4 go-live accepted, the buyer has trained users, a cutover plan and an honored freeze; jointly a value review is dated at 30, 60 and 90 days; the provider has the hypercare boundary and exit terms in force. No gate clears on a status update. G1 Scope lockbefore RFP G2 Solution designaccepted G3 Build and dataready G4 Go-liveaccepted Buyercommits Jointagreement Providercommits Baseline, target andin-scope networksigned Decision rights anddesign authoritynamed Master data cleaned,system accessgranted Trained users, cutoverplan, freezehonored Six work typesclassified and owned Acceptance testwritten per corridor Defect classes andremedies agreed Value review datedat 30 / 60 / 90 days Assumptions, exclusionsand dependenciesstated Release and upgradepath documented Environments, metersand reporting live Hypercare boundaryand exit terms in force No gate clears on a status update. Each one clears on an artifact somebody signed.

The five dependencies that most often hold up the top row are below.

The five dependencies that slip most often

Your dependencyWhat to commit, in writing
Master dataCarrier, lane, rate, site and service-level records reconciled to a single source, with a named owner and a freeze date.
Decision rightsNamed individuals who can approve a routing rule or an exception path, and the hours within which they will.
System accessEnvironments, credentials and representative test data available on a dated schedule, not on request.
People releasedNamed planners and operators with allocated hours, and a backfill plan for the day job they are leaving.
Site readinessDevices, connectivity, printing and dock process changes ready at each location before its wave, not during it.

7The deal readiness score

When a good score still means do not sign

A hundred-point guardrail against a deal that looks attractive and is under-specified.

Score the evidence in front of you rather than your confidence in the relationship. Seven dimensions, each scored 0 to 5 and weighted to a total of 100. Run it before award and again at the design and readiness gates. The worked case below is the one worth studying: a deal that clears the threshold on the total and still should not be awarded.

ScoreWhat it meansThe evidence threshold
0 to 1Absent or aspirationalAn ambition or an RFP sentence exists. No owner, no boundary, no commercial treatment, no proof.
2A buyer askThe requirement is documented. Responsibility, cost, dependencies or acceptance remain unresolved.
3Shared designBoth parties agree the intended answer. Scope, owner and commercial treatment are written down.
4Executable agreementDependencies, acceptance evidence, reporting and escalation make the answer deliverable and governable.
5Operational commitmentIt is funded, contracted, tested and owned, with a review rhythm already in the diary.

Fig. 6 The arithmetic, worked

73.6 out of 100 clears the band. One hard gate scored 2, so the total is irrelevant.

A worked deal readiness score of 73.6 that still fails on a hard gate Seven weighted dimensions scored out of five. Outcome and baseline clarity, weight 12, score 4, 9.6 points, a hard gate that clears. Solution and client-layer boundary, weight 16, score 2, 6.4 points, a hard gate that fails because it needs 3. Integration, data and security readiness, weight 14, score 4, 11.2 points. Commercial architecture and total cost, weight 18, score 4, 14.4 points, hard gate clears. Delivery, adoption and buyer commitments, weight 14, score 4, 11.2 points. Acceptance, service and support, weight 12, score 4, 9.6 points, hard gate clears. Governance, change control and value proof, weight 14, score 4, 11.2 points. The weighted total is 73.6, which sits in the 60 to 79 band, but one hard gate scored 2, so the verdict is do not award. Weighted points = weight x score / 5. Seven dimensions at full marks give 100. DIMENSION WT SCORE PTS Outcome and baseline clarity Solution and client-layer boundary Integration, data and security readiness Commercial architecture and total cost Delivery, adoption and buyer commitments Acceptance, service and support Governance, change control and value proof 121614 18141214 424 4444 9.66.411.2 14.411.29.611.2 HARD GATE FAILS, NEEDS 3 Weighted total 100 73.6 hard gate clears hard gate fails not a gate Band says: 73.6 sits in 60 to 79 Proceed only with a dated closure plan for every weak line. Gate says: do not award One hard gate scored 2. The total is irrelevant until that single line reaches 3.

A worked illustration of the scoring method, not a specific transaction.

8The printable canvas

The page you take into the room

Take it into the steering committee and into the final room. One score, one unresolved issue, one owner and one decision date for every dimension. If a row is blank, that is the row to work on.

The deal readiness canvas

DimensionWtScore 0 to 5 What has to be negotiated nowOwnerEvidence / date
Outcome and baseline clarity12
Solution and client-layer boundary16
Integration, data and security readiness14
Commercial architecture and total cost18
Delivery, adoption and buyer commitments14
Acceptance, service and support12
Governance, change control and value proof14
Weighted total (sum of weight x score, divided by 5) 100

Prints the canvas on its own, without the rest of the guide.

When to use which section

WhenSections
Before the RFPSections 2 and 3. Classify your priority workflows and set your pricing and scenario assumptions.
During evaluationSections 3 and 4. Run common scenarios, compare the full ledger, and keep a give and get record.
Before awardSections 6 and 7. Score the evidence and close the hard gates.
At contract and mobilizationSection 8. Carry every unresolved row into the project plan with an owner and a date.

A field guide, not legal or procurement advice. It assumes no particular provider or platform.

Utkarsh Garg

Utkarsh Garg

CFO, Locus

Utkarsh, a BW 40 under 40 leader, leads finance and customer success at Locus. He spearheads post-acquisition integration management while focusing on scaling Locus' global operations.