Booking a site visit took a phone call. Thousands of phone calls.
Facile626 sends technicians out to do workplace safety inspections across Italy. Somebody had to call every client to agree a time, then fit those times into a driving route that made sense. We replaced the calling and the routing with a system that does both overnight.
- Sector
- Workplace safety inspections
- Built as
- CTO, Prisma Group
- Shipped
- June 2026 · on their own infrastructure
- Runs on
- Their VPS, their domains, their database
- Their site
- facile626.it
Two jobs, both done by hand, both fighting each other.
The first job was agreeing a time. Customer Care rang clients, offered a slot, got a no, offered another. Every inspection in the backlog was a conversation somebody had to have, and the backlog did not stop growing while they had it.
The second job was the driving. A technician's day is a route, and routes have rules: working hours, a lunch break, real traffic, and the fact that some parts of Italy are far enough away that going home is not sensible. Building a good route by hand is hard. Building one that also matches the times Customer Care just agreed by phone is harder.
And the two jobs undermined each other. The route you would plan is not the route you get once clients have picked their own times, so the day filled with gaps nobody could close.
Route first, then ask. Not the other way round.
The order was the whole problem. Agreeing times first and routing afterwards guarantees a bad route. Routing first and then asking people to confirm a time that already fits produces a good one, and most people say yes to a time that is offered rather than negotiated.
That inverted the system. Overnight it computes the best possible day for every technician, then in the morning it asks each client to confirm their slot over WhatsApp. A no is not a failure — it triggers an alternative, and after three of them a human at Customer Care picks it up.
The other finding was about cost. Route optimisation is the kind of thing that is easy to buy per request and expensive to buy at scale. So the routing engine for the whole of Italy runs on their own server and costs nothing per call. The only metered service is Google Maps, used in exactly two narrow places: geocoding an address the first time it is ever seen, and one traffic-aware route per technician per planned day.
Four phases, each one an independent workflow.
The phases run in order and can be launched by hand from the dashboard, but in normal operation nobody touches them.
- 01
Sync — about two minutes
Every morning it imports technicians, pending inspections, confirmed appointments and unavailability from the Facile626 CRM. This is the only moment the system reads the outside world.
- 02
Routing — about five seconds
The optimal route for each technician, honouring working hours, the lunch break, real drive times with traffic, and an overnight stay where the geography demands one. Five seconds, for every technician, for the day.
- 03
WhatsApp outreach
The consent template goes to every client in the plan. Replies are handled until 23:00. A no gets an alternative date; three consecutive nos escalate to Customer Care. Every yes calls back into the CRM and writes the appointment.
- 04
The three unattended jobs
A 24-hour timeout at 07:00, a retry for failed sends at 08:00, and hole filling at 09:00 that tops each technician's day up to five stops. Nobody schedules these; they schedule themselves.
- 05
A rollout you cannot fumble
Going from test to full production is three buttons, in order. Step one messages only a test number and filters everybody else out. Step two releases it to the first three real clients. Step three removes the limit. Safe mode is the default, and it has to be switched off deliberately.
- 06
The map as the check
The dashboard draws each technician's day as numbered stops on real Google routes, with total distance, driving hours, and a badge where an overnight is planned. It exists so a human can glance at a day and say whether it makes sense.
Handed over onto their own machines.
The whole thing runs on Facile626's own server. The part that works out the driving routes lives there too, which is why it costs nothing per calculation, and it cannot be reached from the internet at all. The two web addresses renew their own security certificates.
The database is their Supabase account, transferred to them. The encryption key for the stored credentials was carried through the migration intact, so nothing had to be reconnected by hand on the other side.
Both addresses live under facile626.it. The system stopped being ours the day it moved.
Handover documentation, 29 June 2026.
Customer Care still calls people. Just not to read out a calendar.