Bert Van Wassenhove

The through-line

Across the recent posts, Bert Van Wassenhove keeps returning to one idea: confident-sounding numbers and black-box systems are dangerous unless someone can actually interrogate them. He wants ROI figures tied to real operational data rather than one-size-fits-all percentages , and he wants planners to be able to see why a scheduling engine made a decision rather than override it on instinct . The same suspicion of hidden complexity shows up in how he talks about tooling: he favors building on low-code platforms where "every table and permission is in plain sight" and handing only the genuinely hard optimization problem to a specialist solver . Earlier posts state the underlying belief in more general terms ("low-code and AI... are the way forward") , while the later posts get specific about why: the value only becomes real once you can see the mechanics behind it, whether that's a route's cost, a plan's constraint, or an app's data model .

On ROI honesty

Van Wassenhove is explicit that a single ROI percentage cannot describe route optimization value across different operations. He notes 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," and that "a dense home health route and a rural field service route are not the same business case" . He describes changing his own sales approach as a result: "Send us a few months of real schedules with locations and we calculate what optimization is worth in your numbers. If it's small, you find that out before you buy anything" . He is openly skeptical of vendors who skip this step, asking "When a vendor gives you a hard ROI figure before seeing your data, do you take it seriously?" .

On planner overrides and explainability

He identifies planner override, not licensing cost, as the real expense in a scheduling rollout: "The most expensive thing in a scheduling rollout is not the licence. It is the morning a planner decides the optimizer is wrong" . His diagnosis is that visibility into constraints isn't sufficient on its own; what changes behavior is showing cost. He writes that "showing the blocking constraint is not enough. What stops an override is showing what the alternative costs," and that "a planner who can see that their preferred fix adds 40 minutes across the round makes a different decision" .

On low-code and specialist engines

Van Wassenhove pushes back on teams trying to build everything, including optimization logic, inside a low-code tool. He describes the pattern that works: teams "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" . For him this is "the unlock" for businesses with needs too specific for off-the-shelf software: "Build it yourself, with full visibility, and borrow the intelligence you do not have in house" . This sits alongside his broader stated conviction that "low-code and AI (llm's or algorithm based AI) are the way forward for many organizations" .

On modeling real job relationships

He argues that most routing APIs oversimplify pickup-and-delivery work by treating it "as one shape," when real field work involves stops that are dependent on each other: a part "picked up at the depot, installed three hours later, the old one returned to a different depot at end of day" . His conclusion is structural: "the hard part isn't the route. It's the relationship between jobs," and that modeling that relationship as a constraint lets "the solver hold the chain together when the day changes," whereas folding it into a single virtual stop "breaks the moment one half needs to move" .

From the stage

In the Connexi promo clip, Van Wassenhove speaks about entrepreneurship in a way the written posts never touch: the value of peer openness among founders. He describes the atmosphere of trips with other entrepreneurs as distinct and valuable in itself, saying "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" . He also makes the point that learning is strongest from entrepreneurs who built something in your own region, because they understand the local market problems you actually face , a claim about proximity and shared context that has no equivalent in his technical writing.

Takeaways

• Before trusting a route optimization ROI figure, insist the vendor calculate it from your own multi-month schedule data rather than quoting a general percentage .
• Treat a rising rate of planner overrides as a warning sign; the fix is showing the cost of the alternative plan, not just the constraint that produced it .
• When building scheduling or planning software, keep the low-code platform for data and permissions and route the hard combinatorial decision to a specialist solver via API instead of building an optimization engine in-house .
• Model dependent job relationships (linked pickup, installation, and return legs) explicitly as constraints rather than folding them into a single stop, so the plan holds together when the day changes .
• Seek out and learn from entrepreneurs who built businesses in your own region, since they understand the local market problems you actually face .