Real-time pricing vs. spot pricing: Whats the difference? – FreightWaves

Posted: February 12, 2021 at 5:31 am

By Omar Singh, president and Founder, Surge Transportation

The most fundamental difference between real-time pricing and spot pricing is that one is by design and the other is by mistake.

Traditional spot pricing sending loads to auction is sourcing capacity for loads that are not covered by mistake. The traditional routing guide strategy is to forecast annual volume across a linear average and send that out to bid.

However, demand is not linear and sometimes that creates gaps in coverage. Historically we find that shippers experience this gap in coverage up to 10% of the time and then turn to spot auctions to source capacity when their loads are not covered by mistake. By mistake, I mean they forecast 25 loads per week and secured commitments of 25 trucks per week, but their customer ordered all 25 loads on Monday and Tuesday rather than the linear average across the week and now there is not enough capacity by mistake.

On the other hand, real-time pricing also known as dynamic pricing and technically activating an application programming interface (API) external rate engine is by design on purpose. When I say by design, I mean everything is intentional.

From a shippers viewpoint, the community of service providers is intentional, the amount of volume is intentional, the type of volume is intentional, the key performance indicator (KPI) considerations are intentional. From a service providers viewpoint, everything about the returned rate and capacity should be intentional rather than relying on the gut or the mood of the person bidding that day. This discussion unpacks some of the key intentional design factors involved with API real-time pricing.

Strategic partner vs. transactional provider

Perhaps the most notable difference of this is the intentional design around the service provider who is participating in a real-time environment returning API rates. This is the strategic partner vs. the transactional provider.

There is typically a bit of time, financial investment and relationship quality required to integrate and activate API pricing with a transportation management system (TMS) in general and then with each service provider individually. So shippers are carefully curating a community of only their best carriers and brokers to participate in an API environment this is where strategic partners play.

The result should be that they get reasonable market-based rates returned, which are supported by excellent service levels from providers who know their supply chain well and are truly invested in the success of the relationship.

Spot auction, on the contrary, is typically a community of anybody and everybody who received an award by that shipper, not just in this years bid cycle but perhaps even in some remote prior years bid cycle. Typically these are transactional providers who are not invested in the long-term success of the relationship and do not know the customers supply chain well.

The result, and quite honestly the expectation, is often volatile rates and volatile service levels. At the worst, its high rates and low service levels.

Intentional volume vs. overflow

The traditional routing guide strategy is to forecast 100% of a shippers annual volume, send that out to bid, secure capacity commitments accordingly whatever transactional volume does not have coverage gets sent to auction. What we are seeing with real-time pricing is the intentional design of either a volume of freight or characteristic of freight that is reserved for API rate providers.

When I first started in this business, several of my customers had a disclaimer in their awards that indicated if the market changes up or down more than 5% based on a reliable market index, then either party has the right to renegotiate rates.

I dont see these disclaimers much anymore, but they represent a mature seasoned supply chain teams understanding that one way or another they are going to be paying market rates when the market is up, they will pay more and when the market is down, they will pay less. Well, rather than one year at a time, real-time pricing allows shippers and their service providers to exercise this dynamic one day at a time. Some large shippers are now forecasting 100% of their projected annual volume and only sending 70% of that to RFP, with the intention of playing the market with the other 30%.

Again, this is the mature understanding that when the market is up, they will pay more and when it is down, they will pay less and strategically hedging that it is more valuable and stable for them to be with the market along with their providers almost like a choreographed dance where partners stay in step with each other at all times.

Another place we are seeing intentional design regarding real-time rates is in the characteristic of freight volume, not just the percentage and/or the characteristic of their shipping location. Many large, high-volume shippers break out their bids into volume high-volume and low-volume business.

Traditionally, high volume is designated for large asset-based motor carriers that are able to build efficiencies around the high-volume shipping lanes, and hence, provide better rates and service due to the strategic nature of that lane in their overall network. Low volume is reserved for brokers that are not providing drop trailers and do not rely on the volume consistency in the traditional strategic front- or back-haul sense required to make a network of lanes function altogether.

With real-time pricing, we are seeing some shippers designate low-volume business (primarily broker partners) to those strategic API rate providers and understanding that the market is going to move a bit in most years a lot in some years. On that same note, other shippers are designating high-volume outbound locations only to API providers and lower volume locations to traditional spot.

KPI vs. lowest rate

OK, not everybody has built this capability, and it is not necessary to activate real-time pricing and build a strategic community, but its pretty exciting to work with customers that are able to consider service along with rate in a real-time environment.

The traditional way of curating a spot auction community is that providers are either in or they are out, and they are either the cheapest or they are not. Getting expelled from an auction is kind of like getting cast out of the village you have to do something really bad or just be altogether a terrible provider. What that leaves in auction is a range of providers that go from barely acceptable to remain in spot all the way to the best and most strategic.

Since a TMS typically is configured to award spot auction based solely on rate, the result can be that it drives more business to barely acceptable providers when, for a tolerable threshold difference in rate, that business could be driven to a strategic partner who over time returns more value.

Standard auction is not configured to account for KPIs, whereas everything can be designed and programmed in API. So we are seeing customers that develop the capability of awarding business not just on rate but on the weightage of the likelihood that a provider will accept a load if tendered to it and on the likelihood that it will deliver on time and on the likelihood that it will be compliant with EDI and tracking visibility.

Traditionally these evaluations are done once per year as part of a large annual award, or once per month to evaluate whether a provider can keep its award, and it involves some human and relationship discretion, whereas in API it is done daily and it just involves clearly defined programmable math the evaluation is done at the level of each individual load rather than at the level of the lane or the RFP event.

Service providers perspective no human error

The defining theme of this conversation has been to establish that real-time pricing is by design rather than by mistake. This is true not only for the shipper but also for the carrier and broker.

Shippers are able to get rates faster, secure capacity more rapidly and drive more business to strategic providers who are currently performing well in their supply chain. Brokers and carriers are able to remove human error, discretion and attendance while also rapidly returning rates at a high volume hence securing more loads more quickly.

Some of the most common things I hear from bidders are that they fat fingered a number by mistake; they didnt realize it was a same-day shipment; they didnt realize it was a team shipment; they didnt notice more loads were available by refreshing the screen; they discerned that they should not bid on that particular shipment for some new reason; and the list goes on, trust me.

With the API external rate engine, the algorithm knows when it is a team load, the algorithm knows when it is a same-day shipment, the algorithm knows how many loads we can take on the same lane on the same day or how many additional loads we can take as a company on any given day. It knows that V means van and R means refrigerated. It never gets sick, never slows down and never takes a day off.

Certainly it takes a while to build logic that accounts for everything and then more time to build the capability of integrating that logic with multiple TMSs thousands of hours later, its an ongoing process really. The result is that the customer experience of making strategic decisions proactively by design rather than reactively by mistake, and selecting providers who can meet them at those initiatives, has been a winning combination in every shipper-carrier TMS relationship Ive seen.

Every shipper we work with month-over-month sends more volume to its API real-time environment, which is absolute proof that the strategy works to provide a desirable balance of cost, service and capacity. For shippers, more volume moves the way it was designed to, while for service providers, more business is developed and earned the way we aspire to strategically rather than transactionally.

See original here:

Real-time pricing vs. spot pricing: Whats the difference? - FreightWaves

Related Posts