Carrier onboarding decides whether your visibility programme works. It is not an IT task.

Visibility programmes have a characteristic failure mode. The platform goes live, the top five carriers integrate, coverage reaches somewhere around 40% of shipments, and then it stops.

Nothing has broken. The technology works. But customer service still phones carriers, because a system that covers 40% of shipments is a system you have to check against anyway — and once you are checking anyway, you may as well phone.

Coverage is not a nice-to-have metric on a visibility programme. Below a threshold, the benefit is close to zero regardless of how good the platform is.

Why it stalls

Because onboarding gets planned as an integration exercise. Formats, endpoints, message specifications, test cycles — all real work, and all of it assumes the carrier wants to do it.

Many do not, and their reasoning is sound. A mid-sized regional haulier serving forty shippers has no interest in a fortieth bespoke integration for one of them. The effort is yours to justify, not theirs, and “our programme needs it” is not a justification that lands.

Tier the carriers, not the effort

Treating every carrier identically is the most reliable way to stall. Three tiers works better:

Tier one — deep integration. Your top carriers by volume. Full API or EDI integration, proper event mapping, real testing. Perhaps ten to twenty relationships covering the majority of shipments. Worth every hour spent.

Tier two — lightweight. The middle. Whatever they can already produce — a flat file, a scheduled export, an existing standard format — accepted with transformation on your side rather than theirs. The ask has to be small enough to say yes to in one conversation.

Tier three — portal or nothing. The long tail. A web form or a mobile status update, with the honest expectation that adoption will be partial. Some of these will never participate, and the plan should assume it rather than treat it as a defect.

The instinct to standardise is exactly wrong here. Uniform requirements optimise your integration team’s convenience at the cost of coverage, and coverage is the whole point.

The lever that actually works is commercial

The programmes that reach high coverage are the ones where network participation is written into carrier agreements and tender criteria.

That means:

• Data provision as a term in the contract, at renewal
• Participation as a scored criterion in tenders, weighted enough to matter
• Existing carriers given a clear window and a clear consequence

This is a procurement change, not an IT change, and it needs to start before the platform does. A programme that reaches go-live before having this conversation has already given away its leverage — you are now asking a favour rather than exercising a term.

Decide what an event is for

Once carriers are connected, the second failure appears: everything is tracked and nothing is actionable.

Every event, broadcast to everyone, is noise with a licence cost attached. Before onboarding, decide:

• Which milestones matter, per lane type — a domestic parcel and an ocean import do not share a milestone set
• What constitutes an exception, in terms specific enough to alert on
• Who acts on each exception, and inside what window

The third one is the one that gets skipped, and it is the one that determines whether visibility changes any outcome. An unowned alert is a notification, not a control.

What good looks like

A visibility programme is working when customer service stops phoning carriers — not when the dashboard is populated.

That happens at high coverage on the lanes that generate the questions, with events people trust, and exceptions someone owns. Note that this is achievable with 80% coverage concentrated on the right lanes, and unachievable with 60% spread evenly across all of them.

Which is really the point: onboarding is a targeting problem before it is an integration problem.