Automate Carrier Selection & Rate Negotiation

Many small logistics companies rely on their TMS, like AscendTMS or MercuryGate, for rate management. These platforms are useful for storing rate data, but they often fail when it comes to acquisition. If a smaller carrier does not offer an API or EDI integration, an operations person must manually look up the rate in a portal or a PDF and type it into the TMS. The TMS becomes a static database, not a dynamic quoting tool.

Consider a 10-person freight brokerage quoting an FTL shipment. The dispatcher opens three separate carrier web portals and a master Excel spreadsheet containing rates for five regional carriers. They re-enter the load details nine times. One portal times out. The spreadsheet has an outdated fuel surcharge. The best rate comes from a PDF rate sheet, but they must manually cross-reference it with an email addendum from last week. This entire process takes 25 minutes of error-prone, low-value work for a single quote.

The structural problem is that off-the-shelf TMS platforms are not document intelligence systems. Their architecture assumes structured data inputs via API or EDI. They are not built to parse unstructured data from a PDF, an image of a rate table, or the body of an email. Solving this requires a dedicated data processing pipeline, a capability completely outside the scope of a general-purpose TMS.

The first step is an audit of your carrier mix. Syntora would map how each of your top 10-15 carriers communicates rate and capacity information: REST APIs, legacy EDI, web portals, PDF rate sheets, or simple email text. This audit determines the right data extraction method for each source and creates a clear technical roadmap for the project.

For carriers with modern APIs, the system would use a FastAPI service to normalize requests and query them in parallel using httpx, which can handle 10+ concurrent requests with a P99 latency under 200ms. For documents and emails, the approach uses the Claude API. We've built similar document processing pipelines for financial documents, and the pattern applies directly to logistics. An AWS Lambda function triggers on new files, parses the content with Claude, and stores structured rate data in a Supabase Postgres database.

The delivered system exposes one API endpoint that your team can use from your existing TMS or a simple web form. You receive the full Python source code in your GitHub, a runbook for maintenance, and a dashboard to monitor data parsing accuracy. The entire system typically has a hosting cost under $50 per month on AWS, providing a powerful quoting engine without expensive software licenses.