Last December, Convoy, J.B. Hunt, and Uber Freight announced the formation of the Scheduling Standards Consortium (SSC), “which aims to solve transportation scheduling challenges by establishing the freight industry’s first formal set of appointment scheduling application programming interface (API) standards.”
Earlier this month, the SCC announced “the achievement of a landmark milestone — the publication of its Technical Standard for developing scheduling application programming interface (API) for transportation management systems (TMS).” Here’s an excerpt from the press release:
The Technical Standard is available for TMS developers on GitHub, encapsulating eight months of rigorous technical and strategic collaboration. The work ushers in an era where scheduling systems work seamlessly, transcending the barriers that have long hindered efficient data sharing among shippers, carriers, and brokers. The SSC’s API-based approach will allow companies to access the latest data and make smart decisions to increase efficiency, reduce empty miles and waste, lower costs, and improve service outcomes. As each company aligns with these standards, the industry can better orchestrate freight needs with data-informed systems.
The SCC also announced additional industry collaborators. Here’s the full list of participants:
- Convoy
- J.B. Hunt
- Uber Freight
- Arrive Logistics
- Blue Yonder
- Coyote Logistics
- e2open
- Echo
- One Network Enterprises
- Oracle
- DHL Supply Chain
- Lineage Logistics
- Mastery Logistics Systems
- Transportation Insight & Nolan Transportation Group
- Ryder System, Inc.
- Worldwide Express
It’s great to see many industry leaders participating in this effort, but there are also some notable names missing from the list (e.g., SAP, C.H. Robinson, Trimble). As the SCC noted in its press release last year, “[Industry] adoption is critical for the effort to succeed.” If you don’t see your TMS provider, carrier, or brokerage partner on this list, ask them about it. Hopefully, we’ll see this list continue to grow in the weeks and months ahead.
That said, as I mentioned in my post last December (“Appointment Scheduling API Standard: Will It Work With Paper Calendars?”), assuming an appointment scheduling API standard is defined and broadly adopted and complied with, it’s not enough.
Research conducted in April 2020 with members of our Indago supply chain research community — who are all supply chain and logistics executives from manufacturing, retail, and distribution companies — showed that relatively few of our members (21%) are using dock appointment scheduling software from a TMS, WMS, or YMS vendor. An equal percentage (21%) are using spreadsheets, with others using paper calendars (8%) and commonly available online calendars like Google Calendar (17%).
Simply put, an API standard is worthless if you’re still using spreadsheets and paper calendars to manage your appointment scheduling process.
How do you get more companies (especially small and mid-sized ones) to implement appointment scheduling software from a TMS, WMS, or YMS vendor? It’s a question many vendors ask themselves, of course, but in a nutshell: make it inexpensive, quick to implement, and super easy to use.
All that said, in my opinion, the biggest risk to success for this API standard is that it will suffer the same fate as so many EDI standards, including EDI 163 – Transportation Appointment Schedule Information: many companies will start customizing it (e.g., adding and rearranging fields), turning a standard into a non-standard that will lead to the same integration and data quality challenges that plague supply chains today.
SCC recognizes this risk, which is why it included the following statement in the “Best Practices” section of the API document:
Customer- or Facility-Dependent API Variations SHOULD Be Avoided
While discouraged, the SSC is aware there may be times when an API implementer may need to add additional custom properties to request headers and/or request and response bodies. However, the SSC strongly discourages any such customizations that vary based on other aspects of the request context, such as which customer or facility the request is for. For example, requiring a field ‘foo’ when making a request for one customer but requiring a different field ‘bar’ when making a request to a different customer should be avoided. Similarly, defining supported values for a field that vary based on the customer or facility should also be avoided. Such variations greatly increase the complexity and effort required for a client to successfully integrate with scheduling systems at scale.
Will companies resist the temptation to bastardize this API appointment scheduling standard? I hope so, otherwise the promised benefits of this API standard — “making it easier to book and manage appointments, optimize processes for carriers, shippers and receivers, and drive operational efficiencies for the industry at large” — will never be fully achieved.
For related commentary, please read:
