Case study ยท Logistics
BOL automation on a custom TMS
A logistics client was taking bills of lading, proofs of delivery, and rate confirmations out of email and typing them into a system they had built themselves. The client is not named here.
The problem
The paperwork arrived the way it always had: email, with a PDF attached. A person opened the message, found the BOL, POD, or rate confirmation, and typed the load into the TMS.
That worked when the volume was smaller. As the inbox grew, so did the number of people required to keep the TMS current. A missed field or a transposed number showed up later, in tracking or in billing. The TMS itself was not the bottleneck. The re-keying was.
They were not going to replace the TMS. It was theirs, and the rest of the operation already ran on it. The intake had to land in that system.
What we put in place
The inbox stayed the front door. Confirmed documents stopped being typed in by hand.
-
Gmail trigger
A new message in the inbox starts the workflow. The attachment is picked up from that message. Nobody has to forward it to a second tool.
-
Classification
The file is classified as a BOL, a POD, or a rate confirmation, so the right fields are read for that document type.
-
Extraction
Parties, references, dates, and the rest of the load are read off the document.
-
Review queue
If a field is missing, unreadable, or fails a check, the document waits. A person confirms or corrects the low-confidence fields. It is not written to the TMS until then.
-
TMS load
Confirmed documents are loaded into the custom TMS. Those documents are not re-keyed.
Results
- Runs against their custom TMS
- ~20x faster document intake
- Hundreds of staff hours saved weekly
- Zero manual re-keying on confirmed documents
- Documents per day: [docs per day]
- Annual savings: [annual savings]
[client quote]
If your paperwork still starts in email
A pilot is one document type, one inbox, and one TMS, including a custom one. The success metric is agreed before the work starts.