Case Study 01 · Distribution & Third-Party Logistics

Scaling Warehouse Operations Without Scaling the Warehouse Team

A virtual operator drives the same screens your team does. EDI imports, picking dialogs, label printing, customer-portal close-outs. A supervisor watches the live feed from a web console.

The Problem

Your ops team spends most of its day clicking through portals and typing into a legacy ERP. The work is required, repetitive, and you can't hire your way out of it.

The Result

A virtual operator that runs those workflows. One supervisor watches from a web page, and every action is logged.

Operator Console showing the virtual operator's live desktop stream and synchronized action log alongside legacy WMS screens
At a Glance
  • The agent runs seven workflows right now: EDI order imports from retailer portals, building shipments in the legacy OpShip app, order printing, order cancellation, ship-via updates, work-order number updates, and PDF stamping.
  • An Operator Console in the ops app shows the agent's live desktop and its action log. Supervisors don't have to RDP into the VM to see what it's doing.
  • If a screen doesn't look right (a popup, a layout change) the agent hands off to a vision model that reads what's there and picks the next move instead of giving up.
  • One supervisor can watch several agent sessions at a time. Adding capacity stops requiring new hires.
Results
>70 hrs/wk of manual workflows eliminated
7 workflows automated end-to-end
24/7 always-on coverage, no business-hours gap
  • More capacity, no new hires.
  • EDI imports and close-outs run overnight and on weekends, not just during business hours.
  • Every action is timestamped and replayable, so chargeback disputes have real evidence to point at.
The Problem

You can't hire your way out of screen work.

A lot of what a 3PL ops team does every day isn't warehouse work. It's screen work. Someone has to import EDI files through the retailer's portal. Pick tickets and packing slips have to print at the right printer at the right facility. Orders get cancelled at the last minute and need to be backed out of the ERP. Ship-via codes change. Work-order numbers need fixing. This stuff happens hundreds of times a day.

The obvious move is to hire more people. The problem: staff who can navigate a retailer portal and a 90s-era ERP at the same time are hard to find, and harder to keep. The work burns them out. It's repetitive, you can't batch it, and they take heat every time a chargeback shows up. Every uptick in volume means either more hires or more risk of falling behind.

And there's no clean API path. Retailer portals are HTML pages. The ERP is a Windows desktop app from the 90s. So historically your options have been: write scraping scripts that snap when a button moves, or hire more people.

What We Built

An agent that drives the same screens your team does.

A Windows agent runs on a dedicated VM. It logs into the ERP, navigates the retailer portals, fills out dialogs, prints to the right printers, and reports back. It runs on a schedule, when ops asks it to, or in response to events elsewhere in the system. Its desktop and action log stream live into an Operator Console inside the ops app, so a supervisor can watch and step in if something looks off.

How It Works

Four pieces that made this work.

Step 01

Pick the seven workflows to automate first

Situation

Seven workflows were eating up the team's time: EDI imports, building shipments in OpShip, order printing, cancellations, ship-via updates, WO-number updates, and PDF stamping. All manual, all repetitive, all required every day.

Task

Take them off people's plates without losing the judgment the team brings when something doesn't go to plan.

Action

We broke each workflow into explicit steps. Every step knows what should be on screen, how to check it worked, and what to do if a popup gets in the way. Each one gets logged.

Result

All seven workflows now run the same way, at the same speed, every time. Overnight and on weekends included.

Step 02

Make the agent watchable from a browser

Situation

Automation that runs out of sight makes ops leaders nervous, and they're right to be. When something goes sideways, you find out when the chargeback lands.

Task

Give supervisors the same view they'd have standing behind a person at a desk.

Action

The agent streams its desktop as an HLS feed into the ops app. Next to it, an action log shows the current step, the last one it finished, and what's coming next.

Result

Supervisors can audit it from any browser, no RDP needed. One person can watch several sessions at once.

Step 03

A vision model for when the screen changes

Situation

Retailer portals and legacy apps change. A button moves, dialog text shifts, a session expires in some weird way. Traditional UI automation snaps the moment that happens.

Task

Keep the agent going through small changes without paging someone at 2am.

Action

When a step doesn't see what it expects, it hands the screen over to a vision model. The model reads what's there the way a person would and picks the next move. Small surprises stay small. Real problems still escalate.

Result

The supervisor's exception queue ends up full of actual problems instead of "the button moved."

Step 04

Log everything

Situation

When an automated system is touching customer-facing data, you need to be able to point to exactly what happened, and when.

Task

Get an audit trail at least as good as the one a person would leave.

Action

Every click, every step start, every success or failure gets a timestamp and a session ID. The same log feeds the Operator Console live, and the database for after-the-fact review.

Result

A full audit trail behind every automated action, available to ops, IT, and compliance.

Technical detail (for the engineers in the room)

The agent is a WPF desktop app running on its own VM. UI automation runs on FlaUI (which wraps UIA primitives), with an Azure OpenAI vision model as the fallback. The Operator Console lives in the React/MUI client and streams the agent's desktop over HLS via FFmpeg. The action log comes through SignalR. Jobs land on the agent's queue over HTTP from the ops app, and the orchestrator picks them up.

The stack at a glance:

  • WPF · FlaUI drives the legacy ERP and retailer portals through UI Automation primitives, all on a dedicated Windows VM
  • Azure OpenAI picks up as the vision fallback when a UIA target isn't where the workflow expects it
  • React · MUI · FFmpeg · SignalR power the Operator Console — an HLS desktop stream alongside the synchronized action log
  • HTTP queue · orchestrator handle job intake from the ops app and dispatch on the agent side
Why this matters for your 3PL

Switching ERPs won't fix this. Switching the screen work will.

If you run a 3PL, your people spend more time in retailer portals and a legacy WMS, TMS, or ERP than you'd like. Switching systems won't really change that. The pattern we built for our client works elsewhere: figure out the workflows that eat up the most time, put an agent on them, and let a supervisor watch from a browser. You add capacity, and the institutional knowledge tied up in your senior ops people stops being a single point of failure.

Want this pattern in your operation?

Book a free 30-minute call. We'll talk through where your team is spending time and whether a virtual operator is a fit.

Book Discovery Call
Related case studies

Where this fits in the bigger picture

Real-time Ship List grid with validation badges layered on the legacy ERP
Case 03 · Operations

Modern ops on top of a legacy ERP
End-to-end automation timeline for Amazon routing from email intake to confirmed shipment
Case 05 · Amazon

From routing request to confirmed shipment
(407) 349-3633