Tai TMS
How Tai integrates with Chaine
In this guide, you will understand how Tai integrates with Chaine. Whether you are using Chaine's Booking, Copilot or Tracking features, the integration is the same. The integration is a two-way sync between Tai and Chaine. This means that any updates made in Tai will reflect in Chaine and vice versa. Once the integration is in place, your Chaine Implementation Specialist will work with you to enable the features you signed up for.
If you're looking for how to integrate Tai with Chaine, please refer to the Chaine Integration Guide.
Integration Deep-dive
Let's look at some more details on how Tai integrates with Chaine.
Field mapping
Chaine has a "standard" mapping of the fields of a load in Tai to fields in Chaine. This means that in most cases the integration is already built and ready to go.
Special field mapping
However, not all companies are they same as they have different set of customers and freight-types with differing requirements. So the standard mapping is customizable for every customer and during the implementation process led by your Chaine Implementation Specialist, they will work with you to identify any special requirements or scenarios to make sure the correct fields are mapped.
See Carrier Details below for an example
Sub organizations
If your team is separated into different offices, groups, pods or agencies, Chaine can also map these fields to the correct groups in Chaine, so that these separate "sub-organizations" will have their own workspace inside of Chaine (See Sub organizations). We will work with you during implementation to idenfity these sub-organizations and map them correctly to workspaces inside of Chaine.
For example, if you have an agency Dallas, but have several Pods working out of your New York office, Chaine can map these to the correct groups in Chaine, so that these separate "sub-organizations" will have their own workspace inside of Chaine.
In the example above, let's say the Dallas agency is completely isolated from the rest of the organization, and there is no user-over lap. In this case, the Dallas agency can have their own workspace in Chaine, and the users in the Dallas agency can only see their own loads, and not the loads from the rest of the organization.
The individual Pods in New York can also have their own workspace in Chaine, and the users in the Pods can only see their own loads, and not the loads from the rest of the organization or the Dallas agency.
But let's say a user in one of the New York Pods, i.e. Pod A, needs to see the loads from a different pod, Pod B. You can either add that user to both workspaces (one for Pod A and other for Pod B) inside of Chaine, or if the user is added on loads that are from both Pods, then Chaine will automatically add that user to both workspaces.
Booking
Loads that are "available" for carriers to book or view on the Carrier Hub in Chaine can be identified by their specific status in Tai. Since the integration between Tai and Chaine is very robust, your Implementation Specialist will work with you to identify the correct status that will trigger the load to be available for booking in Chaine.
This can be done for loads in "Committed" status or "Quoted", or any other logic pertaining to specific fields on each load. Your Chaine Implementation Specialist will work with you during the implementation process to nail this down.
Loads will automatically be marked covered in Chaine when they are assigned a carrier in Tai. And if a carrier falls off and moves back to Committed status (or whatever logic we decide during the implementation), the load will be marked as "available" in Chaine again.
Tracking
Fields that update in Tai
When the driver updates stop statuses with date and time from the Chaine driver app or the dispatcher updates them from the Chaine web app, all updates will reflect to Tai. Current statuses supported by Tai are "actual pickup arrival", "actual pickup departure", and "eta to delivery".
Only the status updates for 'Arrived Pick', 'Departed Pick', 'Arrived Drop', and 'Departed Drop' will appear on the Revenova dashboard. Note, though most customers keep these on, these are completely configurable and can be turned off or on if needed.
Here is an example of where the Actual Arrival Date, Actual Arrival (Time), Actual Departure Date, and Actual Departure (Time) gets updated automatically.
Carrier details
The driver and dispatcher fields are typically mapped from under the "Shipment References" section in Tai. If you don't have the fields below, or they are named differently, your Chaine Implementation Specialist will make sure these are properly mapped. Important information typicall includes:
- Driver Phone: Used for tracking and copilot features
- Dispatcher Email: Used for tracking, booking and copilot features
- Truck (and/or Trailer) Number: Used for tracking; specfically for ELD integrated carriers
If you don't have Dispatcher reference fields, we recommend creating them as shown below. This powers more powerful integrations with Chaine around key features of automated check calls, booking opportunities and POD collection to name a few.
Alerts that update in Tai
When there are exceptions that trigger based on any Chaine Copilot rules you have set up, this can also be fed into the "Alerts" section in Tai as a "Load Track Exception".
Tracking map in Tai
With the Chaine integration, Chaine will populate the locations on the tracking map inside of Chaine which is accessed by clicking the "Location History" on a load in Tai.
