What an AI Freight Dispatcher Actually Does
An AI dispatcher automatically matches inbound loads to the best available carriers based on rates and performance history. It also quotes rates, books shipments, and tracks loads without requiring manual entry from your brokerage team. The complexity of building such a system depends significantly on your existing data infrastructure. For brokerages with clean, standardized carrier data within a modern TMS, direct integration is a more straightforward starting point. Teams relying on spreadsheets and email, however, would first require a data ingestion and standardization pipeline. Syntora approaches this by first auditing your data landscape to define the most efficient path to an automated dispatching solution.
Syntora specializes in designing and building AI dispatcher systems for freight brokers. Such a system would automate load matching, rate quoting, and booking processes. Syntora applies its expertise in data engineering and large language models to tailor these solutions to a brokerage's specific operational needs.
What Problem Does This Solve?
Most brokers rely on their TMS, like McLeod or TMW, for load management. But the "automation" modules are often just rule-based. They cannot learn from past performance, so they might offer a hot load to a carrier who is cheap but has a 30% late delivery record on that lane. This forces brokers back into their email and spreadsheets, manually tracking carrier preferences.
It's 4:30 PM on a Friday. A priority load tender hits a broker's inbox. Their TMS suggests five carriers based on who has run the lane before. The broker has to email or call each one, wait for replies, and compare rates. The first carrier to respond gets the load, not necessarily the best one. Meanwhile, a top-performing carrier who was available never even saw the offer because they were on another broker's preferred list.
This manual process does not scale. It creates knowledge silos where one broker knows a carrier is great for a specific route, but that information is not available to the system or the rest of the team. As a result, brokers spend their time on low-value data entry and communication instead of building carrier relationships.
How Would Syntora Approach This?
Syntora's approach to building an AI dispatcher begins with a data discovery and engineering phase. We would audit your existing TMS and historical load data to define the most effective ingestion strategy. Typically, 12-24 months of historical load and rate data would be pulled into a dedicated data store, such as a Supabase Postgres database. Python-based scripts would clean, standardize, and unify carrier names, locations, and other critical features. The goal is a comprehensive dataset supporting detailed analysis and encompassing dozens of relevant features per carrier, including performance history, lane preferences, and historical rates.
The core of the system would be a matching engine implemented as a FastAPI service. This service would query the refined database to identify and rank suitable carriers for new loads. The ranking logic would move beyond basic rate comparisons, incorporating a weighted score that considers factors like on-time performance, preferred lane history, and recency of previous engagements. This Python-based logic would be designed for transparency and adjustability, allowing for easy tuning of weighting factors.
For handling unstructured incoming load tenders, such as those received via email, the Claude API would be integrated. We have experience building similar document processing pipelines using the Claude API for financial documents, and this pattern applies to extracting key information like origin, destination, equipment type, and target rate. The extracted data would be formatted into a structured JSON object to trigger the matching engine. Following carrier selection, the system would be designed to use the Claude API again to generate and send a structured rate confirmation email, aiming to reduce manual data entry errors.
The architecture would typically involve serverless deployment on platforms like AWS Lambda. This design minimizes operational overhead, ensuring compute resources are consumed only when a load needs processing, which optimizes hosting costs. Webhooks from your TMS or integration with a dedicated email inbox would trigger the Lambda function for new loads. The delivered system would integrate with your TMS to write back booking confirmations.
A typical engagement for a system of this complexity, assuming structured data sources, might span 8-12 weeks for initial development and deployment. The client's primary contribution would be providing access to their TMS, historical data, and active participation in defining business logic and testing. Deliverables would include the deployed system, source code, detailed documentation, and knowledge transfer to the client's team.
What Are the Key Benefits?
Cover Loads in 90 Seconds, Not 30 Minutes
From an inbound email tender to a booked carrier in your TMS in under two minutes. Your team stops racing the clock and starts managing exceptions.
Reduce Reliance on Load Boards
By surfacing the best internal carriers first, you build stronger relationships and reduce the 15-20% margin you pay out to public load boards for last-minute capacity.
You Own the Carrier Performance Model
We deliver the complete Python source code in your private GitHub repository. Your proprietary carrier data and matching logic are your assets, not a SaaS vendor's.
Alerts When a Booking Fails
If the system can't find a suitable carrier or an API fails, it sends a detailed failure reason to a dedicated Slack channel for immediate human review.
Integrates With Your Live TMS Data
We build direct API connections to systems like McLeod, MercuryGate, and TMW. The dispatcher works with your team's existing source of truth.
What Does the Process Look Like?
Week 1: TMS Data Integration
You provide read-only API access to your TMS. We pull and analyze 12 months of load history, delivering a data quality report and a proposed carrier scoring model.
Week 2: Build Matching Engine
We build the core FastAPI service and deploy a staging version. You receive a private API endpoint to test load matching against your historical data.
Week 3: Connect Communication Channels
We configure the email parsing and response generation using the Claude API. You receive a demo showing a live email being processed and booked automatically.
Week 4: Deploy and Monitor
We deploy the system to production on AWS Lambda and monitor every transaction for 30 days. You get a complete system runbook and handoff documentation.
Frequently Asked Questions
- What's the typical cost and timeline?
- A project connecting to a modern TMS with a clean API takes 4-6 weeks. The cost depends on the number of data sources and the complexity of your matching logic. A system that only considers rates is simpler than one that factors in weather, traffic, and multi-stop loads. We scope this on our discovery call.
- What happens if the AI can't find a good carrier match?
- The system has a configurable confidence threshold. If no carrier scores above, say, 85/100, it does not book the load. Instead, it posts the load details and the top 3 suggested carriers into a Slack channel for a human broker to make the final call. This prevents bad automatic bookings.
- How is this different from the 'automated booking' feature in our TMS?
- TMS automation is typically based on static 'if-then' rules you configure manually. Our system learns from your historical data to create a dynamic carrier score. It can identify that a carrier is reliable on one lane but not another, a level of detail that rule-based systems miss.
- Can we get an audit trail of why a certain carrier was chosen?
- Yes. Every automated booking logs the reason to your TMS and our Supabase database. The log includes the final score for the winning carrier and the scores for the next five runners-up. This gives you full transparency for every decision the system makes.
- Does this replace our dispatchers or brokers?
- No, it makes them more efficient. It handles the repetitive, high-volume work of booking standard loads. This frees up your experienced brokers to manage complex shipments, negotiate rates on difficult lanes, and build stronger relationships with both customers and carriers.
- What if our carrier data is spread across multiple spreadsheets?
- This is a common starting point. The first phase of the project would involve building Python scripts to ingest, clean, and merge these spreadsheets into a single database in Supabase. This creates the foundational dataset the matching engine needs to operate, typically adding 1-2 weeks to the project timeline.
Related Solutions
Ready to Automate Your Logistics & Supply Chain Operations?
Book a call to discuss how we can implement ai automation for your logistics & supply chain business.
Book a Call