Nordkade Fulfilment sends about 120,000 parcels a month through four carriers, and the rules that decide which parcel goes with which carrier were written six years ago on a whiteboard. Carrier A takes most domestic parcels, Carrier B takes letterbox-sized items, Carrier C handles Germany and Belgium, Carrier D the rest. Since then the rules have been adjusted whenever a brand complained, a depot changed its cut-off time, or somebody noticed an invoice. Everyone agreed the split was about right.

“About right” is a strong claim for a problem shaped like this one. Every contract has volume tiers: rates fall when monthly volume crosses a threshold. One contract includes a minimum commitment with a penalty for falling short. Each brand has a delivery promise, and each carrier has a different measured on-time rate on each lane. Each depot has daily pickup limits. Move a few thousand parcels from one carrier to another and you may cross a tier on one contract, fall below a minimum on another, and break a promise on a third. Transport is not a rounding error in this business: Capgemini’s research puts the last mile alone at 41 percent of overall supply-chain costs.

The BI developer had been circling the problem for a quarter - the carrier-allocation model he had started once the Analytics Engine took reporting off his desk. He had got as far as a spreadsheet solver add-in, which could not cope with tier breakpoints. A volume tier is not a slope; it is a switch. Once you have sixty brands, four carriers, eighteen destination zones, several service levels and thirty days, you have a mixed-integer programme, and that is operations-research work. The usual routes were a transport-management suite’s optimization module, priced for shippers ten times Nordkade’s size, or a consultant and several months. So the whiteboard rules stayed.

Formulate first, then solve

By autumn Nordkade had the other two pieces in place: every lane’s measured on-time rate from the Analytics Engine, and a daily parcel forecast per brand from the Prediction Engine. The ops manager asked the question directly:

> Allocate next month’s forecast parcels across our four carriers to minimize total shipping cost, meeting each brand’s delivery promise, each carrier’s daily pickup capacity and depot cut-off times, and the volume commitments in our contracts.

The Optimization Engine did not reply with a split. It replied with a model, written in business terms, before anything was solved. Decide: how many parcels per brand, zone, service level and day go to each carrier; which volume tier each contract reaches; whether to buy an extra pickup at a depot. Must hold: every forecast parcel is assigned; no carrier exceeds its daily pickup capacity; a parcel may only go to a carrier whose measured on-time rate on that lane meets the brand’s promise; contract minimums are met or the penalty is paid. Minimise: tiered base rates, surcharges and penalties. The ops manager checked each line against a contract, a depot sheet or a brand agreement. That review took an hour. It is the step that makes the rest trustworthy.

The first run came back infeasible, and that was the design working as intended. The solver reported the smallest set of constraints that could not all be true together: Brand E’s next-day promise to southern Germany, the fact that only Carrier C met that promise on that lane, and Carrier C’s Friday pickup cap during Brand E’s campaign week. A language model asked for “the optimal split” would have produced a plausible-looking table anyway. The solver produced a contradiction, with names attached. The fix was a phone call: Carrier C agreed to a second Friday pickup for four weeks.

The second run was proven optimal in forty-one seconds. For the same forecast volume and the same promises, it cost 7.8 percent less than the whiteboard split - €520,000 against €564,000 for the month. Most of the saving did not come from cheaper rates. It came from a Carrier B volume tier the habit split had missed by about three percent three months in a row, and from no longer paying Carrier D’s shortfall penalty because the plan now routed just enough volume to meet the minimum.

Rule-of-thumb splitset six years ago €564k

Optimization Engine planproven optimal, same promises €520k

€0k€100k€200k€300k€400k€500k€600k

Base ratesSurchargesShortfall penalty

−7.8% for the same forecast volume. Most of it: a Carrier B volume tier the habit split had missed by 3%, and no penalty.

Composite scenario; figures illustrative. Carriers anonymised; tier breakpoints and penalties modelled as integer decisions.

The BI developer’s spreadsheet became the proof. He had solved one week by hand, with simplified tiers; the engine’s formulation, restricted to the same week and the same simplifications, matched his answer to the euro, then extended it to the full month and the real contracts. It was not a black box he had to trust. It was his own model, completed.

Decide

• Parcels per brand, zone, carrierper day · integer
• Volume tier each contract hitsbinary
• Extra pickups per depotinteger

Must hold

• Every forecast parcel assignedfrom the Prediction Engine
• Carrier pickup capacity per dayby depot and cut-off time
• Brand promise per lanecarriers whose on-time rate meets it
• Contract minimumsor pay the penalty

Minimise

• Tiered base ratesstep costs by tier
• Surchargesfuel, remote, oversize
• Shortfall penalties

• infeasibleConflict: Brand E next-day promise to southern Germany × Carrier C Friday pickup cap
• optimalAfter a Friday second pickup was agreed: gap 0.0%, solved in 41 seconds

Composite scenario. Every constraint maps to a contract clause, a depot limit or a brand promise.

The peak roster

The second question was labour, where warehousing research places 50 to 70 percent of costs. The Prediction Engine had given Nordkade hourly pick volume for peak with honest intervals. Turning that into a roster is a classic covering problem with rules attached, so the ops manager asked for it in one paragraph:

> Build the November–December shift plan. Minimise labour cost while covering forecast pick volume at the 85th percentile every hour. Use permanent staff first, agency blocks booked at least two weeks ahead, and the night shift only where needed. Respect a maximum of five consecutive shifts and eleven hours’ rest between shifts.

This model is much larger - every shift pattern for every worker type across sixty days - and the engine said so. It reached a plan within 0.4 percent of the proven bound in just over three minutes and reported that gap rather than claiming perfection. The night shift that had been planned for four weeks appeared on nine nights. Peak labour cost came in about twelve percent under last year’s plan, with forecast volume covered in every hour. The engine also reported which constraint was most expensive: Saturday coverage by permanent staff. Each additional permanent picker available on Saturdays would have saved more than the Saturday allowance Nordkade then offered, and enough people took it to matter.

What the three engines add up to

Nordkade now runs the whole chain on its own data. The Analytics Engine showed which clients cost money and which lanes perform. The Prediction Engine forecast how many parcels those clients will send. The Optimization Engine decides who carries them and who picks them. Each step comes with a receipt a manager can check: the query, the held-out error, and the solver’s status and gap.

Nordkade did not hire an operations-research team. The scarce skill - turning contracts, promises and capacity into a formal model - is the part the engine does, and the business owner reviews it line by line in her own terms. The whiteboard split was 7.8 percent wrong for six years. Nobody was careless. The problem was simply too large for a spreadsheet and too small, it had always seemed, to justify a consultant.