OTM SIG 2026, the Oracle Transportation Management User Conference, runs July 26–29 at the Hilton Minneapolis. If you’re going, you already know what OTM does. Routing. Carrier selection. Cost optimization. Transportation planning at scale. You’ve built your operation around it, and it works.

What’s coming up more often now, on the show floor, in RFPs, in internal reviews, is what happens right after the plan is set. The moment shipments leave the dock. That’s where a significant amount of cost and manual work quietly lives. And it’s what we’ll be talking about at OTM SIG 2026.

The people in the room

The OTM SIG community skews operational. Transportation managers, logistics ops leaders, IT teams running integrations, supply chain executives who own carrier spend and OTIF metrics. Most of them run OTM as their core transportation system. Sessions cover product updates, implementation best practices, integration strategy, and a lot of peer conversation about what’s actually working.

If your organization runs OTM, this is your community.

The problem worth a real conversation

OTM is a planning system. A very good one. It handles the decisions upstream of the dock: mode, carrier, cost, routing, load optimization.

Parcel execution is a different architecture problem. Rate shopping across carriers in real time, generating compliant labels at volume, tracking individual packages from creation to delivery. That requires a parcel-specific execution engine that sits downstream of the planning decision, not a workaround bolted to the side of your WMS.

Here’s what that gap actually looks like in practice.

Take a logistics ops manager at a mid-market industrial distributor running OTM. Two hundred and fifty to three hundred parcel shipments daily, peak at end of day. Their label generation is running through a disconnected tool that takes six seconds per shipment. That’s 30 minutes of print time before the first truck can leave. Every day. Not counting manual carrier selection for shipments that fall outside the rate table, or the phone calls when a package misses carrier cut-off because the label wasn’t ready.

The plan was right. The execution was the problem.

Six seconds per label doesn’t sound like a business issue. But at 300 shipments daily, it’s 30 minutes before the dock opens. At 600 shipments, it’s your first hour. That’s not a throughput tweak; it’s an architectural constraint on your peak capacity.

The architecture OTM wasn’t designed to replace

OTM handles planning. It’s not designed to manage parcel-level rate shopping at the moment of shipment, or label generation at carrier-compliance speed, or package-level tracking from creation through delivery exception.

The gap between what OTM plans and what the dock executes is real and documented. Most environments fill it with manual workarounds or disconnected point tools. Both work until volume increases, carrier contracts change, or a customer SLA comes under pressure.

The reframe: this isn’t an OTM gap. It’s an architecture gap. OTM does what it was built to do. The parcel execution layer is a separate capability, and it needs to be connected to the plan, not layered over it.

What QAD does about it

QAD Multi-Carrier Parcel Shipping is Oracle-certified and built specifically for OTM environments. It extends what OTM already does into parcel execution without competing with it or replacing it.

In practice that means four things:

Rate shopping. Live parcel rates across carriers, compared automatically at the moment of shipment. No spreadsheets, no manual builds. Best rate, every time, in under one second.

Carrier execution. One engine for tendering, label generation, and carrier compliance. Powered by live carrier content, not static configurations that drift out of sync with carrier rule changes.

Package-level tracking. Real-time visibility on every parcel after it leaves the dock. Exception alerts surfaced before issues reached your customer.

Carrier connectivity. UPS, FedEx, DHL, OnTrac, Purolator, and a pre-built carrier network that covers the vast majority of routes your operation needs. Live carrier content means the network stays current as carriers update rates, label specs, and service requirements. 

OTM stays the system of record for planning. QAD handles execution. The two work together on the same underlying data.

What customers are seeing

A few results from actual QAD deployments. These figures are illustrative of outcomes observed in specific customer environments; results will vary based on shipment volume, carrier mix, and operational configuration.

Label processing time down from six seconds to under one second per shipment. At 300 shipments daily, that’s roughly 28 minutes returned to operations, every day, before carrier cut-off.

One customer deferred a $30M warehouse expansion. Throughput improved without adding space, because execution capacity was the real constraint, not physical square footage.

That last one tends to stop people mid-conversation. Because a $30M capital decision is one thing. But understanding that the constraint was a software architecture problem, not a real estate problem, is a different kind of realization.

Come find us in Minneapolis

We are at Booth G10 at OTM SIG 2026. If you’re dealing with label speed, carrier rate shopping, or visibility gaps between your WMS and OTM, that’s the conversation we’re set up to have.

We also have a five-minute spot on the general session stage. It’s called Logistics Confessions. Come see how your peers are actually handling parcel execution in their OTM environments. It’s more honest than most sessions.

Meet us at OTM SIG, Booth G10.

QAD Multi-Carrier Parcel Shipping. Rate shopping, carrier execution, and package-level visibility. Built for OTM environments.