Appointment Scheduling is a major point of friction for carriers, brokers, and shippers alike. Complex and nuanced appointment scheduling processes lead to inefficiencies when procuring and managing appointments across the freight industry. The Scheduling Standards Consortium (SSC) aims to simplify the integration of systems across the fragmented ecosystem that exists today. We anticipate that a standard set of communication protocols will enable shippers and carriers to more seamlessly connect with each others’ systems, enabling efficient data sharing and greater efficiencies across the supply chain.

The primary objectives of the SSC are to (1) define an API standard for sharing scheduling information, (2) eliminate manual processes by automating interactions where possible, (3) implement the standardized interfaces and integrations across core systems, and (4) advocate for the standard across the industry. The SSC aims to partner with shippers, carriers, brokers, and solutions providers to drive towards a standard. The purpose of this document is to start the conversation and to provide an overview of the key workflows that the scheduling API will need to support. The SSC will continue to refine documentation informed on feedback from the industry.

Aligning as industry leaders on a set of standards will simplify the integration of systems across the fragmented ecosystem between shippers, carriers, and intermediaries. All such parties will benefit from simpler interfaces and integrations.

Key Definitions

• Load: A load is a truckload of goods that is moving between 1:N locations. It is possible for a load to have multiple pickups and multiple deliveries. Each load has a unique identifier that will be defined by the TMS. This identifier will be referred to as the primary reference number.
• Stop: A stop is a point along a load’s journey. For example, the pickup location, the dropoff location, and any stops in between will be referred to as stops.
• Dock Groups: Dock groups are a predefined set of dock doors that are eligible for a particular load. Dock groups are configured in the TMS, WMS, or scheduling software. For example, a facility may have two dock groups that are being managed within a system where Dock Group A is for outbound shipping and Dock Group B is focused on inbound receiving. Other unique constraints that may be configured within a dock group are commodity type, equipment type, consignee, etc.

• For Version 1 of the Scheduling Standards, we are focusing on TMS Dock Groups.

• Live Loading: Describes a load in which the freight will be loaded into or unloaded from the carrier’s trailer upon their arrival at a location.
• Preloaded: Describes a load in which the freight will already be loaded onto a trailer that is onsite at a location. In this scenario, a carrier will bobtail to the pickup location (arrive without a trailer) or drop an empty trailer before attaching the loaded trailer.
• Drop: Describes a load in which the carrier is expected to unhook the loaded trailer in the yard or at a dock door upon arrival. Carrier may bobtail out or depart with another trailer from the location.

Scope:

• Core Systems Involved: The first phase of this initiative will primarily focus on defining standards to facilitate appointment scheduling transactions between carriers/brokers and shipper TMS dock scheduling applications. We aim to extend these standards to standalone dock scheduling solutions (i.e. non-TMS scheduling solutions) in the next phase of this initiative.
• Load Types: The first phase of this initiative will focus on over-the-road full truckload. Multi-stop loads (i.e. loads that pickup or dropoff at multiple locations) are also included as in scope. As referenced above, a load is a truckload of goods that is moved between 1 and N locations.
• Equipment Types: This first phase of this initiative will support the 3 primary full truckload equipment types: Van, Reefer, Flatbed.
• Loading Types: Live, Drop, and Preload appointment scenarios will be supported.

Out of Scope:

• Intermodal
• Transload
• Rail
• LTL
• Dray

Given that existing TMS and Appointment Scheduling Solutions are the source of truth for appointment data and appointment restrictions, the SSC’s proposal is to simplify carrier-side appointment logic and nuance, and empower the TMS’s and Appointment Scheduling Vendor’s to implement necessary rules and validations for appointment booking.

As a carrier / broker, I should be able to fetch a list of available appointment times for a particular load on a particular day at a particular stop in a TMS / appointment scheduling solution.

The carrier / broker should be able to provide the load’s primary reference number, either the stop sequence number and/or location identifier, and a preferred appointment date or date range.

• In addition, the carrier / broker will have the option to provide a BOL number and/or a PO number as additional reference numbers.

 Based on these inputs, the API response will return either a success or failure message.

• Failure messages will return a reason code outlining why a particular failure occurred.
• Success messages should contain one of the following:

1. A list of “eligible” appointments at a particular location that match the load, stop, and carrier requirements.

•  The available appointment candidates should be restricted by necessary exclusions including, but not limited to, equipment type, commodity, consignee, “must-pickup-on” and “must-deliver-by” dates, etc. It is important to ensure dock groups are properly configured so that only eligible times are returned.
• Specific appointments, appointment windows, and first come, first serve should be supported.
• Each available appointment should have an identifier that can be used for scheduling and rescheduling.

2. An indication that the request is pending.

 The TMS / appointment scheduling solution should be capable of responding synchronously and/or asynchronously. 

• If asynchronous is supported, the TMS / appointment scheduling solution should provide the ability to push a response and/or allow the carrier / broker to poll for a response.

As a carrier / broker, I should be able to schedule an available appointment for a particular load on a particular day and time at a particular stop in a TMS / appointment scheduling solution.

After fetching available appointments via the fetchAvailableAppointments endpoint, the carrier / broker should be able to provide either an available appointment identifier or a combination of the load’s primary reference number, the stop sequence number and/or location identifier, and a fetched available appointment date and time.

• In addition, the carrier / broker will have the option to provide a BOL number and/or a PO number as additional reference numbers.

Based on these inputs, the API response will return either a success or failure message.

• Failure messages will return a reason code outlining why a particular failure occurred.
• Success messages should contain one of the following:

1. An appointment confirmation identifier number if the appointment was scheduled.
2. An indication that the request is pending.

The TMS / appointment scheduling solution should be capable of responding synchronously and/or asynchronously.

• If asynchronous is supported, the TMS / appointment scheduling solution should provide the ability to push a response and/or allow the carrier / broker to poll for a response.

As a carrier / broker, I should be able to reschedule an existing appointment to a new available appointment for a particular load on a particular day and time at a particular stop in a TMS / appointment scheduling solution.

After fetching available appointments via the fetchAvailableAppointments endpoint or referencing a log of fetched appointments, the carrier / broker should be able to provide either the existing appointment confirmation number or a combination of the load’s primary reference number, the stop sequence number and/or location identifier, and a fetched available appointment date and time.

• In addition, the carrier / broker will have the option to provide a BOL number and/or a PO number as additional reference numbers.

Based on these inputs, the API response will return either a success or failure message.

• Failure messages will return a reason code outlining why a particular failure occurred.
• Success messages should contain one of the following:

1. An appointment confirmation identifier number if the appointment was rescheduled.
2. An indication that the request is pending.

The TMS / appointment scheduling solution should be capable of responding synchronously and/or asynchronously.

• If asynchronous is supported, the TMS / appointment scheduling solution should provide the ability to push a response and/or allow the carrier / broker to poll for a response.

Regardless if the response is synchronous or asynchronous, the TMS / appointment scheduling solution should only cancel or move the previous appointment if the new rescheduled appointment is accepted.

• If the new appointment request fails or is rejected, the original appointment information should remain.

It will be up to the discretion of the TMS / appointment scheduling solution if a new appointment confirmation number will be generated or if the previous appointment confirmation number will be reused.

As a TMS / appointment scheduling solution, if I change an appointment time, I want to ensure the carrier / broker is notified so that they pickup or deliver the load correctly. As a carrier / broker, I should be notified if the details of an appointment are modified so that I have the most up-to-date appointment information for the load.

If details about an appointment are modified, these appointment details should be pushed to the carrier / broker.

The push should clearly outline what aspects of the appointment have changed. Details about the current and previous values should be outlined in this appointment change notification.

When a change is triggered, the TMS / appointment scheduling solution should be able to provide information about why the change occurred (e.g., product_not_ready, change_to_production_schedule, accomodating_for_staffing, etc.).

As a carrier / broker, I should be able to cancel an existing appointment in a TMS / appointment scheduling solution.

The carrier / broker should be able to provide either an appointment confirmation number or a combination of the load’s primary reference number with stop sequence number and/or a location identifier.

• In addition, the carrier / broker will have the option to provide a BOL number and/or a PO number as additional reference numbers.

Based on these inputs, the API response will return either a success or failure message.

• Failure messages will return a reason code outlining why a particular failure occurred.
• Success messages should contain a confirmation that the appointment was canceled.

The TMS / appointment scheduling solution should be capable of responding synchronously.

If the load is canceled by the TMS / appointment scheduling solution, all associated appointments within the TMS / appointment scheduling solution related to that load should be canceled.

As a carrier / broker, I should be able to fetch the existing appointment details for a particular load at a particular stop in a TMS / appointment scheduling solution.

The carrier / broker should be able to provide either an appointment confirmation number or a combination of the load’s primary reference number with stop sequence number and/or a location identifier.

• In addition, the carrier / broker will have the option to provide a BOL number and/or a PO number as additional reference numbers.

Based on these inputs, the API response will return either a success or failure message.

• Failure messages will return a reason code outlining why a particular failure occurred.
• Success messages should contain the requested appointment’s details including the appointment confirmation number, appointment times, appointment status, and the most recent reason code.

 The TMS / appointment scheduling solution should be capable of responding synchronously.

All Contents Copyright © 2023, J.B. Hunt Transport, Inc. (except where otherwise noted). All rights reserved. All text, images, graphics, animation, videos, music, sounds and other materials on the Site are subject to the copyrights and other intellectual property rights of J.B. Hunt Transport, Inc. Notwithstanding the foregoing, copyrights and intellectual property rights of certain materials on the Site may be owned by another person or entity if so indicated within or adjacent to such materials. J.B. Hunt Transport, Inc. owns the copyrights in the selection, coordination, and arrangement of the materials on this site. These materials may not be copied for commercial use or distribution, nor may these materials be modified or reposted to other sites.