Three questions a spreadsheet can't answer.

A note before the detail: I'm describing the method and the shape of what came out, not publishing savings figures from someone else's P&L. If you want the numbers, ask me on a call and I'll tell you what I can defend.

Why these three broke the spreadsheet

Each of these decisions has the same structure, and it's a structure spreadsheets handle badly. There are discrete yes/no choices — award this lane to that carrier, qualify this SKU at that co-man, move this quantity from that node. The choices interact, so you can't evaluate them one at a time. And the constraints bind against each other: carrier capacity against service commitment, line time against minimum run, freight cost against shelf life remaining on arrival.

What people do instead is a heuristic. Sort by rate, assign greedily, fix the violations by hand, stop when it looks reasonable. That produces a feasible answer, usually a decent one, and there is no way to know how far off the best answer it is. That last part is the actual problem — not that the heuristic is bad, but that nobody can tell you how bad, so the conversation about whether to change anything has no floor under it.

Model one: freight lane assignment

The question: across the origin-destination lanes the business ships, which carrier should be awarded which lane, at what volume, to minimize total landed freight cost — subject to the constraints that actually exist rather than the ones that make the math easy.

Those constraints are where the modeling work is. Carriers have capacity limits by lane and in aggregate. Some awards carry volume commitments that have to be met or the rate isn't real. Service requirements rule out otherwise cheap options on time-sensitive lanes. And you frequently want an explicit diversification constraint — no single carrier above some share of the network — because the mathematically optimal answer of "give everything to the cheapest carrier" is an operationally catastrophic answer the first time that carrier has a bad quarter.

Formulated as a MILP, that's assignment variables per carrier-lane, continuous volume variables, and a set of linear constraints encoding capacity, commitment, service and concentration. Gurobi solves it. What comes back is not just an award list — it's an award list with a proven optimality gap, which changes the meeting entirely. "This is the best available allocation, and here is the cost of the diversification constraint you asked me to impose" is a fundamentally different conversation from "here's what I came up with."

The part people underestimate

Ninety percent of the effort in a lane model is not the optimization. It's reconciling the rate data — accessorials, fuel surcharge treatment, minimums, whether a quoted rate is comparable to the one next to it. A solver applied to inconsistent rate data will confidently produce a precisely wrong answer. Getting the cost basis right is the engagement; the model is the last two days of it.

Model two: co-manufacturer sourcing allocation

The question: which co-man should run which SKU, in what volume, over the planning horizon — minimizing total delivered cost while respecting the constraints of a supply base you don't own.

This is the richest of the three, because a co-man network has constraints in several directions at once. Line capacity by facility and by period. Minimum run quantities that frequently dwarf a month of demand, which is what makes the problem genuinely integer rather than continuous — you either run it or you don't. Qualification: not every SKU can run at every site, and qualifying a new one is a cost and a lead time, not a free option. Then freight from each co-man to each market, which is what makes the cheapest per-unit converter regularly the wrong answer once you land the product where it sells.

That last interaction is the one that justifies the model. A sourcing decision made on conversion cost alone and a distribution decision made on freight alone will each be locally sensible and jointly poor. Solving them together is the whole point, and it's exactly the coupling a spreadsheet can't hold.

Model three: inventory deployment and transfers

The question, asked continuously rather than annually: given what's already in the network and what's coming, what should move where — and when is a transfer cheaper than a buy or a run?

This is a network flow problem with side constraints, and it's the operational sibling of the other two. The strategic models answer where things should come from; this one answers what to do about the position you're actually in this week. Constraints that matter: truck fill on the moving lane, remaining shelf life when the pallet lands, handling cost at both ends, and the service consequence at the node you're pulling from.

Those last two constraints are what separate a model operations will run from one they'll ignore. A deployment recommendation that moves product with three weeks of life left onto a two-week lane is wrong in a way the objective function won't notice unless you tell it to. Get that wrong twice and nobody opens the model again — which is the most common way an optimization project dies, and it has nothing to do with the math.

What optimization gives you that a heuristic doesn't

Three things, and cost savings is only the first:

1. A bound. You learn how much better the best answer is than the one you're running. Sometimes that gap is small, which is genuinely useful — it tells you to stop spending attention here and go work on something else. A heuristic can never tell you that.
2. Shadow prices. The dual values tell you what each binding constraint is costing you. "Your single-carrier concentration cap is worth X" or "the binding constraint is line time at this facility, not price" reframes the negotiation. This is the output executives find most useful and the one most modeling work never surfaces.
3. Scenario speed. Once the model exists, "what if this co-man's capacity drops twenty percent" or "what if fuel moves" is a re-solve, not a project. The value compounds after the first build, which is also the argument for owning the model rather than renting a study.

Where this goes wrong

I'd rather say this here than have you find out later:

Bad cost data beats a good solver every time. Optimization amplifies whatever you feed it. If your rate table isn't reconciled or your landed cost is missing accessorials, the model will find the arbitrage in your data errors and present it as a recommendation.

The unexecutable optimum. Models that ignore the soft constraints — a relationship with a converter, a customer commitment, an operational reality nobody wrote down — produce answers that are correct and dead on arrival. Every one of these models ended up with constraints in it that exist for reasons that aren't in the cost function.

The model nobody owns. A one-time optimization study is a slide deck with a half-life of about a quarter. The version that keeps paying is one that lives in the business, gets re-solved when inputs change, and has someone whose job includes running it. That's a handover problem, not a math problem.

Sometimes the answer is that you don't need one. If you have four lanes and two co-mans, the enumeration fits on a page and a solver is an affectation. I'll say so.

What transfers

The three models above are all variants of the same small family — assignment, facility location and network flow with side constraints — and that family covers most of the strategic network questions a mid-market business actually has. Which sites should exist and which customers each should serve. Which supplier gets which volume. What moves between nodes. Where a new facility should go, and whether it should exist at all.

The distribution version and the co-man version look nothing alike in the room and are nearly the same model on paper. That's why this work travels: what changes between clients is the cost structure and which constraints bind, not the formulation.

One practical note. The model is the asset, not the solver. These were built against Gurobi, which is excellent and licensed; the same formulations can be pointed at an open-source solver where the problem size allows and a licence isn't something you want to buy. That's a decision worth making deliberately at the start of a build rather than inheriting from whatever the consultant happened to own.