Skip to content
Case study · Taal Healthtech

Route‑to‑market optimisation for medical representatives

With Taal Healthtech, we reshaped not just the routing algorithm but how field teams operate: who to visit, in what sequence, and how to spend the day for maximum impact.

Client
Taal Healthtech
Industry
Healthtech, AI
Timeline
3 months
OutcomeWhat the work delivered
30%
less travel time
20%
more visits per day
3 weeks
to a working proof of concept
In their words

We collaborated with WislaCode on a route-to-market optimisation project. Working with WislaCode was effective, transparent and predictable, which is especially critical for AI and ML projects. We provided them with six months of anonymised data, and within just three weeks, they delivered a proof of...

1636832228517.jpeg
Julia DvornikovaCo-Founder, Taal Healthtech
Read the full review
The challengeThe brief, and what was at stake

The client sought to increase field efficiency by optimising routes and visit prioritisation, embedding this into day‑to‑day operations via tight CRM integration and moving to KPI‑driven planning. The practical challenges were familiar: data quality issues (unstandardised addresses, missing or inaccurate GPS), historically grown territories with overlap and “gaps”, volatile traffic and time windows, and static plans that were hard to adapt mid‑day.

We delivered an end‑to‑end solution: a time‑dependent, graph‑based routing engine (with multi‑modal options), territory redesign via spatial clustering, and a daily VRP with time windows powered by CP‑SAT and a time‑expanded DAG scheduler. We implemented a rigorous data remediation pipeline (address standardisation, geocoding, deduplication), two‑way CRM integration, and two integration modes (server‑to‑server API for central planning, an embedded SDK for on‑device re‑routing and offline use). We ran an A/B pilot and scaled progressively with dashboards and monitoring to manage by metrics.

Result:

  • Approximately 30% less travel time and ~20% more visits per day
  • 15-20% reduction in transport costs
  • Between‑zone travel reduced by around 50% following the territory redesign
  • Improved on‑time performance via real‑time re‑routing and live CRM synchronisation.
AI that earns its keepHave field operations an algorithm could transform?

We turn six months of data into a working proof of concept in weeks, then into real operational gains.

How we built itWhat WislaCode designed and shipped
01From static routes to a dynamic, time‑dependent graph

We modelled the operating area as a weighted, time‑dependent graph with roads, public transport and walking links as edges. Shortest paths are computed with Dijkstra (for pre‑computed matrices) and A* (for fast, on‑the‑fly re‑routing), incorporating live traffic and incidents from mapping APIs. The engine supports multi‑modal choices (e.g., park‑and‑ride + train) where it truly reduces total journey time, not just distance.

From static routes to a dynamic, time‑dependent graph
02Territory design using spatial clustering (OPTICS)

To eliminate spaghetti‑like routes and cross‑territory zig‑zags, we clustered partner locations into contiguous, compact zones using a density‑based method suited to uneven spatial distributions. Business rules then refined clusters (key accounts, regulatory or regional constraints). In practice this halved between‑zone travel and created coherent daily catchments, lifting visit density and agent familiarity with each zone.

Territory design using spatial clustering (OPTICS)
03Data quality, geocoding and CRM integration

Prior to optimisation, we standardised addresses, repaired or re‑derived missing GPS via geocoding, and resolved inconsistencies between sources. A two‑way integration keeps CRM entities (accounts, visits, constraints) and the routing store in sync, with automated geocoding for new or changed addresses. This remediation was critical: even the best optimisation underperforms with noisy inputs.

Data quality, geocoding and CRM integration
04Daily VRP with time windows, backed by CP‑SAT and a DAG scheduler

Each planning cycle builds a feasible, near‑optimal sequence of visits per agent under time windows, service durations, working‑hour limits and priorities. Heuristics generate a good initial plan, CP‑SAT and a time‑expanded DAG refine sequencing and enforce constraints efficiently. The approach balances objectives: minimise dead kilometres, meet frequency rules and maximise coverage of high‑value segments.

Daily VRP with time windows, backed by CP‑SAT and a DAG scheduler
05Real‑time adaptability, API/SDK delivery and measurable impact

Plans adapt during the day: cancellations, urgent inserts or traffic disruptions trigger rapid re‑routing (A*) and, where useful, task swaps across nearby agents. The server API powers centralised overnight planning, the embedded SDK provides on‑device, offline‑tolerant adjustments with in‑app navigation. Territory dashboards expose visit adherence, plan deviations, causes of cancellation, mileage and bottlenecks for continuous improvement.

Real‑time adaptability, API/SDK delivery and measurable impact
Part of a broader capabilityOne engine, across field operations

This is one of our AI route and territory optimisation projects - the same operations-research and machine-learning engine we apply to field forces across healthcare, logistics and sales.

Have a similar challenge?Let's map the fastest safe path to live

Book a 30-minute integration review. Bring one stuck or upcoming integration - we'll diagnose it with you and scope the work, no obligation.