Automate Carrier Selection and Rate Negotiation with Custom AI

Small logistics firms often use their TMS's built-in rating module, like those in AscendTMS or MercuryGate. These tools are great for API-connected national carriers but fail with smaller, regional carriers who operate on emailed PDF rate sheets. The TMS cannot read a PDF, so a dispatcher must manually find the document, search for the correct lane, and type the rate back into the system.

Consider a 15-person 3PL firm trying to cover a last-minute load from Chicago to Atlanta. A dispatcher sends a rate request to ten carriers and seven respond via email with PDFs attached. The dispatcher must now open seven documents, find the correct rate, and manually enter them into the TMS. The first carrier to respond often wins the load, not the cheapest, because the team is under pressure to move on.

The structural issue is that TMS platforms are built for structured data exchange via APIs and EDI, not document intelligence. Their architecture cannot interpret the unstructured data inside an email body or a PDF rate sheet. Adding a new regional carrier without an API means adding more manual work for your team, because the core system lacks the tools to adapt.

This manual process directly impacts margins. Choosing a carrier based on response speed instead of best price can erode profit by 5-10% on every single load. It also means dispatchers spend their day performing data entry instead of building carrier relationships or finding new business.

The first step would be an audit of your carrier communication channels. We would review how your top 15-20 carriers send rate information, identifying which use APIs, which send structured emails, and which use non-standard PDF formats. This audit produces a data processing plan for each carrier, which forms the basis for the system's architecture.

The system would be a Python service built with FastAPI, running on AWS Lambda for cost-effective processing. For API-based carriers, httpx would make parallel, asynchronous calls. For email-based carriers, an AWS SES inbound rule would trigger the Lambda function. The Claude API would parse the email body and any PDF attachments, extracting key fields like MC number, rate, and equipment type with 99.5% accuracy. This structured data is then written to a Supabase database.

The delivered system exposes a single API endpoint that your TMS can call. When you create a new load, the system queries all connected carriers in under 2,000 milliseconds and returns a ranked list directly within your TMS interface. For negotiation, it compares an inbound spot quote to the last 12 months of rate data for that lane and automatically sends a counter-offer. You receive the full source code, and a build for 10 carriers typically takes 4-5 weeks.