AI decision support · Concept

Smart Allocate

An AI-assisted carrier and service selection concept for Metapack’s Delivery Manager, designed to handle peak-season volume without taking the decision away from the people who did not yet trust the model.

The Smart Allocate dialog over the consignment queue, listing 11 proposed allocations, each with a reason, a confidence percentage, a proposed carrier and a proposed service, and an Allocate Selected button.

Role

Sole designer on Smart Allocate, end to end from concept to polished UI, with no product manager assigned.

Team

Back-end and front-end engineering leads, day-to-day contact mainly the front-end lead; no one else from the Metapack design team was involved.

What I owned

The objective, success criteria and scope, and the user research, with customer service and account management as research partners.

What shipped

Designed and delivered to the backlog, ready for build.

The Smart Allocate dialog, large and centred over two Delivery Manager queue screens: the unallocated consignments behind on the left, the same queue with services chosen behind on the right.

The queue before, the suggestion, the queue after. The system proposes a carrier and service per consignment with its confidence; nothing is allocated until an operator confirms it.

Context

Delivery Manager is where a retailer’s outbound consignments get a carrier and a service assigned. It was already configurable: cost thresholds set against the retailer’s margins, carrier availability rules, service-level agreements fed in from the retailer’s own e-commerce systems. It would narrow the field to a suitable subset.

What it would not do is choose. Metapack’s own analysis of system log data put the share of allocation still done manually at up to 70%. That was still a person’s job, consignment by consignment: working through the queues in dense tables, setting criticality and making sure every allocation was correct, whether a hard rule captured in the system had already set it or not, before submitting them. The people doing it were the operators: warehouse and depot staff, working in an interface that was flexible but unpleasant to use.

Delivery Tracker was live by then, and the volume problem was the obvious next thing on the roadmap. Peak season concentrates a large share of a retailer’s annual trade into a few weeks. Metapack’s Q4 data for a sample of medium-to-large retailers showed peaks running to hundreds of consignments a minute, and keeping the queues moving through it meant pulling staff from elsewhere in the business or running overtime. The concept was aimed at the highest-volume accounts first, because they felt the problem hardest. The cost was the staff the allocation work needed, at the point in the year they were least available.

Director, User Experience

·

Metapack

·

October 2019 – February 2022

Constraints

The machine learning underneath did not exist yet, so this was a concept designed to be right once it existed, with no working model to test end to end.

Discovery with the enterprises buying it, and with the staff managing the queues, showed a trust problem. They were uncomfortable handing carrier and service selection over untested, and most uncomfortable at peak, when the right choice moves day to day and a wrong one is most visible.

Delivery Manager ran on a legacy stack, and the front end was the harder half. There was no design system underneath, the implementation was understood by a small pool of people, and changing or testing it was expensive. New value had to come through narrow, additive interventions, and anything that needed new machinery built to support it was out.

Decision

Suggest, don’t decide. The system would put forward a carrier and a service, and a person would still have to accept it, a human-in-the-loop design. The technology could have gone further; the research said the people operating this were not ready to be removed from the decision.

Two concepts were taken far enough to choose between: one brought suggestions into the consignment table with no extra step, the other put them behind a Smart Allocate trigger in a dedicated modal. The modal won on engineering cost, which the legacy front end made the deciding constraint. In the modal, the designed flow took allocation from the existing operator flow’s five steps to three and let a batch of consignments be actioned at once.

Autonomy was designed to graduate in, starting on low-risk volume once there was evidence the model was reliable there. An explicit correction interface wasn’t affordable on that stack, so the loop was made implicit: uptake of suggestions, and what operators chose instead when they rejected one, read together as the signal for where the model was weak. The confirmation step was doing double duty as the mechanism for improving it.

Trade

Putting Smart Allocate behind a trigger cost discoverability, and made single-consignment decisions slower, since acting on one consignment now meant entering and leaving a modal.

Sales and marketing pushed hard for full autonomy at launch. It was a significant feature with real value attached, and shipping it whole would have put the product ahead of the industry at that moment. The case for holding back was that an AI system will eventually get something wrong, and getting it wrong publicly during peak would cost lasting confidence in the product’s judgement.

Process

Analysed three months of customer contact data from calls, emails, live chat and contact forms, categorised by query type and read for sentiment on allocation. Manual allocation appeared across categories that were not nominally about it: bottlenecks at dispatch, missed cut-offs, misroutes to the wrong service, overweight surcharges from parcels put on the wrong carrier and new staff taking weeks to learn which carrier suited which postcode. That set the size and shape of the problem before any concept work.

Ran structured interviews with enterprise customers and the warehouse and depot staff working the queues, using account managers and support staff as proxies between sessions for their close read on both sides. Concepts were tested with the account managers and support staff before going back to the enterprises.

Mapped the existing Delivery Manager experience, the queues, tables, criticality settings and rules configuration, to establish what the concept had to work with. Explored a broad set of early concepts against that map, then narrowed on engineering feasibility and confidence in the data each would need.

Took the two remaining concepts to a fidelity where they could be judged against each other, wrote out the positives and negatives of each, and reviewed them as a feature decision before scoping the preferred direction for build.

Outcome

Designed the experience from recommendation through to auto-selection, with the correction loop built into the confirmation step, and scoped the modal direction for build.

Designed and delivered to the backlog, ready for build.

Artefacts

A close view of the Smart Allocate dialog listing proposed carriers and services with confidence bars for 11 consignments.
The Delivery Manager consignments screen, with a Smart Allocate button beside Export, Import and Advanced above a table of unallocated and allocated consignments.
A before and after flow: five steps to allocate a consignment, including a warning, against three steps using the Smart Allocate dialog.
A spreadsheet of customer contact data from calls, emails, live chat and contact forms, each row categorised by query type with an excerpt about manual allocation.
The consignments table with suggestions built in: a proposed carrier and service on each row, and a Smart Allocate column with a confidence ring and tick box.
Five layout options for the Smart Allocate dialog, including stacked cards, a table split into rows needing review and rows ready to allocate, cards grouped by carrier and a list sorted by confidence.

© 2026 Suneer Sood · Senior Product Designer

© 2026 Suneer Sood · Senior Product Designer