Computer vision workflow / Industrial operations / Concept prototype

Moving an under-fill alert to where someone can still act

Check pallets in the staging lane before they enter an export container, and alert the shift lead while the load can still change.

Role: Product Manager, self-initiated
Period: September – November 2026

Simulated decision moment in the Enterprise view. Shipment totals are real; pallet heights, sequence and outcome are simulated, and the prototype says so on every screen.

83 export shipments analysed

64 / 83 containers already near their weight limit

35 / 36 simulated stuck loads are parts that cannot be stacked

5 linked prototype views

Team: Solo, with peer and AI review
Product stage: Concept prototype suite
Customer: Shift leads and operations leaders
My ownership: Discovery, analysis, prototypes, engineering, pilot plan
Key constraint: Real totals, no pallet-level data

In short.

The problem: An automotive parts exporter believed its shipping containers left the plant 30% empty and asked for an alert when one was under-filled.
The catch: By the time a container is full, the doors are sealed and the driver leaves within minutes. An alert then changes nothing.
What I built: A browser prototype that checks pallets while they still wait outside the container, and tells the shift lead which pallet to load first so that everything fits.
What I found: In the 83 real shipments, most of the visible empty space is really a weight limit. In my simulation, most loads that do not fit cannot be fixed by reordering at all: stacking rules matter more. Pallet heights are simulated, and the prototype says so on every screen.
Try it: Open the Container demo below, press Watch the load, and accept or override the recommendation when it appears.

The customer asked for an alert nobody could act on.

This is a self-directed product study, built from a customer brief I was given. The customer, an automotive parts exporter, believed its containers left the plant 30% empty. The VP of Operations wanted a real-time alert when a container was going out under-filled.

The logistics manager pushed back: the doors are sealed and the driver is moving about four minutes after the last pallet goes in. My first answer agreed with him and set the alert aside, focusing instead on the shipping export.

The data could not answer the question it was asked.

The brief's three-week shipping export covered 83 containers. Weights were recorded. The declared volume was not measured: it was pallet count multiplied by one fixed figure per product family, and the brief confirmed nobody had ever measured actual cube.

36.6% Nominal volume gap across the fleet. Pallet-master volume, not measured void.

64 / 83 Containers at 90% or more of payload. Weight likely explains much visible headroom.

19 / 83 Light, high-cube loads where measured space might be recoverable.

Payload against declared volume for each of 83 export containers, coloured by product family. Most loads sit near the payload limit; a smaller group is light but nearly full by volume. — Fleet analysis, built from the real shipping export. Each dot is one container; above the dashed line, weight likely explains the visible headroom.

Move the check to where a decision still exists.

The site's existing safety cameras already faced the staging lane, not the container interior. The brief also noted that the shipping system builds a load plan the day before, and the shift lead overrides it by pulling the next thing that fits. So the product works with that habit rather than against it.

Measure in stagingReplay load planAdvise earlyHold at the doorShift lead decides

After every pallet, the prototype replays the remaining load plan under a simple stacking rule and tries pulling each reachable pallet forward. It shows a known fix as an advisory straight away, and only blocks a pallet at the door when waiting one more pallet would lose the fix.

What I built.

The idea is one product. The prototype is five linked views of it, each answering a different question. They run in the browser with no install, and they share the same data, rules and wording.

Open the prototype

Two sequences, side by side.

A recommendation is easier to trust when you can see what it would change. Live load in the Enterprise view has a switch for exactly that. Planned sequence shows the finished container if the load plan is followed as given: 37 of 38 ship, with one pallet left at the dock and three stack positions lost. Platform sequence shows it with the one recommended swap applied: 38 of 38, two positions lost. Same loader, same pallets; only the order differs.

The same container shown twice. Under the planned sequence 37 of 38 pallets ship; under the Platform sequence all 38 ship. — Planned sequence above, Platform sequence below. Both are simulated, and the screen says so.

The stepping controls pause while a comparison is open, so a finished layout cannot be mistaken for progress. If the shift lead has already overridden the swap and the window has closed, the Platform view falls back to the plan instead of showing a fix nobody can make.

Designing for trust before accuracy.

A recommendation from a camera is only useful if the shift lead trusts it. The prototype treats uncertainty as part of the product, not an edge case.

Abstain on weak readings A height reading below the confidence bar is withheld; the staging measurement stands.

No recommendation without identity A pallet whose label was not read is excluded until it is scanned.

Overrides are signals The shift lead can override with a reason. Repeated overrides mean the rule needs review.

Every claim is tagged Evidence is marked real, specification, inferred or simulated, on every screen.

Evidence view listing every pallet event with identity and status tags, beside an observation record that labels real, simulated and assumed values. — The evidence view. Every pallet event and every claim carries its source: real shipment totals against simulated heights, readings and outcomes.

From one container to 83.

One container shows the idea works. It does not show whether it generalises. So I ran every export container through the same loader and the same rule. Heights are generated per product family, so these results show how the rule behaves, not what happened on the dock.

44 / 83 Fit outright under the assumed rules. No sequencing issue.

3 / 83 Rescued by a single pallet swap. All three are harness assemblies.

36 / 83 Leave pallets at the dock, and no single swap helps.

The pattern is what mattered. 35 of the 36 stuck loads are brake rotors and cast housings, the two families the brief's scoping answers say nothing should be stacked on. For them, pallet order is not the lever; stacking permission is. The 36th is a single sensor-module load of 43 pallets.

Fleet table with one cast-housing container selected: 20 of 25 pallets planned, no improvement from any swap, and its generated pallet heights. — The fleet table. Every container, the same rule. Selecting one shows its generated pallet heights and why it is stuck.

The real log shows only five of the 83 shipped partial. So either the packaging allows more than I assumed, or the loads are laid out differently from my model. Either way, the simulation turns a vague hunch about empty space into a specific question a pilot can test.

The economics, sized honestly.

Sequencing alone is small. As an illustrative scenario, if every volume-bound export rolled one pallet that sequencing could have saved (about 1/38 of a container each), that would be about nine containers and €8–10k a year. No paid container has been shown saved. It also ignores the cost of a pallet left behind: slots are booked weekly per lane, and a missed sailing can cost three days.

The case for building it is different: a screen the shift lead uses on every load leaves measured pallet heights behind, which is data the customer has never had. Container-count decisions also depend on floor positions, stacking rules and rates, so measured cube is one input, not the answer.

From pilot to operational.

Three people have to say yes, and they need different things. A product that only satisfies the one who holds the budget does not survive the dock.

VP of Operations Budget holder. Wants a number and a decision. Pilot: a baseline of how often the plan loses positions or pallets, built from real load plans before any camera is installed, and a plain statement that most visible empty space is a weight limit. Operational: a monthly report of pallets protected, advice followed and overridden, and what it saved.

Plant Logistics Manager Owns the dock. Sceptical, and right to be. Pilot: shadow mode first, so he sees the advice and where it is wrong without the crew acting on it. No alert at the sealing moment, and a hold only when it changes the outcome. Operational: he owns the stacking rules, and repeated overrides tell him which one to review.

Shift lead and loaders Use it on every load. One message at the moment a decision still exists, an override in one tap with a reason, and no extra scanning beyond pallets whose label was not read.

Four phases, each ending in a decision

Replay. Run real load plans through the loader and tape-measure a sample of pallets. Exit: the band where sequencing matters is large enough, and stacking rules are signed off.
Shadow at one camera door. Read pallets in staging, log advice, show it to nobody. Exit: height error inside target, and the advice would have been right often enough.
Live advisory at the same door. The shift lead sees the advice, and every override is logged. Exit: containers and pallets saved against the baseline, and the logistics manager agrees to expand.
Operational. More doors (cameras cover 2 of 6 export doors today), a live load-plan feed and the shipment-to-container link. Exit: the monthly report is something the VP uses to decide.

The ask

To start, I would ask the VP for three things: a covered export door and its shift lead for the pilot loads, a week of tape measurements plus the load plans for those shipments, and packaging and driver sign-off on stacking. The first two phases ask nothing of the crew, because no advice is shown until the logistics manager has watched it in shadow mode. If height error misses its target, the pilot stops there, and the replay still leaves the customer with a measured answer about their own loads.

What I learned, and what I would change.

Interrogate the request, then return to it

I was right that an end-of-load alert had no action behind it, and wrong to stop there. The customer's request was pointing at a real need; the timing was the problem.

Label simulation as boldly as results

Early reviewers understood the idea but remembered the simulated 38-of-38 outcome as if it had happened. Banners, labels on every result and a persistent counterfactual note fixed what small disclaimers could not.

Run the idea at fleet scale

One polished container hid the most important finding. Running all 83 showed that the loads that fail are almost all one kind of product, which moved the pilot's first question from sequencing to stacking rules.

Next experiment

Measure a week of staged pallets against tape and the real load plan. That single dataset would show whether the camera is accurate enough, whether the sequencing problem occurs often enough to matter, and whether rotors and housings really are single-high.

Next case study

Designing a digital BAU operating model

Have a product problem worth solving?

I am based in Dublin and interested in Product Manager opportunities across Ireland and the EU.

Start a conversation