Collaborative Supply Chain: A Shipper-Carrier Playbook

Every logistics conference has a session on the collaborative supply chain, and almost none of them say what the two parties actually exchange on a Tuesday morning. That is the gap this guide fills. Collaboration between a shipper and a carrier is not a philosophy or a partnership agreement — it is a specific set of data fields, moving in a specific direction, on a specific cadence, with someone accountable at each end.

What follows is the practical version: what is worth sharing, the three ways to move it, the objections you will genuinely hear from the other side, and a ninety-day pilot you can run with one trading partner before committing to anything. It assumes a mid-size operation — a shipper with a handful of core carriers, or a carrier with a handful of accounts that matter — not a Fortune 100 control tower.

What a collaborative supply chain means beyond the buzzword

Strip away the marketing and supply chain collaboration reduces to one idea: each party stops guessing at something the other party already knows. That is it. Every genuine benefit — fewer empty miles, less detention, fewer “where is my load” calls, better forecasting — comes from closing one of those information gaps.

So it helps to be blunt about what each side is currently guessing at.

The carrier is guessing at…	The shipper is guessing at…
How much volume is really coming next week	Whether the load was actually picked up
Whether the dock will be ready at the appointment time	Where the truck is and whether it will be late
What the freight weighs and how it is packaged	Why an accessorial was charged
Whether a tender will be re-tendered or cancelled	Whether the carrier has capacity before tendering

Notice that none of these require a shared platform, a joint venture, or access to anybody’s pricing. They require eight or nine fields to cross the boundary reliably. That distinction matters, because the reason most collaboration initiatives stall is that they are scoped as a technology programme when they should be scoped as a data exchange.

Three things collaboration is not

• It is not shared systems. You do not need the same TMS, the same WMS, or even the same data model. You need an agreed interface.
• It is not open-book pricing. Cost transparency is a separate commercial negotiation and conflating it with operational data sharing is the fastest way to kill the conversation.
• It is not permanent. Collaboration is scoped to lanes, sites and a time period, and it should be reviewed like any other commercial arrangement.

The three data layers worth sharing

Not all data is equally valuable and not all of it is equally sensitive. Sort it into three layers and work outward: each layer is harder to agree than the last, and each is worth more.

Before any layer: agree the identifier

None of the three layers joins up without a single shipment identifier that both sides use and neither side changes. This sounds trivial and it is the most common reason a feed arrives and turns out to be unusable: the shipper keys on its own order or delivery number, the carrier keys on its pro number or trip number, and nobody can reconcile the two without a manual lookup table that goes stale in a fortnight.

Pick one primary key, carry it on every message in both directions, and carry the other party’s reference alongside it as a secondary field rather than replacing it. The bill of lading number is the usual choice for truckload; a GS1 SSCC works where the unit of handling matters more than the load. Whichever you pick, write down what happens when a shipment splits, merges or is re-tendered to a different carrier — those three events break more identifier schemes than anything else.

Layer 1 — Execution data (start here)

Status events on shipments that already exist. This is the easy layer: the data is factual, it is already captured, and neither side considers it commercially sensitive. In EDI terms it is largely the 214 status message, and it covers:

• Tender accepted or rejected, with a reason code on rejection
• Driver dispatched, arrived at pickup, loaded, departed
• Estimated time of arrival, updated when it changes materially
• Arrived at delivery, unloaded, departed, with timestamps on each
• Exceptions with a coded reason, not free text

Layer 1 alone removes most of the phone calls between the two organisations and makes a service scorecard possible. If you do nothing else, do this.

Layer 2 — Planning data (the valuable one)

Forward-looking volume. The shipper shares a rolling forecast — typically two to six weeks out, by lane, with a stated confidence — and the carrier shares equipment availability against it. This is where the economics actually change: a carrier that can see your volume two weeks out can position equipment instead of repricing the lane at the last minute.

Layer 2 is harder because a forecast is an opinion, and sharing an opinion invites blame when it is wrong. Handle that in the agreement, not in the data: state up front that the forecast is non-binding, define what an acceptable deviation looks like, and agree that persistent one-sided error triggers a conversation rather than a penalty.

Layer 3 — Network and constraint data (the hardest)

Facility constraints, dock capacity by hour, seasonal patterns, planned site changes, and — from the carrier — network imbalance: which regions they are short of outbound freight in. This layer is where empty miles get removed and where continuous-move opportunities appear, because you cannot build a round trip without knowing what is on the other side of it.

It is the hardest layer because it is genuinely competitive information on both sides. Most mid-size relationships never formalise it; they do it informally, in a quarterly conversation between two people who trust each other. That is a legitimate implementation and it is worth more than a stalled project to systematise it.

EDI, API and portal approaches compared

Three mechanisms move shipper carrier data sharing in practice. They are not competing philosophies; most real relationships end up with two of them running side by side.

	EDI	API	Portal
How it works	Batched standard documents exchanged over AS2 or a VAN	Request/response or webhook over HTTPS, usually JSON	One party logs into the other’s web interface
Latency	Minutes to hours, depending on batch schedule	Real time	Real time, but only when someone looks
Setup effort	High — mapping and testing per partner	Moderate — but only if both sides have one	Low
Cost shape	Per-document or VAN fees, ongoing	Build cost up front, low marginal cost	Near zero
Scales to many partners	Yes — that is what it is for	Only if your API is the standard one	No — manual effort per partner
Best for	High-volume, stable relationships	Status, tracking, rating, real-time ETA	Low volume, exceptions, document exchange

EDI remains the backbone of North American freight and it is not going away. The relevant ASC X12 transaction sets are few: 204 to tender a load, 990 to accept or reject it, 214 for status, 210 for the invoice, 997 to acknowledge receipt. Its weakness is latency and the per-partner mapping cost; its strength is that it is a genuine standard, so partner number twenty costs far less to onboard than partner number two.

APIs win on everything EDI is bad at and lose on everything it is good at. Real-time ETA, instant rating, a tracking page that is actually current — all of that needs an API. But “we’ll integrate by API” quietly assumes both sides have one, that it is documented, and that someone will maintain it through the other party’s next platform change. For a mid-size carrier, that last assumption is the one that fails.

Portals are underrated. A web interface where the counterparty can see status, download documents and raise an exception costs almost nothing to run and handles the long tail of partners who will never justify an integration. The common mistake is treating the portal as a stepping stone to be retired; in practice it stays, because there is always a tail.

A sensible target state for a mid-size operation: EDI or a flat-file exchange with your two or three largest partners, an API for the real-time surfaces that customers actually see, and a portal for everyone else. For carriers that means a public-facing site doing real work rather than acting as a brochure — a self-service quote request and a status lookup remove more inbound calls than any internal system change. Both are build patterns we have written up in detail: the instant freight quote calculator guide and the track-and-trace page walkthrough, both built on the Moovit logistics and transportation theme, which includes quote request forms and service inquiry handling as standard.

Trust and commercial objections

Technical work is the easy half. These are the objections that actually stop projects, and the answers that actually work.

“You will use our data against us at the next bid.”

From the carrier, and entirely reasonable. The answer is scope, in writing: name the fields, name the systems they land in, name who inside your organisation can see them, and state that operational data is excluded from procurement analysis. Then actually honour it — one bid built on shared status data ends collaboration with that carrier permanently, and the story travels.

“Our forecast is not good enough to share.”

From the shipper, and usually true. Share it anyway, with the error attached. A forecast with a stated confidence of plus or minus thirty per cent is far more useful to a carrier than no forecast, because they can plan against the floor. Perfection is not the bar; honesty about accuracy is.

“Who pays for the integration?”

The party that captures the benefit, which is normally the larger one. Arguing this to a 50/50 split wastes more money in meeting time than the integration costs. If the shipper wants the data, the shipper funds the connection — and gets to specify it.

“What happens when the relationship ends?”

Write the exit into the agreement before you start: data deletion or return, how long retained records may be kept, what happens to a jointly built integration. An exit clause makes the entry decision much easier, which is precisely why it accelerates rather than delays the project.

“We tried this before and nothing happened.”

The most common objection and the hardest to answer, because it is usually accurate. Previous attempts fail for one of three reasons: no named owner on either side, no defined end date, or no measurement. The pilot below exists to remove all three.

A 90-day pilot plan

One partner. One set of lanes. Ninety days. A go/no-go decision at the end. Resist every attempt to widen the scope before the decision point — scope creep, not technical difficulty, is what kills these.

1. Days 1–10 — Pick the partner and the scope. Choose a partner you already have a functioning relationship with; a pilot will not repair a bad one. Pick five to ten lanes with enough weekly volume to generate a readable signal. Name one accountable person at each organisation — not a committee.
2. Days 10–20 — Agree the field list and the baseline. Write down every field, its format, its direction and its frequency, on one page. Then record the baseline for the metrics in the next section before anything changes. Pilots that skip the baseline cannot be evaluated and are therefore always judged on feeling.
3. Days 20–35 — Build the thinnest thing that works. If a daily CSV over SFTP delivers Layer 1, ship the CSV. The pilot is testing whether the information changes behaviour, not whether your integration is elegant. Build the proper interface after you know the answer.
4. Days 35–50 — Run in parallel. Keep the phone calls and emails running alongside the feed. This is how you find the gaps: every time someone picks up the phone, log what they asked for and check whether the feed should have answered it.
5. Days 50–75 — Switch over and add Layer 2. Stop the manual channel for anything the feed covers. If the relationship survives that comfortably, introduce the rolling forecast and the equipment availability response.
6. Days 75–90 — Measure, decide, write it down. Compare against the baseline, hold a joint review with both owners in the room, and make an explicit decision: extend to more lanes, extend to more partners, or stop. Record the decision and the reasoning — this document is what gets a second pilot funded.

Measuring whether it worked

Pick four metrics, baseline them in week two, and do not add more later — a pilot judged on twelve metrics is a pilot that can be argued either way. These four cover the realistic benefit of a collaborative logistics platform at this scale:

Metric	How to measure it	Which layer drives it
Tender acceptance rate	Accepted tenders ÷ tenders offered, by lane	Layer 2 — the carrier can plan for the volume
Manual touches per shipment	Count calls and emails about a load; sample a week	Layer 1 — status answers the question first
Dwell and detention incidence	Detention events ÷ shipments, plus average dwell	Layers 1 and 3 — arrival visibility and dock planning
Forecast accuracy	Absolute error between forecast and actual volume, weekly	Layer 2 — and it is the honest test of whether the forecast was worth sharing

Two measurement warnings. First, seasonality will swamp a ninety-day window if you let it — compare against the same period last year as well as against the pre-pilot baseline. Second, “manual touches” improves immediately and dramatically, which makes it the metric everyone quotes; it is real, but it is the smallest of the four in money terms. Tender acceptance and detention are where the actual cost sits.

Finally, measure the thing nobody puts in the deck: whether the two owners still talk to each other. Data exchange makes a working relationship more efficient. It does not create one, and if the pilot ends with both sides pointing at the feed instead of calling each other, it has failed regardless of what the numbers say.

A collaborative supply chain is, in the end, a sequence of small agreed exchanges that each remove one guess. Start with the status feed, prove it, add the forecast, and leave the hard network layer to the quarterly conversation until the first two have earned the trust to support it. If you are specifying the public-facing side of that — the quote, the status page, the service and coverage detail a partner checks before they commit — our guide to carrier contract optimization covers what shippers look for, and the business and industry theme collection is where to start on the build.