Arrival planned per route, not per shift
Slots are assigned across a window so that one approach road is not asked to absorb an entire shift inside the same few minutes.
Employee transport software · Thiruvananthapuram, Kerala
Thiruvananthapuram concentrates most of its IT workforce into one very large park on the northern edge of a city that is long, thin and coastal. Routing is close to linear, which is simple until a stretch closes and there is no parallel road to move to.
Where it runs
Routing is planned around these rather than across a city-wide average.
What breaks a schedule in Thiruvananthapuram
These are the local problems a generic routing engine does not know it has.
One park, one approach
When most of the volume converges on a single campus from one direction, the approach road and the gate decide the on-time figure — not the quality of the route plan behind it.
A linear city has nowhere to divert
The city runs along the coast. When a stretch of the arterial is blocked there is frequently no parallel road to switch to, so the plan has to change rather than the driver improvising around it.
Monsoon disruption is annual, not exceptional
Waterlogging affects stretches that are known in advance. A routing model with no concept of a blocked segment carries on generating plans through roads nobody can use that week.
How taSki answers them
Slots are assigned across a window so that one approach road is not asked to absorb an entire shift inside the same few minutes.
A stretch that cannot be used is taken out of the plan rather than discovered by a driver halfway along it, and the resulting timings are the ones the SLA is measured against.
Where a park has more than one entrance, routes are planned to the gate nearest the drop rather than to a single default address for the whole site.
The platform
The same modules run in every city; the routing model is what adapts.
Shift rosters, ad-hoc requests and attendance in one place, so the transport plan is built from who is actually coming in.
Clustering by pickup density, then routing against real road networks — with ride-time ceilings and vehicle capacity as constraints rather than preferences.
Trips are allocated across your operator panel by coverage, rate card and compliance status, with double-assignment blocked at source.
GPS tracking against the planned route, escort compliance, and an in-app SOS that reaches the transport desk rather than a call centre.
Trips, rate cards and vendor invoices reconciled automatically, so disputes are evidenced rather than argued.
Every allocation, escort assignment and exception timestamped and exportable for statutory or internal compliance reporting.
Questions
Still unanswered? Our solutions team replies within one business day.
Talk to the team →No. taSki is software and owns no vehicles. Your existing transport operators run the trips on the platform. Where you would rather contract once, taSki can also be your transport vendor — in which case taSki holds the agreements with the empanelled operators and you contract only with taSki.
Yes, and most programmes do. Operators onboard onto the Partner Suite in days, usually without changing their commercials. There is no supply lock-in, and no requirement to retender before you can use the software.
One site first. A single Thiruvananthapuram location, one shift pattern and one roster is modelled against your current spend, so the business case uses your data rather than a benchmark. Most programmes run four weeks from first site to steady state.
Escort assignment, no-first-no-last-drop logic, driver vetting and in-app SOS are enforced when the route is generated rather than reviewed afterwards, and every decision carries a timestamped record for statutory and internal reporting.
See it on your Thiruvananthapuram roster
A 30-minute review using your own roster and rates, not a generic benchmark.
Hi there. How can we help?
Real people, Monday to Saturday