CRM implementations
the portal
On a customer portal that thinks along with the service van, and why good CX is mostly invisible logistics
One service van. Three driving days a week. Hundreds of maintenance customers spread across five regions.
That was the starting point at a company installing air conditioning and heat pumps. They wanted to let customers pick their own maintenance slot. Nice for the customer, and it saves a lot of phone calls.
One catch: free choice and an efficient route work against each other. Let everyone pick whatever they want and the van zigzags all over the region. Lock the route down and the customer waits weeks for a date that suits the company. That’s the problem I built a solution for.
the dead database
First, the pattern I see across the whole industry, and the one I consider the most underrated problem in CRM.
The CRM is there, but it’s an archive. A customer fills in a form and that form becomes a row in a system. Only then does the real work start: someone at the office reads the row, picks up the phone, looks at a map, shuffles appointments around and hopes the puzzle fits. The software records. The human plans.
That feels normal because it works that way everywhere. But it means the company’s most expensive knowledge, namely where the van drives and when, lives only in the planner’s head. Every appointment is manual work. Every busy week is a map puzzle. And the customer notices none of it, except that they have to wait a long time for a date.
Software that only remembers helps no one. The moment a system can add value isn’t afterwards, in a report. It’s the moment the customer is choosing.
let the system think along
The reversal we built: don’t constrain the customer, let the system think along at the moment of scheduling.
The customer books their maintenance through their own portal. The moment they pick a date, the system looks over their shoulder. What jobs are already scheduled in their region? It puts the day the van will already be passing nearby at the top.
The customer just sees a list of available dates. They pick one that suits them. What they don’t see is that the order of that list is driven by the van’s route. Appointments cluster into efficient trips on their own as a result.
The result: the planner no longer works a map puzzle, and the customer keeps the feeling that they simply picked their own slot. Both true, at the same time.
And the portal does more than schedule. A fault report with a photo becomes a ticket on the right customer. A booking shows up on the maintenance board. Everything lands straight in the right place in the existing CRM. Nobody retypes anything. That last part sounds like a detail, but it’s exactly where most portals die: a pretty form at the front and, behind it, someone re-keying all of it anyway.
built lean
There’s another principle underneath this that I care about: the day-to-day flow shouldn’t cost money.
The obvious route was a routing API from a big provider. Works fine, but then you pay per call, day after day, for something that’s a distance question at heart. We went a different way: a free Dutch address service with smart distance logic layered on top. Zero API costs in the daily flow.
And we didn’t have to replace anything. The company keeps its CRM, its boards, its way of working. We laid a layer of intelligence and a customer portal on top. For a smaller business, that’s the difference between a project of weeks and a migration of a year.
Honest about the limits: this isn’t real route optimization. The system makes a suggestion based on distance to what’s already scheduled. The customer is free to ignore that suggestion and still pick a day when the van is on the other side of the region. It happens, and that’s fine. The goal was never a perfect route. The goal was that the average week clusters better on its own than when a human has to do it by hand.
logistics you don’t see
What this project mostly showed me again: good customer experience is usually not a frontend problem. It’s logistics that’s been made invisible.
This installer’s customer has no idea there’s distance logic under their date choices. They experience something much simpler: they could book an appointment quickly, at a time that suited them, without calling. That the date sitting at the top happened to also be the date the van was already driving nearby feels like coincidence. It’s designed coincidence.
That, to me, is the heart of the reversal. The industry builds systems that feed the planner with information, hoping the planner does something smart with it. I’d rather flip it around: the system makes the planning smart, not the planner. The human keeps the exceptions, the system does the shuffling.
And maybe that’s the fairest measure of a customer portal. Not how many features it has, but how much work disappears without anyone seeing it go.