Keana: green city logistics, with ZEN as the entire engineering team

Keana is planning software for city logistics. It takes the transport orders arriving at a hub and builds trips out of them: which vehicle, which time window, which stops and in what order. The goal is not primarily a tighter schedule. The goal is fewer vans in city centres that were never built for them.

The product belongs to our client. The engineering team around it is us: support, maintenance and development, in full.

One van entering a historic city centre is not a problem. The problem is that dozens drive in where a handful would do, because every carrier plans its own orders and nobody sees the total.

Bundling at hub level is the answer: orders heading the same way go in together. That sounds simple until you start doing the arithmetic.

A trip is only usable if it satisfies everything at once. The time window of every stop, because a recipient who is closed does not count as delivered. The vehicle's payload. Its range, which with electric transport is a hard limit rather than a detail. And temperature classes, because chilled and dry freight do not simply share a compartment.

Any one of those constraints is manageable. Together they are exactly the kind of problem a planner working by hand stalls on, and where software earns its place — provided that software knows the realities of transport and not just the mathematics.

This is not a case where we delivered something and left. We do the entire technical side of Keana: incidents and support, maintenance and upgrades, and the new functionality on the roadmap. One team for all three.

That shape is deliberate. Separating support from development looks tidy on an org chart, but in practice it produces two parties pointing at each other the moment something breaks. With one team, who fixes it is not a question.

Our client keeps what matters: the product, the customers and the direction. What we take over is the entire layer underneath — that it runs, that it stays current, and that whatever needs adding tomorrow actually gets added.

There is no handover moment, no knowledge walking out of the building at the end of a project, and no second supplier who has to be brought up to speed first. The people building the new functionality are the people who can also reach it at three in the morning.

Sustainability gains in logistics are usually estimated. Here they follow from the planning itself: the system knows which orders were bundled, which trips were therefore not driven, and which vehicles were deployed. That is not an assumption made afterwards; it is what the plan says.

That is what makes this one of the more satisfying engagements for us: software whose payoff is not in a dashboard, but in a street that has less traffic running through it.