Building a Freight Carrier Selection Workflow
Overview
I built a demo inspired by Oracle OTM’s carrier selection workflow. It covers the path from reviewing shipment data to comparing carriers and preparing a tender draft.
I chose freight because carrier selection brings together documents, carrier records, and operational requirements. It gave me a concrete way to explore how different sources of data can support a carrier decision.
- Date
- July 4, 2026
- Tools
- Figma, Next.js, TypeScript, Prisma, PostgreSQL, Playwright, Mistral OCR
- Focus
- Workflow design, explainable matching, freight operations
- Deliverables
- UX flows, full-stack prototype
From shipment to draft
Once the shipment data is ready, the operator can run the matching process and review the result for each carrier. I wanted every result to show what was checked, how the outcome was reached, and which data supported it.
The operator can then prepare a tender draft. Before saving it, the system checks that the matching result is still current and records the action.
Handling uncertainty
Not every missing piece of information should exclude a carrier. When the system cannot confirm something, it returns Review required. When it finds a clear incompatibility, it returns No match.
This helps the operator distinguish between information that needs attention and a requirement the carrier cannot meet.
Reviewing documents
I used Mistral OCR to extract possible values from shipment documents. These values are presented as suggestions rather than written directly into the shipment.
The operator can confirm or correct them before continuing. Matching only becomes available once all the required information has been reviewed.
Keeping data in sync
This project helped me understand how data moves through an operational workflow. The main challenge was not the matching itself, but keeping the data, results, and operator actions in sync as information changed. I solved this by saving the data and rules used for each matching run.