Trunkrs Shipping Portal

The Shipping Portal is what a webshop sees of Trunkrs. It began as shipment management, a searchable table and a detail view, and grew into the place merchants do the whole job themselves: edit a delivery, file a claim, follow a support case, choose which delivery options they pay for, and tell Trunkrs how much volume to expect.

The problem

Every question a merchant had about a parcel used to be a conversation with operations. Where is it, can the address still change, what happened at the door, who signed for it. Operations could answer all of it, which is precisely why the asking never stopped.

Forecasting had its own version of the same problem. Merchants sent their volume expectations as CSV uploads, so the numbers arrived late, in whatever shape that merchant's spreadsheet happened to be in, and only when somebody remembered.

Both halves reduce to one thing. The person holding the question could not answer it, and the person who could was expensive to ask.

Constraints

A parcel's history is load-bearing, legally and commercially. Proof of delivery is not a status label. It is evidence: which document was checked, its last two digits, a GPS location link, photos at the door, and the recipient's own leave-behind instruction with photo proof attached.

Changing a delivery costs money and time, so it cannot be unconstrained. A parcel already loaded on a van can only move so far before it becomes tomorrow's parcel.

Forecasts are only useful before the trucks are booked. A number that lands after planning is not a forecast, it is a report.

Decisions worth naming

State the rule in the interface, not in the reply. The change-address panel carries its own rules: country cannot change, a new address within 200 metres still arrives the same day, anything further moves to the next delivery day. The merchant sees which outcome they are choosing before they commit, and the panel confirms "Delivery date unchanged" when that is the case. Nobody has to ask what will happen, because the screen already said.

Price the options in the same list as the free ones. Plan management puts standard features and paid add-ons on one page with the per-shipment cost written on each. Leave-behind permission is tagged "Most sustainable". Disallowing neighbour delivery states plainly that it causes repeat attempts and costs more. High-value security carries a threshold the merchant sets, defaulting to €200. The trade-off is legible instead of being a sales conversation.

Proof of delivery is arranged for the argument it will be used in. The detail drawer leads with the parcel's handling flags, then the photos, then the document check, then a timeline that includes the driver's own notes and the recipient's leave-behind permission. When a merchant is answering an angry customer, the sequence they need is the sequence they get.

Forecasting, the part worth pulling out

The default is Trunkrs' own number. The page says review it only if you want to change something, and it means it: submitting is optional, and silence is taken as agreement with the Trunkrs forecast. That inverts the CSV burden. A merchant's work drops from producing a number to disagreeing with one.

Near-term days lock, and say so. The rolling three-week window shows the nearest days as locked, each with the reason on the row. A forecast that cannot change is more useful than an editable field that will be quietly ignored.

Amending requires a reason from a taxonomy. Promotion, stock-out, new launch, weather, holiday, closed for a holiday, a structural shift in baseline, or something else with a note. Every reason goes to the merchant's success manager, and a change over 20% may prompt a call. Same principle as risk reasons on the operations side of the estate: a structured reason travels to the next person, free text does not.

That list is not arbitrary. Every entry on it is something the prediction cannot see from the outside, which is the whole argument for asking a merchant at all. Everywhere else the model already knows better, so the interface stops asking.

Grades show their arithmetic. A week does not get a score out of ten from nowhere. It reads "2 of 5 days landed within the allowed difference, 2 × 2 = 4", with the allowed band on each day, ±50 parcels on most and 20% on the bigger ones. A merchant who disagrees with a grade can see exactly which day cost them.

Those grades are not a scoreboard, either. A merchant whose forecast is wrong turns up in the operations planner as an overloaded van, which is the other half of this estate and the reason accuracy is worth showing at all.

What shipped, and how

Merchants now handle their shipping without leaning on operations, which was the point. On the forecasting side, the share of merchants persistently landing outside the allowed margins fell to under 3%. That was not the redesign alone: the team also changed how it talked about forecasting, and most of the improvement showed up among merchants somebody had also spoken to directly.

I design these as interactive prototypes in production code rather than static mockups, directing AI coding agents to build them, so engineers work from something clickable. The forecasting flow exists as a running prototype with a frozen clock, which is also how its rolling window and its day locks get tested at all.

Honest edges

Track and Trace, the recipient-facing tracking app, is a separate product and is deliberately not in this case study until it ships. Smart Search is included here as an annotated interaction spec rather than a built screen, because that is what it currently is.