Diagnose the network you have. Design the one you need. Prove the difference.
Most transport software starts once the buses are already running. Network Planning starts earlier — with the demand, the zones and the gaps — and ends with a costed, quantified service plan a board can approve and an operator can run.
Understand → Diagnose → Design → Quantify → Export.
Each stage has an owner and completion criteria. A stage does not open until the one before it is genuinely finished, so a plan cannot be signed off on data that was never loaded.
The board shows what is blocking the next stage and who owns it — not a progress bar that moves when someone clicks "next".
Know the territory before you draw a line on it.
Territory Profile
Population, employment and land use per analysis zone, with the demographics gaps flagged rather than silently averaged.
Market Potential
Where trips could come from, by zone and purpose — the demand case that justifies the service, not just the demand you already carry.
Zone OD & work-purpose flows
Origin-destination movement between zones, separated by trip purpose, so commuter corridors are not hidden inside total flow.
Trip generator register
Employers, campuses, hospitals and interchanges as named generators with coordinates — and a check that flags any sitting outside the study boundary.
Destination register
The anchors the network has to serve, defined once and reused across every diagnosis and scenario.
Operating calendar
Service days, school days, holidays and special events — the basis for annualising anything you quantify.
Name the problem in numbers.
Zone Accessibility
What each zone can actually reach within a time budget, on an editable ruleset — walk speeds, transfer penalties and wait assumptions are yours to set and to defend.
Opportunity
Zones with demand and no reasonable service, ranked. The shortlist a planning team argues about, produced from data rather than memory.
Route Service Quality
Route-level directness, coverage and duplication — which routes earn their kilometres and which are carrying legacy.
Frequency Strip
Headway across the day and week, corridor by corridor, so a "30-minute service" that is really hourly after 6pm shows up.
Corridor analysis
Where demand concentrates enough to justify a corridor, and what that corridor would carry.
Barrier & catchment
Rivers, rail lines and motorways treated as the barriers they are, instead of straight-line catchments that assume people can walk through them.
A plan someone can be held to.
Scenario Designer
Draw and edit routes against the diagnosis, then approve and lock the scenario. Locked scenarios keep a change log, so "who changed the alignment" has an answer.
Scenario comparison
Baseline against proposal on the same metrics — coverage, accessibility, vehicle-kilometres and cost — rather than two separate reports.
Quantification
Vehicles, service hours and vehicle-kilometres for the plan, including dead running — the number that makes a budget realistic instead of optimistic.
Automated QA — 17 checks
Orphan stops, missing coordinates, impossible trip times, single-trip routes, unreconciled length and vehicle-kilometres, unzoned OD, generators outside the boundary. Handover is gated on zero errors.
Versioned, lockable ruleset
Every assumption — speeds, penalties, dead-running percentage, cost rates — is versioned. Exports carry the ruleset version that produced them.
Export Centre & handover pack
Service specification, route workbooks and GeoJSON, stamped with the ruleset version. Detailed vehicle and crew scheduling continues downstream — in RouteSync's own Schedule Design, or in HASTUS.
Bring us a network and a question.
The fastest way to judge this is on your own zones and routes. We will load them and walk the diagnosis with your planners.