A practical build plan for mid-market freight brokers: SMS-driven check calls, structured parsing, and a workflow that keeps dispatchers focused on exceptions.
Context
Most mid-market freight brokers are still running dispatch operations through a mix of phone calls to carriers (check calls), email threads with customers, and manual updates inside a TMS such as McLeod, Tai, or Revenova.
This works at low volume. But once a team is managing 150 to 300 loads per day, it starts to break:
- Dispatchers spend hours on repetitive check calls
- Customers constantly request status updates
- Updates are delayed or inconsistently logged
- Exception handling is reactive instead of proactive
This document outlines a focused, practical approach to automating one part of that workflow.
Scope
Included
- Outbound check calls via SMS (voice optional)
- Parsing carrier responses into structured updates
- Logging updates into a structured layer
- Basic escalation rules
Not Included
- Full TMS replacement
- Complex exception resolution
- Full email automation
- Pricing and quote workflows
Current Workflow
Dispatchers typically call carriers every 2 to 4 hours, ask for status updates, log responses manually, and notify customers if needed.
At scale this means roughly 3 to 5 minutes per call, hundreds to thousands of calls per day, inconsistent logging, and a high degree of repetition.
Target State
The system handles routine status collection end to end:
- Sends SMS to carrier
- Receives response
- Parses into structured data
- Logs the update
- Flags issues if detected
Dispatchers only handle exceptions.
Architecture Overview
The build splits cleanly into a handful of components:
- Trigger layer for timing and rules
- Communication layer for SMS and optional voice
- Parsing layer powered by an LLM
- Workflow engine for rules and routing
- Data layer for structured updates
- Human review layer for exceptions
Example Parsing
Carrier reply: "Running about 45 mins late, stuck near Dallas, should be there by 3."
The parser extracts a structured record with the carrier's approximate location ("Dallas area"), a delay flag set to true, an ETA of 3:00 PM, and a risk flag of "minor_delay". That structured shape is what gets written back to the TMS and used to drive downstream notifications.
Before automating any check-call workflow, write down what a "good" structured update looks like. That schema becomes the contract between the LLM, the workflow engine, and the TMS — and the baseline for every later change.
Implementation Plan
Week 1
Map the current workflow, define triggers and escalation rules, and stand up the communication layer with a real SMS number wired to a single test lane.
Week 2
Build the automation logic, run it against a small subset of active loads, and add a human review queue for anything the parser is not confident about.
Week 3
Expand coverage across more lanes, add retry and escalation logic for non-responsive carriers, and pull dispatchers out of the loop on the routine cases.
Expected Outcomes
- 40 to 60 percent reduction in manual check calls
- Faster update cycles to customers
- More consistent and queryable update data
Limitations
This system does not replace dispatchers, does not automate all edge cases, and still requires human oversight on anything outside the routine path. The point is to remove the repetitive 80 percent so the team can focus on the 20 percent that actually needs judgment.
Expansion
Once the check-call loop is stable, the same architecture extends naturally into status email automation, exception routing, and eventually quote-to-book workflows.
Summary
This approach focuses on automating a single high-frequency workflow without disrupting existing systems. The goal is to reduce repetitive work while keeping humans in control of exceptions.