There are two fundamentally different types of freight optimization tools on the market, and the difference is not feature set or algorithm sophistication. It is whether the tool reads from your TMS, or reads and writes to it.
A tool that reads your shipment data and outputs a suggestion -- a reroute recommendation, a carrier option, a cost comparison -- is an advisory layer. A tool that reads your data, generates a rerouted plan, and writes the confirmed result back to your TMS record is an operational layer. The practical difference in how the desk uses each is enormous.
Why the write-back matters more than the algorithm
When a coordinator receives a reroute recommendation from a tool that does not integrate with the TMS, she then has to manually enter the changes. For a single reroute on a straightforward load, that might take three to five minutes. For a load with multiple legs, carrier-specific booking numbers, and customer notification requirements, it can take fifteen to twenty minutes. Multiply that by twelve disruption events in a month and you have three to four hours per month of coordinator time spent on data re-entry -- for a tool that was supposed to reduce manual work.
More importantly, the re-entry step introduces errors. A coordinator who has just spent twenty minutes resolving a carrier issue and is moving on to the next disruption is entering data while already partially focused on the next problem. Booking number transpositions, wrong departure date entries, and missed leg updates in multi-stop shipments are common in this context. These errors surface later as invoice discrepancies or as phantom loads in the TMS that require cleanup.
A tool that writes confirmed reroutes back to the TMS eliminates the re-entry step entirely. The coordinator confirms the plan in the replanning interface. The TMS record updates. The desk stays current without additional work.
What TMS integration actually requires technically
The integration question is more nuanced than "does it have an API." Different TMS platforms expose different data structures, and the level of write access they allow varies significantly.
For read access, most modern TMS platforms support REST or SOAP endpoints that expose shipment records, carrier assignments, and booking details. Reading this data is relatively straightforward -- it is the reason visibility platforms can pull shipment feeds across many different TMS environments without bespoke integration work per customer.
Write access is different. Writing a confirmed reroute back to a TMS means updating carrier assignment records, modifying departure dates and ETAs across all legs of a shipment, triggering customer notification workflows if the TMS manages those, and in some cases updating EDI transaction records that have already been transmitted (204 transaction sets for freight bills of lading, 210 for invoices). The complexity varies by TMS architecture, and it requires the integration to understand the platform's data model at a deeper level than read-only access does.
EDI-based TMS platforms -- common in European freight forwarding and in North American operations that follow standard transportation EDI conventions -- have specific transaction set structures that write-back integrations need to handle correctly. An update to a carrier assignment on an in-transit load may require an EDI 204 modification rather than a simple API PATCH call. A replanning tool that does not understand this distinction will write back to the record correctly in the database and create a mismatch with the EDI transaction stream.
The integration model and the coordinator's workflow
The way the integration model affects daily desk workflow is more significant than most teams anticipate when evaluating a replanning tool. Consider two scenarios on the same disruption event:
Scenario A (advisory-only tool): Port slot closes at 14:30. Alert fires at 14:33. Coordinator reviews reroute suggestion at 14:38. She calls the carrier to confirm capacity. Carrier confirms at 14:51. She goes to the TMS to update the load record. She enters the new carrier, updates the departure date and ETA, adds a note on the original slot closure, notifies the customer via the TMS notification workflow. Update complete at 15:09. Total time: 36 minutes.
Scenario B (integrated tool): Port slot closes at 14:30. Alert fires at 14:33. Coordinator reviews reroute plan with carrier options scored by cost and transit time at 14:37. She selects the recommended option and clicks confirm. The tool confirms capacity with the carrier via API (carrier integration was set up during onboarding). TMS record updates automatically with new carrier, revised ETA, and event log entry. Customer notification triggers from the TMS workflow. Update complete at 14:44. Total time: 11 minutes.
The 25-minute difference per event is the operational value of the integration model. At twelve disruption events per month, that is five hours. At thirty events, it is twelve and a half hours -- which is more than a full coordinator workday.
What integration does not solve
Good TMS integration is a prerequisite for an effective replanning tool, not a guarantee of effectiveness. The replanning logic still has to be right. A tool that writes bad reroute plans back to the TMS very efficiently is worse than an advisory tool that the coordinator can override before any data changes hands.
The integration model assumption worth examining before evaluating any replanning tool: how does the tool handle a situation where the recommended plan turns out to be wrong? If a carrier confirms capacity in the tool interface and then cannot deliver because their actual available equipment is committed elsewhere, what does the tool do? A well-designed integration handles the failure state gracefully -- rolls back the TMS update, flags the failure, and presents the next option. A poorly designed integration leaves the coordinator with a committed TMS record and a carrier that cannot perform.
This is why the desk should always retain confirmation authority. Kilimanjaria's design keeps the coordinator as the confirmation step -- the tool presents the rerouted plan with carrier confirmation, the desk confirms it. That step is not friction; it is the handoff point where human accountability and tool efficiency work together. We are not looking to automate the decision itself, just the analytical and data-entry load surrounding it.
Evaluating integration depth in a vendor conversation
When you are evaluating a replanning tool and integration is a consideration, three questions get to the substance quickly:
First: does the integration write back to the TMS in real time, or does it queue updates for batch processing? Batch processing introduces latency between a confirmed reroute and the updated TMS record -- which means there is a window where the TMS is wrong. For high-frequency disruption environments, real-time write-back matters.
Second: how does the tool handle EDI transaction sets for loads that have already transmitted booking documents? If the TMS uses EDI for carrier communications and the replanning tool does not understand the transaction set structure, write-back updates create EDI discrepancies that require manual cleanup.
Third: what does failure look like? If the carrier API confirmation fails after the coordinator has clicked confirm, what happens to the TMS record? A clear answer to this question tells you whether the vendor has actually tested their failure paths, not just their happy path.