Analytics
12%
of sessions with a selected service ended with no result at all. In 83% of those sessions the user left the app within a single minute.
Techsbook · Direct Booking
A zero-result search became a recovered booking
In Techsbook a customer picks a technician for a telematics installation, pays and tracks the order. When no suitable technician was found, the path ended in a call or a chat with support.
I designed two connected solutions: one set of eligibility rules for the map and the list, and a handoff to a coordinator that keeps the service, address and time. The team shipped it.
31%
of zero-result sessions could be linked to a paid booking afterwards
before this, the product had no such continuation
68%
of the people who saw the reason continued
and sent a request to the coordinator
4.2 h
median time to the coordinator's first response
94% of requests were answered within the business day
Metrics cover the first 8 weeks after release, without a control group. The base for the 31% is sessions where matching found no suitable technician. The calculation and its limits are in section 07.
The original failure
The reason was visible. The booking broke anyway.
If no nearby technician held the required certification, the interface explained the constraint but sent the user to Messages or a support phone number. The service, address and time were not carried forward - help lived outside the booking flow.
System state
No certified technician
Next step
Start over through support
01Diagnosis
The problem was the dead end, not the rejection
The map showed a technician nearby, but the next step would not let the customer pick them. One service required a PRO360 certification. I checked analytics, support tickets and customer interviews to size the failure first.
Support
47
tickets a month saying there were no technicians available. This was the second most frequent support topic after payment questions.
Interviews
6
interviews with customers after a zero result. Not one of them understood how to continue the same order without entering its details again.
"There were three people nearby on the map. I assumed the app was broken, closed it and called the service directly."
"I would have waited a day or two if someone had told me it was being handled. As it is, there is just nothing."
Real screenOriginal results
Proposed designNo-match results
With the PM and the engineers we separated three independent constraints: certification, radius and availability. Being close on the map did not make a technician eligible. The fix needed two parts: explain the constraint and keep the path to booking.
02Model
One set of matching rules for the map and the list
A technician being present in the network does not mean they are eligible for a specific order. I broke matching into five states and made them the single source of signals for the map, the list and the recovery flow.
- 01
Certified and free
Can take this job right now.
- 02
Available later
Suitable, but at another time.
- 03
Busy
Qualified, but has no capacity.
- 04
Not certified
Cannot perform this service.
- 05
Out of radius
Sits outside the service area.
The map uses the same states as the list
Colour and icon show not just that a technician is present, but whether they fit this specific order. The legend holds that meaning without opening every pin.
03Decision
Keep the constraints and keep the order alive
The simplest fix is to relax the filters so the list is never empty. I compared five options against two criteria: does the interface stay honest, and can the customer continue the same order they already started.
| Option | Honest | Order alive | Verdict |
|---|---|---|---|
| Relax the filters | No | Yes | Shows a technician without the required certification as suitable. A non-empty list ≠ a successful match. |
| Extend the radius with consent | Yes | Partly | Works when a certified technician exists. Going outside the radius changes the travel fee and needs their consent - a coordinator's decision, not an automatic toggle. |
| A "we will notify you" waitlist | Yes | No | The order goes passive. From the interviews - in that time the customer calls the service directly. |
| A "call support" button | Yes | No | The order context is lost - the service, address and time have to be dictated again. |
| A request to the coordinator with the context saved | Yes | Yes | The reason is named, the order is not rebuilt, and the service gets an owner. The cost - it needs an operational part. |
What it cost
The chosen option is the only one a single product team cannot ship on its own. It requires a queue, an owner and an SLA on the operations side. That became the main risk of the project - see section 06.
04Booking flow
Hand the order to a coordinator without retyping
First the customer sees why the result was empty. Then they check the saved details, send the request and follow its status in the app. The coordinator helps with matching, but never waives the qualification rules.
The user sees exactly what is limiting the choice
Proposed designNo required certification
A trip beyond the radius
No free time available
Check the order details
Follow the request status
Return to the booking
The whole recovery flow in one pass
From placing the order and the eligibility check to the coordinator request, the technician assignment and the return to normal booking. This is the flow that went into user testing - see the next section.
05Validation
What the test changed in the booking flow
I ran a moderated test of the prototype with five customers who had hit an empty result before. Two findings changed the design, and one more changed the wording.
Finding 1
"Send request" read like filing a complaint
3 of 5 hesitated to tap it: they read it as a feedback form rather than a way to continue the order.
Changed: the screen title and the button - they now read "Continue the order with a coordinator".
Finding 2
The stated reason was missing spatial context
"No certified technicians" did not explain where they are. People kept asking: "What about the next district?"
Changed: kept a link to the full map, where the nearest technicians use the same state model as the list.
Finding 3
A specific deadline was read as a guarantee
Everyone read "Within 1 business day" as an exact promise, though response speed depends on coordinator load.
Changed: removed the exact deadline from the confirmation screen. First response time stayed an internal metric after release.
06Service
The request has an owner, a speed guardrail and a status
The chosen option needed an operational part. I built the blueprint, raised three open questions and agreed on an owner before release.
The user sees why matching did not work
Requests help, the product keeps the service and address
The order enters the CRM queue, a coordinator assigns a technician
The status comes back into the app
Open question
Who owns the request?
Decided: the shift coordinator, with requests visible in a shared CRM queue.
Open question
How is response speed controlled?
Decided: promise no exact deadline in the interface and track time to the coordinator's first response separately.
Open question
What does the user see while waiting?
Decided: request status in the orders section and a push when a technician is assigned.
07Results
Recovered bookings and how the service held
The release shipped in April 2026 on iOS, Android and Web. I counted continuation, not clicks: the matching stop rule was linked to the request created and to the payment that followed.
Metrics cover the first 8 weeks without a control group. They show an early direction, not a precise causal effect.
Key result
31%
of zero-result sessions could be linked to a paid booking afterwards. Before the release there was no recovery flow inside the product.
Early signal
68%
of the people who saw the reason get as far as sending a request. The main drop-off is on address confirmation.
Guardrail
4.2 h
median time to the coordinator's first response; 94% of requests were answered within the business day.
System health
71%
of zero results come from certification, not radius. That became the argument for widening the PRO360 training programme.
08Reflection
What I will change in the next project
I should have gone to operations in week one, not in week four.
Agreeing the queue and the SLA took two of the six weeks. Had I started with the blueprint instead of the screens, the release would have come sooner.
The drop-off on address confirmation is my own oversight.
In the test the address was always right. In reality a third of customers book an installation somewhere other than home, and the screen reads like an error. The next iteration is to offer the address from the last order.
The most valuable output is the reason data, not the flow.
The split across certification, radius and availability turned out to be more useful to the business than the recovery flow itself: it shows where the platform needs to widen its supply of technicians.