Rule-Based Allocation
Allocation runs against the rule set the authority publishes. Nearest vehicle, longest waiting, zone priority and fairness weighting are configuration, not code changes.
Dispatch
Every job allocated by a rule you wrote
Allocation is where transport policy either takes effect or quietly gets ignored. The Tanzim dispatch engine applies the authority's rules to every booking, and keeps a record of which rule produced each decision.
Policy that only exists on paper is not policy
A city can mandate accessible vehicle response times, airport queue fairness or zonal coverage. If allocation happens inside an operator's private system, none of it is observable and none of it is enforceable.
- Allocation logic sits inside operator systems the authority cannot inspect
- Accessible and priority bookings compete with ordinary demand
- Rank and queue order is disputed with no record to settle it
- Coverage obligations in outer zones go unmeasured
- Nobody can answer why a specific job went to a specific vehicle
What the engine does
One allocation path for every booking channel, whether the trip starts at a rank, on the street, over the phone, through a corporate account, or in an app the authority runs itself and connects over our API.
Priority Classes
Wheelchair accessible trips, school transport, patient transport and government bookings are allocated ahead of general demand, with their own response targets.
Rank and Queue Control
Geofenced rank queues hold their order digitally. A driver who leaves the rank loses position, and the sequence is recorded rather than argued.
Multi-Operator Arbitration
Where several licensed operators serve the same area, the engine allocates across them on the authority's terms rather than the largest operator's.
Tariff and Surge Governance
Fare tables, multipliers and caps are set by the authority. Operators work inside them. Any change is versioned and dated.
Manual Override
Controllers can intervene for incidents, VIP movements or system faults. Every override is attributed to a named user with a reason code.
Fallback Operation
If connectivity to a vehicle drops, dispatch holds the job, reallocates on a timer, and reconciles the record when the vehicle returns.
Decision Log
Each allocation stores the inputs, the rule applied and the alternatives considered. Disputes are resolved from the record, not from memory.
The reason is stored with the decision
Most dispatch systems record what happened. Tanzim records why. When a complaint reaches the authority six weeks later, the file already holds the vehicles that were available, the rule that ran, and the result it produced.
Decision logRule versioningNamed overridesFull exportOpen booking API
Allocation rules the authority controls
These are configuration settings, not development work. An authority changes them without a release and without asking the vendor.
| Rule | Set by | Typical use |
|---|---|---|
| Response time target | Authority | Separate targets by vehicle class and zone |
| Accessible vehicle priority | Authority | Wheelchair accessible bookings jump general demand |
| Zone coverage minimum | Authority | Hold vehicles in outer districts during peak |
| Rank queue discipline | Authority | Position held digitally, forfeited on departure |
| Fare table and caps | Authority | Tariff bands, waiting charges, maximum multiplier |
| Allocation method | Authority | Nearest, longest waiting, or weighted fairness |
| Driver shift limits | Authority | Maximum hours before the engine stops offering work |
| Operator job share | Authority | Distribution across licensed operators in shared areas |
Works with
The rest of the platform
See it run against your rules
We will configure a working dispatch instance using your licensing conditions and show you the decision record it produces.