Bert Van Wassenhove

The through-line

Almost everything Bert Van Wassenhove says about optimization circles back to the same point: the algorithm is rarely what decides whether a scheduling project works. What decides it is whether the people around the algorithm can see, question and trust what it produced, and whether the business case was ever real in their numbers rather than in a vendor's slide. He frames the failure modes concretely, in overrides per week and minutes added across a round, and the remedies are equally practical: show your working, model the operation as it actually is, and calculate value from real schedules before anyone signs anything.

The second strand is architectural and gets more explicit over time. He believes "low-code and AI (llm's or algorithm based AI) are the way forward for many organizations" [5], with a specific division of labour behind it: build the application yourself where you can see everything, and borrow the hard intelligence through an API instead of trying to build it in house [6].

On ROI that survives contact with the operation

He refuses to quote a single optimization percentage, and the reason is not coyness. "The honest answer depends on four things I don't know until I see the operation: jobs per person per day, distance between them, cost of an hour, length of a job" [1][2]. Those variables produce genuinely different businesses: "A dense home health route and a rural field service route are not the same business case. Quoting one percentage to both is how you end up in an unpleasant meeting nine months later" [1][2]. The inner economist he enjoys reviving [4] shows up here as a working method rather than a pose.

So the approach changed. Customers send a few months of real schedules with locations, and the value of optimization is calculated in their own numbers, with the downside made explicit up front: "If it's small, you find that out before you buy anything" [1][2]. He turns the point back on the industry as a test buyers can apply themselves, asking whether a hard ROI figure offered before a vendor has seen your data deserves to be taken seriously [1][2].

On planner override as the quiet killer

The most expensive line item in a scheduling rollout is not the licence [3]. It is "the morning a planner decides the optimizer is wrong. They cannot see why a job landed where it did, so they assume it is a mistake and move it" [3]. The arithmetic is brutal and quiet: "Fifty overrides a week and the efficiency gain you bought is gone inside a quarter. The plan was fine. Nobody could interrogate it" [3].

His refinement on this is the part worth stealing. Explainability that names the blocking constraint is not sufficient. "What stops an override is showing what the alternative costs. A planner who can see that their preferred fix adds 40 minutes across the round makes a different decision" [3]. Explainability, in other words, is not documentation, it is a cost comparison delivered at the moment of the decision, and he treats it as a direct way to save money on an optimization project [3].

On modelling the relationships between jobs

He is critical of how routing APIs abstract real work. "Most routing APIs treat pickup-and-delivery as one shape. Pick up here, drop off there, same vehicle" [8]. Field reality is messier: a part collected at the depot, installed three hours later, the old unit returned to a different depot at end of day. "Those stops are not independent. Move one, the others have to move with it" [8]. His conclusion is that "the hard part isn't the route. It's the relationship between jobs" [8].

That distinction has a design consequence. "Model that relationship as a constraint and the solver holds the chain together when the day changes. Fold it into a single virtual stop and it breaks the moment one half needs to move" [8]. He sees a recurring set of five relationship patterns across field service, last-mile, healthcare and waste [8], which is consistent with his refusal elsewhere to treat different operations as one template [1][2].

On low-code plus a specialist engine

The teams getting the most out of low-code are not the ones trying to do everything in it [6]. The pattern that works: "They build the app on a platform where every table and permission is in plain sight, and they hand the genuinely hard decision, planning 300 jobs across 40 people without breaking a rule, to a solver through an API" [6]. The payoff is that "they keep control of their data and skip building an optimization engine they were never going to staff for" [6].

He aims this squarely at businesses whose needs are too specific for off-the-shelf software: "Build it yourself, with full visibility, and borrow the intelligence you do not have in house" [6]. The contrast he draws is with vibe-coding a black box, and the reasoning is the same one that runs through his explainability argument, that visibility into how the system works is what makes it survivable [3][6].

On building things himself

The appetite for experiment is genuine and personal. Working daily in AI, routing and maps with Solvice, he took hobby vibe coding "up a notch" and built the RALLY TRIP METER he had been missing on old timer rally rides with his daughter Michèle Van Wassenhove [7]. The design brief mirrors his professional instincts: "practical and simple, yet fully featured" [7], with a pilot and co-pilot view, obvious distance tracking, average speed, stage tracking and notes including GPS coordinates for the obligatory quiz questions [7]. The stated goal is to win another bottle of champagne at the next rally, the app is free on iPhone, and he is openly fishing for rally invitations [7].

On learning from other entrepreneurs

He values entrepreneur travel for the atmosphere it creates: "Het feit dat we met ondernemers op stap zijn, allemaal mensen die iets aan het ondernemen zijn, willen ondernemen, wat toch een heel speciale sfeer geeft en een openheid die heel interessant is" [9]. The openness matters, but so does proximity. The greatest learning comes from founders who built something in your own region, Flanders, Belgium and the Netherlands, because they understand the local market problems you actually face [9].

Takeaways

• Refuse blanket ROI percentages for route optimization; the answer depends on jobs per person per day, distance between them, cost of an hour and length of a job, and a dense home health route is not a rural field service route [1][2].
• Calculate the business case from a few months of the customer's real schedules, and tell them before purchase if the value is small [1][2].
• Budget for planner overrides, not just licences: fifty overrides a week can erase the efficiency gain inside a quarter [3].
• Showing the blocking constraint does not stop an override; showing that the planner's preferred fix adds 40 minutes across the round does [3].
• Model job dependencies as constraints rather than folding them into a single virtual stop, which breaks as soon as one half of the pair needs to move [8].
• Use low-code for the app, where every table and permission is visible, and call a specialist solver by API for the hard planning decision instead of staffing an optimization engine you cannot maintain [6].
• Seek out founders who built businesses in your own region, because they understand the local market problems you are actually facing [9].