The request sounds simple: Cut transport costs, keep customers happy and reduce emissions. It arrives with a spreadsheet of orders, a list of vehicles, several conflicting promised dates and an unwritten rule that the largest customers are never disappointed.
A mathematician could begin by writing equations. A better first step is to ask what the organization can actually decide.
For a delivery operation, the decisions might be which vehicle serves each order, in what sequence and at what time. Those are the decision variables. They turn the many possible plans into quantities a solver can change.
First, define a valid plan
A vehicle has capacity. Orders have quantities and destinations. Drivers have working-hour limits. Some customers can receive goods only during specific windows. An order must normally be allocated exactly once, and each selected route must fit together in time.
These are the constraints: the rules that distinguish a feasible plan from one the operation cannot execute. They come from different places, including physics, regulations, contracts and operational policy. The model needs to distinguish absolute requirements from preferences that can be traded against other goals.
Even the data are not always settled. An order may have one delivery date in sales and another in dispatch. A capacity field may describe theoretical vehicle capacity while loading staff use a more practical limit. Agreeing on the working interpretation is part of the model, not paperwork around it.
Then, give the search a direction
Suppose the initial objective is simply to minimize total route cost. A candidate plan has a score equal to the sum of its distance-related expense, driver cost and any fixed vehicle charges.
That is a useful beginning, but the original request also mentioned customer experience and emissions. One option is to put a monetary value on avoidable lateness, then minimize transport cost plus that modeled service cost. Another is to make on-time delivery a minimum requirement and seek the cheapest compliant plan. A third is to generate several solutions showing the trade-off between cost and estimated emissions.
The choice is not hidden technical fine print. It determines what the solver is being encouraged to do.
A simplified mathematical sketch could be:
Minimize total transport cost + late-delivery cost
subject to vehicle capacity, delivery-window and driver-hour requirements. Emissions can be reported for every candidate plan, included as another objective or constrained by an agreed cap. Each option expresses a different policy.
Test what the model believes
Before bringing in months of operational data, try a tiny example. Give the solver two trucks, five orders and one deliberately tight delivery window. Does it avoid an overweight route? Does it price a delay as intended? Does it choose a route with a slightly longer distance when that protects a critical commitment?
These are not merely software tests. They are checks that the mathematics expresses the business's meaning. Small counterexamples expose misunderstandings far more quickly than a vast model whose outputs are difficult to inspect.
Then expand to representative days: ordinary workloads, peak demand, road disruption and a day with insufficient capacity. Compare with the plans the team would otherwise have used. Measure not only the objective value but delivery performance, estimated emissions, stability and the time needed to obtain a useful answer.
The first model is a conversation with reality
An optimization model is not a photograph of the business. It is a deliberate representation of the choices, relationships and consequences needed for a particular decision. Some details must be exact. Others can be modeled approximately. Some may not affect the decision at all.
The model improves when planners, engineers and business owners inspect its answers together. If a plan looks mathematically attractive but operationally implausible, that is useful information about the assumptions. If two plans trade cost against service in a surprising way, the result can reveal a decision the team had not considered.
The most successful translation from business to mathematics does not eliminate judgment. It makes judgment more informed, more consistent and easier to test.