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.” For many companies, this is precisely what is needed. 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
The thing they 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. Any solution can be put in a cloud. Any solution can be spun up in a matter of minutes. So, what is the real difference?
There are three things a customer should be looking at when comparing web-only and premisable solutions:
- 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 can put a lot of effort into their configuration UI’s, as well as the documentation and technology of their API.
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 that 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 ERP, WMS, OMS, and POS 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 – removing the external dependency and dramatically increasing 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 might be comforting when a web-only solution says they are hosted on one of the major PaaS (Platform as a Service) providers, but we have all seen problems every year with the major PaaS solutions on the market.
Some examples of these problems:
Amazon Web Service outages
- December 2021
- September 2021
- August 2019
- November 2018
For more see https://awsmaniac.com/aws-outages/
- October 2022
- September 2022
- August 2022
For more see https://status.azure.com/status/history/
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?” 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.
It is when things get complex that the ability to reach out to professional services, that are familiar with your implementation and your unique business, makes 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 makes it possible for a company to quickly add basic shipping functionality to any single application in 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 another business rule is needed, 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, 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, recode all the business rules, and test to ensure that all the systems act the same. Don’t forget, every time a change is needed, code needs to be rewritten 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 the business rules are written once and are usable in all the systems. When a change is made, 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, who is likely the most familiar with the platform, build the business rules.
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. These CI/CD solutions are often referred to as “version-less.”
While it is true that web-based software is more likely to follow a version-less deployment and premisable software is less likely, 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, or 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.” It is this video that 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 amount of effort required to create and maintain premisable carriers and APIs, and they are charging their customer 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 see if the limitations of most web-only API aggregators will meet your logistics needs.
If you’re having second thoughts about web-only solutions, or are in the process of implementing one, you are now armed with some industry knowledge and questions to ask your vendors. At ProShip, we understand that choosing the right MCSS for your unique business is no easy task. It requires extensive research on the operational end, as well as the IT side, and sometimes it’s hard to get through all of the fluff and discover exactly 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.
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.