A repair marketplace looks elegant on paper as a two-sided platform: a customer raises a ticket, a vendor accepts it, work happens. Every food-delivery, ride-hailing, and freelance-services platform has trained us to expect that shape. The problem is that food delivery, ride-hailing, and even freelance work all share an assumption that IT repair does not — they assume the request itself is well-formed. The food is real and the address is real; the rider is real and the pickup point is real. In IT repair, the request itself is the failure point. Add a third role between the customer and the vendor — a validator — and the median resolution time across a fleet actually goes down, not up. This post is about why.
Why most repair platforms are two-sided — and why that breaks
The two-sided model fails in IT repair for three reasons that are specific to the category.
First, the customer often doesn't know what's wrong. "The laptop won't turn on" can be a dead battery, a broken charging port, a corrupted Windows boot, or a motherboard failure. Each is a different vendor skill, different parts, different price. A vendor dispatched on "won't turn on" arrives blind.
Second, the customer often doesn't know what's needed. A keyboard that types wrong characters under Linux but is fine in Windows is a software problem. A printer that "isn't printing" is, half the time, out of toner. A senior IT admin can pre-diagnose these in 30 seconds. A first-time customer can't.
Third, the customer's address and access window are often wrong. "Available all day" turns into "in a meeting until 4". "Office at MG Road" turns into "actually our co-working space at the next building over". A vendor who has driven 12 km in Bengaluru traffic to a wrong address is now also a vendor who is going to give the platform a 1-star rating.
The two-sided model treats the customer as the source of truth. In repair, that assumption breaks daily.
What a validation call actually catches
A validation call is a 5–15 minute phone call from a platform operator (or a Super Admin role) to the customer, immediately after the ticket is raised, before any vendor is dispatched. It sounds slow. It is fast. Here is what an experienced validator catches on that call:
- In-warranty devices that should go to the OEM instead. Roughly 5–10% of incoming tickets in a typical Indian SME fleet are still in warranty; the customer simply forgot. Routing those to the OEM saves the customer money the platform has zero claim to.
- DIY-fixable issues. "Won't print" because the cartridge is empty. "Won't turn on" because the laptop is fully discharged and the charger is faulty. Walk the customer through a 3-minute fix on the call and close the ticket. The vendor is freed for real work.
- Wrong device descriptions. "It's an HP" turns into "it's a Dell". "It's a printer" turns into "it's a scanner". This matters because vendor skill flags vary by brand and device.
- Wrong addresses and access windows. Validate the pincode, get a landmark, confirm a contact name and number, agree on an arrival window.
- Onsite vs offsite preference. Some issues are obviously onsite (screen replacement, battery). Some are obviously offsite (motherboard, soldering, paint-shop printer). Decide on the call.
- Data handling. Walk through whether the device leaves the premises. Set expectations on encryption, backup, and chain-of-custody.
A validator catches all of this in one short conversation. The result: a ticket that reaches a vendor is a ticket that is real, well-specified, and ready to work.
The three roles in detail
| Role | Owns | Knows | Decides |
|---|---|---|---|
| Customer | Raising tickets, providing access, paying the invoice | Symptoms, urgency, business context | Onsite-or-offsite preference, urgency |
| Super Admin (validator) | Triage, vendor selection, escalation | Vendor pool, skill flags, recent performance, parts availability | Which vendor takes the ticket, when |
| Vendor | Diagnosis, repair, parts handling, invoicing | Devices, parts, repair craft | What's broken, what it costs, what's possible |
Notice what the Super Admin role is not. It is not a customer support agent — those answer questions after problems happen. It is not a sales role — there's nothing to upsell during a validation call. It is a triage role, closer to an A&E triage nurse than a call-centre agent: the job is to make sure the right ticket reaches the right specialist as quickly as possible.
What changes for the customer
The customer experience is one extra phone call at the start. The first time, it can feel like friction — "why isn't a vendor just coming?". By the second or third ticket, the customer learns that the call is short, that it reduces wasted time later, and that they get to talk to a human who knows the platform. Customer NPS in marketplaces with a validation role is consistently higher than in two-sided ones, even though the validation step adds latency. The reason is simple: the worst part of any repair is the first hour of uncertainty. The call closes that hour with a confirmed plan.
What changes for the vendor
For the vendor, the validation step is a quiet revolution. Vendors in two-sided platforms reject 30–50% of tickets they're offered because the request is ambiguous, the address is unreachable, or the parts won't be in stock. Tickets that come through a validation step have a rejection rate closer to 5%. The vendor is making more money per hour on the platform because they're spending less time on tickets that go nowhere. Vendors notice this within their first month and self-select toward platforms that protect their time. The platform's vendor quality compounds.
How Fixr runs this loop
Fixr by Hives.cloud is built around the three-role model. The Customer submits a request through the platform — a few fields about the device, the fault, the preferred service mode, the location. The Super Admin reviews and validates the ticket via a quick call, confirming details and ruling out non-issues. A verified vendor is then assigned from the Fixr network, based on skill set and current availability. The vendor accepts and proceeds. Every state transition — submitted, validated, assigned, accepted, en-route, onsite, in-repair, closed — is logged with a timestamp.
The platform is free for both individuals and organisations to use. Vendors bill the customer directly for the actual repair work (with a GST invoice). Hives.cloud doesn't take a cut of the repair invoice — the value of the platform is the routing and the trust, not a transaction fee.
When a three-role model is overkill
The validation step is not free. It costs operator time, customer time, and some latency. In two situations, the simpler model is better:
- Single-vendor AMC contracts — when there's exactly one vendor and they've serviced your fleet for three years, you don't need triage. You need a portal.
- Internal IT teams — when the "vendor" is your own team and the "customer" is your own employee, the team is already its own validator.
For an MSME running mixed hardware across multiple offices, or for a hybrid team where employees are scattered across pincodes, the three-role model is what makes repair operations tractable. The validator is the friction that removes friction.
How to think about validation if you run repair in-house
Some of this lesson transfers to in-house IT teams. If you run a 50–500 person company with a 1–3 person IT team and you handle repairs through WhatsApp or email, you have a two-sided system: employee → IT admin → repair shop. Bolting a triage step onto your IT admin role (a 5-minute reply to every new ticket asking three structured questions) pays for itself in vendor time saved and wrong-ticket reduction. Even a simple form — device, symptom, urgency, location, access window — replaces the lossy WhatsApp summary that most repair shops get today.
FAQs
Doesn't the validation call slow things down? By 15 minutes on the front end. It saves 1–4 hours on the back end by avoiding wrong-vendor dispatch, wrong-part visits, and DIY-fixable cases reaching a paid technician. Median resolution time goes down.
What if my issue is urgent? A good validator triages on the call. A genuinely urgent ticket — a paint-shop PC down on a manufacturing line, a CEO's laptop dead before a board meeting — gets fast-tracked. The validator is also the escalation route.
Who pays for the validation step? On a free platform like Fixr, nobody pays for it directly — it's part of the platform's value. On take-rate platforms, it's bundled into the take. On enterprise tiers, sometimes it's a per-ticket fee.
Can validation be automated? Partly. Form-driven validation can catch the structured issues (device type, address, warranty status). The judgement calls — "is this DIY-fixable?", "should this go onsite or offsite?", "do we trust the address?" — still need a human, at least until LLMs get materially better at India-specific repair triage. The right answer in 2026 is hybrid: form upfront, human call when fields don't add up.
Does the validator decide which vendor I get? Yes, with a constraint set. The platform's routing rules narrow the pool by skill, geography, and recent performance; the validator picks within that pool. Pure-algorithmic assignment in India tends to over-route to a handful of high-rated vendors and burn them out. A human in the loop balances the pool over time.