Anyone who has run office IT in India knows the WhatsApp loop. The vendor says "leaving now" at 11:15. At 11:45 you message him; he replies "5 min". At 12:10 he says "stuck in traffic, by 12:30". At 12:35 he is sitting in someone else's lobby because there is a Wing A and a Wing B and nobody told him. The repair itself takes 40 minutes when he finally starts. The morning, however, is gone, and so is the productive output of three people who were waiting on him. Real-time vendor tracking sounds like a vanity feature borrowed from food-delivery apps. In practice, it is the single biggest reduction in operational drag for any onsite IT process — not because the vendor is faster, but because the uncertainty is gone.
The 'he's coming' problem
The problem is not the vendor. The vendor is doing his job. The problem is that the IT admin has no signal between "ticket accepted" and "vendor at the door", and so the admin fills the silence with WhatsApp pings. Each ping costs the admin two minutes and the vendor two minutes and earns nobody any new information. Across a fleet of fifty tickets a month, that's an hour of admin time and an hour of vendor time spent on signalling. More importantly, the admin can't reliably tell the employee on the broken laptop when help will arrive. The employee then takes their own approach — calls the vendor directly, walks down to the lobby every 15 minutes, gives up and goes home — and the operation degrades further.
Tracking solves the signal problem. It does not make the vendor faster. It makes the wait predictable.
What real-time tracking actually shows
A useful tracking implementation shows two layers of information.
Layer 1: stage transitions. Every ticket moves through a defined set of stages. A typical IT-repair lifecycle has eight: submitted, validated, assigned, accepted, en-route, onsite, in-repair, closed. Each transition is timestamped. The customer and the IT admin can see at a glance which stage the ticket is in and when it got there.
Layer 2: live location during the en-route stage. When the vendor is on the way, a moving dot on a map with an estimated time of arrival. This is the food-delivery analogue. It's useful — and it's also the layer that gets overweighted in pitches.
The truth is that Layer 1 carries 80% of the operational value. Knowing that a vendor moved from "accepted" to "en-route" 12 minutes ago is enough information for an IT admin to plan the next hour. Knowing the vendor is currently at a specific traffic signal on Old Madras Road is marginal extra information. Layer 1 is the discipline; Layer 2 is the polish.
A short note on the tech
Real-time tracking is typically implemented with WebSockets (Socket.IO is the most common library in the Indian SaaS ecosystem). The vendor's mobile app emits an event when a stage transition happens, and another event every few seconds during en-route to update location. The platform's backend broadcasts those events to anyone subscribed to that ticket — the customer, the IT admin, the platform's own ops dashboard. Server-Sent Events and even long-polling work too, with various trade-offs. The interesting engineering is not the transport. It is the discipline of writing every state transition to the timeline, even when it would be easier not to. A platform that only emits "en-route" but not "diagnosis complete" has a tracking implementation that looks fine in demos and falls apart in audits.
Why this is different from food-delivery tracking
Food delivery has one observable in-flight stage: the rider is moving. The whole journey lasts 20–30 minutes. The map is the experience.
IT repair has multiple in-flight stages, some of which are stationary. The vendor arrives onsite, diagnoses for 25 minutes, waits 40 minutes for a part to be delivered, repairs for 50 minutes, then closes. A live location map showing the vendor sitting at your office for two hours is not useful. What's useful is the per-stage transition: a small notification when the vendor moves from "diagnosis" to "in-repair", another when "in-repair" closes. That's the food-delivery-tracking metaphor adapted for a much longer, much more variable workflow.
The other difference is that IT-repair stages have implications. A "waiting for parts" stage that lasts more than a working day should automatically alert the IT admin. A "diagnosis" stage that exceeds 90 minutes should escalate. These rules are encoded on top of the stage transitions; they're not possible without the per-stage discipline.
What the IT admin gets back
The operational gains of good tracking, ranked:
- No more chasing. The IT admin stops messaging "ETA?" because the answer is on a screen.
- Predictable scheduling. Employees can be told "vendor at 3pm" with confidence, and rescheduled if the timeline slips.
- Status broadcast. The same timeline can be shared (read-only) with the employee whose device is being repaired. They stop calling the IT admin every 30 minutes.
- Per-ticket audit. Three months later, when someone asks why a repair cost two days of downtime, the timeline answers without anyone needing to remember.
- SLA enforcement. With per-stage timestamps, you can hold the vendor and the platform to an SLA that has actual numbers, not vibes.
The compound effect is hours per month back into the IT admin's day. A 30-ticket-a-month office saves roughly 2–4 hours of admin signalling time once tracking is reliable. For a 1-person IT team in a 100-person office, that's measurable.
How Fixr implements live tracking
Fixr by Hives.cloud uses Socket.IO for live vendor location updates and per-stage event broadcasting. Every state transition in the ticket lifecycle — from submitted through validated, assigned, accepted, en-route, onsite, in-repair, and closed — is emitted as an event and recorded on the ticket timeline. Customers (whether an individual or an organisation) see the same stream of events that the platform's Super Admin and the assigned vendor see. The platform doesn't charge for it; it's part of the free tier because there isn't a paid tier.
A practical note for IT admins: the timeline is permanent. Once a ticket closes, the stage timestamps stay in the audit log. You can refer back to a ticket six months later to settle a dispute or build a vendor-performance report.
Limits of tracking
Tracking does not, on its own, fix three problems.
It doesn't fix vendor quality. A bad vendor with perfect tracking is still a bad vendor. Tracking pairs with vendor verification and a performance-rating system to actually move quality. See our guide on what 'verified vendor' should mean.
It doesn't fix parts logistics. A vendor stuck waiting for a part can be precisely tracked while doing nothing. The platform also needs to track parts as a separate stage and surface that as a distinct stall.
It doesn't fix unrealistic SLAs. Tracking exposes how long things actually take. The first time you turn it on across a fleet, you may discover your "same-day repair" promise was always a 1.5-day repair in practice. That's information, not a feature; what you do with it is on you.
A short field guide
If you're piloting a marketplace, here's a quick test for whether the tracking is real:
- Open a real ticket. Watch which stages emit events. If only "en-route" and "closed" emit, the implementation is shallow.
- Time the latency between a real-world event and the timeline update. Anything over 60 seconds is suspect.
- Close the ticket. Pull up the ticket six weeks later. Are the per-stage timestamps still there? If they're gone, the platform doesn't have an audit story.
- Disconnect your network at the vendor's en-route stage. When you reconnect, does the timeline catch up correctly? Good implementations replay missed events; weak ones leave a gap.
FAQs
Does live tracking work without the vendor's app open? Mostly yes during foreground use; battery-saver modes and Android background restrictions reduce frequency. Per-stage events still fire when the vendor takes an action in the app (e.g. "mark arrived"). For SLA purposes, the stage transitions are what matter; the moving dot is a nice-to-have.
Is the vendor's location stored? Live location is broadcast during the en-route stage. Persistence policies vary by platform — Fixr stores per-stage timestamps in the ticket log but does not retain a continuous high-resolution location trail after the ticket closes.
Can the employee whose device is being repaired see the tracking? On Fixr, the ticket is between the requestor and the vendor; the requestor (often the IT admin) can share the ticket-status view with the affected employee, or simply forward the timeline updates.
What if the vendor turns off tracking? Stage transitions are still required to be entered by the vendor (and validated by the Super Admin). Persistent disabling of location during en-route flags on the platform's vendor performance score and can lead to offboarding from the verified pool.
Is this overkill for a single broken laptop? For a single one-off ticket, maybe. For an IT admin running thirty repairs a month across multiple offices, it's the difference between a job and an emergency.