Case study · Internal tool recreation

Inbound Operations Dashboard

A browser userscript that consolidates three separate warehouse systems into one real-time dock-management view, then predicts which physical lane every package on an inbound trailer will land in, before unloading begins.

◈ Recreation · synthetic dataTampermonkey userscript
3→1
systems consolidated
11+
managers piloting
1,000+
stranded packages caught
v1.2
in production pilot

Recreation notice: this is an interactive recreation of an internal tool, rebuilt for this portfolio with entirely synthetic data. No proprietary systems, names, endpoints, or data are used or referenced.

inbound-dashboard · recreation (synthetic data) ◈ Synthetic data
Loading demo…

Try it: load trailers → containers → packages, explore the tabs, then open Routing config and reassign a door range to a different sorter preset: the lane prediction re-runs live.

The problem

Dock managers planned inbound trailer placement by downloading and filtering Excel exports, a ~10-minute manual task that went stale the moment it finished. There was no way to know where a trailer's packages would physically accumulate until the trailer was already unloading, so lane congestion and door conflicts were discovered reactively, mid-shift.

The idea: predict the lanes before the doors open

Three internal systems each held a piece of the answer: one knew the trailers and their package volumes, one knew the facility's sorting equipment and lane topology, and one could report each package's routed destination chute. None of them talked to each other in a single view. The dashboard pulls all three together in the browser and runs a classification engine over the result:

package → routed chute → owning sorter → (preset overrides by size / container / door) → physical lane

The output is a per-trailer, per-lane forecast: which lanes will absorb how much volume, from which trailers, by when. Managers can rebalance doors, pre-stage labor at the right lanes, and spot bottlenecks while trailers are still in transit.

How it's built

  • Staged data pipeline. Trailers load first (fast metadata), then per-container detail, then the per-package destination query (an asynchronous, paginated long-poll). Buttons unlock as prerequisites arrive, so the tool is useful within seconds and gets deeper on demand.
  • Configurable routing rules. Lanes are defined by pattern-matching rules against physical stacking areas; reusable sorter presets support per-size and per-container overrides and can be assigned to dock-door ranges. Configs are per-facility, exportable as JSON, and cached.
  • Everything in the browser. Single-page dashboard with five tabs (Overview, Trailers, Containers, Lanes, Settings), SVG/canvas charts, CSV export, dark mode for night shifts, and persistent state, with no backend changes required to ship it.
  • Real-world save. The lane view exposed trailers moved off-door prematurely and marked complete while still holding freight, surfacing 1,000+ packages that would otherwise have missed dispatch.

What the demo shows

This recreation implements the actual classification algorithm on a seeded synthetic dataset (12 trailers, ~3,000 packages). The routing-config editor is live: change which sorter preset a door range uses and watch the lane distribution recompute: the same interaction managers use to plan door moves.