I’m exploring an AI “exception resolver” for small freight brokers: brutally honest feedback wanted
I’m exploring a SaaS idea and would love feedback from people who know freight, logistics, or B2B SaaS.
The problem: Small/midsize 3PLs and freight brokers often spend hours manually resolving EDI/freight exceptions.
Someone has to figure out:
• What exactly mismatched?
• Which line/item/load is affected?
• What was expected vs. what was received?
• Why did it happen?
• What needs to be fixed?
• Who needs to be contacted?
My initial idea is an AI agent that takes an exception and turns it into something like:
Load #48392 — Rate mismatch
Expected: $1,850
Received: $2,050
Difference: $200
Likely cause: Accessorial charge missing from the shipment record.
Recommended action: Verify detention documentation.
Draft email: Ready for an operator to review and send.
The workflow would be:
Detect → Explain → Recommend → Draft → Human approves
I’m deliberately not trying to build another giant TMS or fully autonomous EDI system.
The initial wedge would be one high-volume exception workflow, with a target customer of smaller 3PLs/brokers that have enough EDI volume to be dealing with these issues every week.
I’m considering roughly $149/month, but that’s just a hypothesis.
What I’m trying to figure out
- Is EDI exception handling actually painful enough that someone would pay to eliminate it?
- Which specific exception type is the biggest time sink?
- Would a small 3PL pay ~$149/month for this?
- What TMS/EDI integrations would be absolutely necessary?
- Would you trust AI to identify the problem and draft the resolution, with a human approving the final action?
- Is this solving a real problem, or am I just building a feature that existing TMS/EDI platforms should already have?
If you work in freight brokerage, logistics, EDI, or run a small 3PL, I’d especially love to hear about the last EDI exception you had to manually resolve.
I’m much more interested in hearing “this is a terrible idea because…” than getting polite validation.
The price should follow exception economics, not seat count. Run a shadow-mode pilot on 50 historical cases and measure minutes to resolution, manual touches, reopen rate, and invoice or payment delay. Start with CSV or forwarded-email intake before committing to a deep TMS integration. If the system can explain the mismatch and prepare the next action accurately while the operator remains the approver, you can prove value without asking the broker to trust autonomous execution.
The fact that you're asking for the last real exception someone handled is more useful than hypothetical feedback. Curious what kinds of exceptions people actually spend the most time resolving.