Company

We Replaced an Admin with 40 Lines of Code

When a logistics company called us, they were embarrassed by how manual one recurring task had become: extracting shipment confirmations and entering them into a TMS. An operations admin spent 15 minutes per shipment opening emails, copying tracking numbers, matching SKUs, and updating records. That task lived at the intersection of boredom and error: on a busy day the team handled 40 shipments and the admin burned an hour. On a slow day she still spent 30–60 minutes. The problems: human error, inconsistent email formats, and a slow velocity that scaled linearly with volume.

We promised three things: reduce time per shipment, keep error rates low, and avoid a fragile, hard-to-maintain system. The solution ended up being 40 lines of code and a pragmatic approach to failure.

Design decisions

First, we accepted that email formats would be noisy. There were PDFs, forwarded chains, and three different courier formats. Instead of trying to parse every possible layout, we targeted the high-signal parts: tracking number patterns, SKU codes, and key phrases like “shipped” and “ETA.” We used a simple pipeline: pull new emails → run lightweight pattern extraction → validate against the database → create or update the TMS record → surface uncertain matches for human review.

Implementation

We built a small service that runs every minute. It authenticates to the company’s mailbox, streams new messages, and applies a prioritized set of regular expressions and heuristics. If a confident match is found (e.g., a tracking number with matching SKU and order ID), the service calls the TMS API and marks the email processed. If confidence is low, it creates a short review task in the admin dashboard with the original email attached.

The core is 40 lines of code because we relied on existing libraries for IMAP/SMTP handling and the TMS SDK. The custom bits are the heuristics and a tiny state machine to avoid double-processing. We prioritized observability: logs, example extraction, and a one-button rollback for any automated update.

Outcomes and numbers

On day one after launch we processed 312 shipment emails. 78% were fully automated, 22% went to review. That translated to time savings of roughly 12 minutes per automated shipment (the admin would have spent the full 15 minutes), and 3 minutes per reviewed shipment. Across the month that turned into ~85 hours saved — the equivalent of two full-time workweeks. Error rates fell from roughly 3% manual-entry mistakes to under 0.2% for automated writes; the small number of edge-case mistakes were all recoverable via the rollback.

Tradeoffs and learning

We deliberately avoided an ML-first approach. A model would have been neat, but it introduces retraining, edge cases, and expensive inference costs. Regular expressions and heuristics plus a human-in-the-loop review for low confidence gave us a pragmatic balance: high automation where safe, visibility where unsure.

We also learned to build for transparency. The operations team wanted to see the extracted fields alongside the source email. That made them trust the automation within days.

Advice for teams

If you have a repetitive, semi-structured task: start small and measure. Automate the 70–80% of cases you can confidently handle and route the rest to a light review queue. Favor simple, observable code over an opaque model at first. Focus on rollback and recoverability — mistakes are unavoidable; being able to fix them quickly is crucial.

Final thought

Replacing an admin isn’t the right language; we augmented their work to scale and remove the worst parts. The admin who once spent time on copy-paste now manages exceptions and continuous improvement. Forty lines of code bought back attention and sanity — and the team used that time for higher-value work.