Manufacturing

Hear from ProShip’s Co-founder, and learn why you should be questioning the validity of the shipping software “Install in Days” guarantee

A dangerous trend is making its rounds in the small parcel market lately. The promise of a supply chain technology provider who can “install in days.” This is precisely what many companies need. For the rest, it is caveat emptor - buyer beware.

Promises made by some shipping software companies

Purveyors of this technology push advantages such as:

• No on-premise install
• Self-configuration of carriers
• "Easy" self-integration into your Enterprise Software Stack (ESS)
• No upgrades
• No additional cost to add carriers

There is one thing these companies don’t want you to know. Most “premise” based software solutions offer the same capabilities but have additional options that many “install in days” companies cannot extend.   

Let’s investigate the details of each of these claims to see the bigger picture.  

Note: For the purpose of this article, I will use web-only and premisable (a solution with the ability to be installed on-premise) to describe the two solution types in the market.

No on-premise installation

Let’s start with the facts. You can put any solution in a cloud, and you can spin up any solution in a matter of minutes. So, what is the real difference?  

When comparing web-only and premisable solutions, there are three things a customer should be looking at:

• The ease of Configuration
• The response speed of the solution
• The availability of the solution

The Ease of Configuration

A web-only solution can control just one of those three things: Ease of configuration. These solutions typically invest considerable effort into designing their configuration user interfaces (UI’s), as well as improving the documentation and technology of their APIs.  

A good premisable solution should also provide API’s and UI’s that allow for easy configuration of simple tasks. Simple functions should include things such as the setup of standard carrier services. Premisable solutions can also provide the ability to configure contract-only services. These are often not available in the carrier API’s (and not available in web-only solutions, as a result).

The Response Speed of the Solution

However, web-only solutions cannot claim to force a carrier API to go any faster. They cannot reduce the round-trip time from your Enterprise Software Stack (ESS), including the Enterprise Resource Planning (ERP) system, Warehouse Management System (WMS), Order Management System (OMS), and Point of Sale (POS) system used to run your enterprise, to their API. It is not uncommon for a full rate shop to take over 1,300 milliseconds (1.3 seconds). And this does not even count the time required to execute your business rules (more on that later)!   

Not only can a premisable solution perform the above, but it can also be installed in the same data center as the key pieces of your ESS, helping to control network latency. These solutions can also perform carrier rate, ship, and labeling computations directly inside that data center. This removes the external dependency and dramatically increases the speed of response times. It is not uncommon to get response times, even with business rules, of 300 milliseconds (.3 seconds) or less from a premisable solution.

Availability of the Solution

All good multi-carrier shipping software (MCSS) should incorporate a stateless solution. This means that each API transaction lives independently of any prior or subsequent API call. This is the key to allowing a distributed solution to provide high availability of shipping services.  

It can be reassuring when a web-only solution mentions that it is hosted on a leading PaaS (Platform as a Service) providers. However, we have all seen problems every year with the major PaaS solutions on the market.

Some examples of these problems:

A premisable solution can still leverage the same PaaS providers, but it can also be installed in your data center, as mentioned before. This hybrid-style solution, popularized by IBM, provides for tiered degradation of services, rather than a complete stop.

Self-configuration of carriers

They say, “Why pay an engineer to enter your carrier data when you can do it yourself?” And I could not agree more. Customers with few carriers and normal contracts should have a means of adding origins, accounts, and other configurable items.    

But what happens when your needs go beyond just a few carriers? What happens when there are thousands of accounts to load in order to cover all your stores? What happens when you need to go deep into the details of a carrier?  

Does your team know how to configure FedEx Ground vs Express vs SameDay City? Do you qualify for USPS CPP, MCP, NSA? Did your resource who did know these things leave your company? Misconfiguration of these choices could cost tens of thousands per day in mis-shipped packages.

When things get complex, the ability to reach out to professional services becomes crucial. Professionals that are familiar with your implementation and your unique business can make the difference between a “good enough” solution that meets most of your needs and an excellent solution that meets all of your needs.

"Easy" self-integration into your Enterprise Software Stack (ESS)

As someone with a software engineering background, I agree it is easy to integrate to RESTful JSON based API’s that all good shipping software providers offer. The latest technology enables a company to easily incorporate fundamental shipping process functionality into any individual application within your ESS.   

Complications arise when you need a business rule- simple, right? The IT person that is connecting the company’s software to the shipping API adds a few more lines of code. Later, when they need another business rule, they add to that code. This continues in that one system, and at the time, seems rather manageable.   

But many companies need to quote pricing on their website, and in their sourcing system, and in their WMS. Modern retailers need their OMS to contact the shipping system to include shipping costs as part of the sourcing logic. E-commerce suites might be able to get the results from the OMS, if one exists, or they must connect to the shipping system to set proper expectations for the customer. Though the WMS is the “normal” place to connect shipping software systems, many companies have more than one WMS. Yet another “easy” place that needs to be connected.

The next logical conclusion is to just connect each system in the ESS to the shipping system API. This would entail someone spending time in each piece of software to connect them to the same API. They’d also have to recode all the business rules and test to ensure that all the systems act the same.    

Don’t forget, every time you need a change, you must rewrite the code within each system. Why? Because few web-only systems have a place to put the business rules on the shipping system side of the API, leaving a shipper to add them into their OMS, E-Commerce Suite, and all their WMS’s.

Most premisable shipping solutions have a dedicated area for business rules. This means that you only need to write the business rules once, then you can use them in all the systems. When someone makes a change, it thereby affects all systems.   

Finally, when business rules are created inside the shipping system, there is an option to have the shipping software vendor’s professional services team build the business rules. This team is likely the most familiar with the platform.

No upgrades

Many have had ESS vendors charge enormous amounts for upgrades, which stings. But software companies solved this years ago by moving to a “continuous integration, continuous deployment” (CI/CD) strategy for their solution, popularized by the Agile software development approach. People often refer to these CI/CD solutions as “version-less.”

Version-less

It is true that web-based software is more likely to follow a version-less deployment and premisable software is less likely. However, this is not a rule. There are web-based solutions that have an upgrade process, and there are many premisable solutions that are now version-less.

Strong API contracts

The real key to a version-less solution is a strong API contract between the product and the rest of your ESS. If the API contract is not going to change for years, the supporting modules and containers can be switched out multiple times per day if needed. Alternatively, you can replace them once or twice per quarter, with no change to the API.    

That is not to say that those contracts will never need to change. Especially in the multi-carrier small parcel world, carriers will come out with new services that the API contract might not have had the fields to support. However, this should be rare. [Something to note: ProShip has only had 4 changes to our API contract in 22 years. With that level of experience, we do not expect an API contract to change frequently.] 

Even more important: A well-designed contract change will have minimal to no impact on the rest of your ESS.

No additional cost to add carriers

In 1973, the artists Richard Serra and Carlota Fay Schoolman broadcasted a short video titled “Television Delivers People.” This video helped coin the phrase, “If you are not paying, you are the product.” 

MCSSs that don’t charge by the carrier are either charging by the transaction or they are reselling rates. This means they are making a margin off every shipment processed. That might be a flat fee across the board, or it could be a percentage of each transaction. This can really add up the more you ship. 

However, in regards to reselling rates, this is not necessarily a bad thing. You might think you are getting a better deal – even if they are reselling rates. A noteworthy exception is that this may not be the case unless you are an early startup.  Once a company has grown past the startup stage, it is difficult to know if you are still getting a “good deal” using these “reseller rates.”

“Simply put, you cannot be certain that reseller rates provide the best value, unless a thorough evaluation of carrier direct rates/services is performed.” Said Nate Skiver of LPF Spend Management. “This is often overlooked, but if rates are procured through a third-party, a shipper's account may be viewed as nothing more than a small part of a reseller's program. Establishing a direct relationship with the carriers, including direct contracts, ensures both parties are engaged, and the carriers have a greater incentive to understand a shipper's business. This is especially important as order volume and/or operational complexity increases.”  

The MCSSs that charge by the carrier are being upfront with customers. They understand the effort needed to create and maintain premisable carriers and APIs. They charge their customers based on the effort for the engine (a one-time cost), rather than how much the engine is used. Without the incentive to push you towards the carrier that provides them the largest cut, all carriers within the right premisable MCSS are on a level playing field, benefiting you with a carrier-agnostic platform.

Final considerations when choosing shipping software

Your company might be a perfect fit for the “install in days” small parcel multi-carrier API-based solutions on the market. After reviewing the above information, it should be easier to determine if the limitations of most web-only API aggregators will meet your logistics needs. 

If you’re reconsidering web-only solutions or currently in the process of implementing one, you now possess industry knowledge and questions to pose to your vendors, equipping you to make informed decisions about your choice. At ProShip, we understand that choosing the right MCSS for your unique business is no easy task. Extensive research is necessary on both the operational and IT sides. Sometimes, it can be challenging to precisely assess how well a solution will fit and perform.

For more information, check out ProShip’s How It Works brochure, and see exactly how our solution fits into your ESS.

View the Brochure

About the Author

Justin Cramer is Co-Founder of ProShip, where he has deployed, designed, or consulted on over 300 customer solutions within 4 continents and has designed shipping solutions executing more than 3 million labels a day. Listed as one of Supply & Demand Chain Executive’s 200 “Pros to Know” in 2019, Justin has been on the IT side of shipping since 2001.