Tell the partner what to do, before telling him what we know
The CSP app is an execution surface. He acts as a sub-agent of Wiom, so the app's job is to produce predictable outcomes — and every decision he takes should come back to us as a signal we can either verify or learn from.
He can accept or decline a booking at the start, and he should have the information he needs to make that call properly. In the absence of it he may decline, and a decline for want of information is a booking lost for no reason. Once he has accepted, we want him to complete the job rather than leave it mid-way; and where he genuinely cannot, we want to know why, because a stated reason is worth far more to us than an abandonment.
Acceptance is the point that divides the journey. Up to it, saying no costs him nothing and the only thing that matters is that he is deciding with full information. From that point his install SLA is engaged, so the app's job changes: it should help him finish, and where he wants out it should offer him a way to save the job before it is given up.
The exceptions belong to him too — if the customer cancels, that is not his failure and it should not count against him.
He is worried about his install SLA because it is tied to his earnings, and that worry can work against us. When a customer does not pick up the phone he sometimes cancels the connection, which costs him the very SLA he is protecting — and he may not know that. Wherever his instinct and his interest diverge like this, the app should make the honest action the safe one, and say so plainly.
For this phase we have chosen to manage the customer's expectation on date adherence rather than enforce a particular time on the CSP. A date change that does not hurt his SLA should encourage him to tell us the real install date, which lets us set the customer's expectation in time — instead of a customer waiting and being told about the delay after the fact.
The journey is also a repeat task. He will do it many times a week, so the accepting path should stay fast and free of ceremony; whatever friction the design needs belongs on the exit, which is rare and is where jobs are actually lost. Where we do need to check something he has told us, we should do it without making him feel he is under suspicion.
From Wiom's side the goal is simple: as many installs completed as possible, and none lost to lack of clarity or coordination. The design principle throughout is predictability for the CSP — he is the key persona for every call we make.
Decided
Rules the design is built on
These came out of the objective-setting discussion and drove every screen.
Install SLA
Declining before accepting — no SLA impact.
Customer cancels — no SLA impact.
Accepts, then declines himself — SLA impact, depending on the reason.
Does not act and the lead is taken back — SLA impact.
Acceptance
Acceptance happens on the booking screen — the ✓. The SLA clock starts there.
After the ✓ he sees the date and the customer, then assigns to a team or to himself.
P41 starts the moment he receives a booking and stops the moment he accepts.
Date changes
Free up to n times, n = 2.
SLA is measured against the CSP's latest proposed date, not the customer's original one.
Once the grace period is over, the lead is taken back.
A date changed by the CSP is final — it is not confirmed with the customer. The customer is told the install day has moved for technical reasons.
Calls
The CSP should call the customer at least once himself, and escalate to Wiom only if the customer is unreachable.
When Wiom reaches the customer, the CSP also gets a call — the moment he picks up, the two are connected.
Verification
Verify customer claims, but never make the CSP feel untrusted — frame it as "we will try to revive this and call the customer, you can wait."
If it still dies after Wiom has tried, it does not count against him. No penalties.
Reasons
Keep only the most relevant four, plus an escape option.
Every reason opens a recovery before the booking is given up.
Decline and reassignment
A connection is never removed — it is taken back. The ticket stays in My Tasks with an updated status.
A system re-triggered booking can be reversible if no other CSP takes it. out of scope
Money
Wiom intends to pay more when the location is farther than typical, and this must be visible before he decides — that is what makes him put in the extra effort. out of scope
System rules
P41 — acceptance timer, ends at accept, not at technician assigned.
P74 — grace timer post slot, runs as it does today.
Quality — after acceptance, a decline does not penalise if it is a customer coordination issue (to be verified); a timeout penalises if the commitment was never met. No penalty for timeout or decline on the FPN.
Affirmation copy must make expectation and consequence clear, since the rules have changed.
Behaviour
How it behaves, screen by screen
The rules above decide what the journey costs. These decide how it actually runs.
Bubble
When a booking reaches him, a bubble appears on screen with the FPN sound, a vibration and a ripple.
Pressing either volume button silences it — the sound, vibration and ripple stop; the bubble stays.
Tap the bubble to open the booking’s address screen.
Drag the bubble and a cross appears; drop it on the cross to dismiss the booking.
P41 starts the moment the bubble appears, not when he opens it.
Bubble · more than one booking
Only the oldest bubble is shown, with a badge counting the rest — three bookings waiting shows the oldest bubble with +2.
The volume button works the same — sound, vibration and ripple stop, the bubble stays.
Tapping a badged bubble does not open the address screen — it expands the stack. Each waiting booking comes out as its own bubble, so with +2 he now sees all three.
Expanding counts as acknowledgement. He has seen every booking, so the sound, vibration and ripple stop.
Once expanded, every bubble is independent — tap one to open its address screen, or drag it to its own cross to dismiss it, without touching the others.
Bubbles he has not acted on stay on screen, inside the app as well, until he opens or dismisses them.
FPN · address screen
The map at the top is a real map — it can be zoomed and panned.
The labels for the nearby connection and the new booking are placed dynamically and must never overlap, at any zoom level or pan position.
The address card carries the customer’s audio address — a play control with a waveform, and a पता नहीं समझे? link beneath it for when the recording still doesn’t help.
The screen has two versions — with the audio address, and one without. When the customer has not recorded one, that row is absent entirely, not shown empty or disabled.
Rejecting from here uses the pre-acceptance reason set.
Date screen
He can call the customer from this screen.
He can change the day, up to twice.
Day change
दिन बदलें is always visible — never hidden, never greyed out.
Two changes are allowed. The picker states how many are left.
Once both are used, tapping it opens a sheet saying the day can no longer be changed — the blocked sheet. There is no third change.
When the day is changed from the drilldown, the day the customer originally gave always carries a tag beneath it, so he can tell it apart from the other options.
Rejection reasons
Two sets, and why each one is short
The reasons a partner can give are split by whether he has already accepted the booking. The two lists differ because what he can truthfully know at each point differs — a reason he cannot answer only manufactures data.
Before accepting
यहाँ तार नहीं जा पाता
नेटबॉक्स नहीं है
कोई और वजह
The sheet opens collapsed, showing the first two with और वजहें beneath. Tapping that reveals the rest. Nothing is deducted for declining here, and the sheet says so.
पता समझ नहीं आया is deliberately not on this list. The address screen already carries an option for exactly that — he can connect with the customer and clarify the location. It is an action he can take, not a reason to lose the booking, so it stays where it can be resolved.
There are no date-related reasons here at all, because the installation date is not revealed to him before he accepts. He cannot decline over a day he has not seen.
After accepting
कस्टमर ने मना कर दिया
कस्टमर से बात नहीं हो पाई
नेटबॉक्स अभी उपलब्ध नहीं है
कोई और वजह
The first two are conditional. They appear only once he has tapped the Call button at least once — until then they are not in the list at all. Until he has tried to reach the customer he has no way of knowing either to be true, and offering them would only give him a convenient answer to pick.
Why “team not available” is not a rejection reason
It is left out on purpose. Not having a team on the scheduled day is not a reason the booking cannot happen — it is a reason the day has to move. A partner in that position should change the installation date, not cancel the connection.
So it appears instead as a date-change reason, where it leads somewhere the job survives. Rejection is reserved for bookings that genuinely cannot proceed; team availability is a scheduling problem and belongs in the date-change flow.
Date change reasons
Why he is moving the day
Asked once, on the way into the day picker. This is the cheapest path in the journey, so the list exists to tell us why install dates really move — not to talk him out of it.
18 जुलाई को टीम नहीं भेज पाऊँगा — the date is variable; it always carries the slot day he is moving, so he can see which day he is giving up.
नेटबॉक्स नहीं है
कस्टमर ने दूसरा दिन का बोला है
कस्टमर से बात नहीं हो पाई
This is where team availability lands, and it is the reason that list has no equivalent on the rejection sheets.
Nudges
Reminders between the screens
Two points in the journey pass without the partner opening the app, and both end in a booking dying quietly. These are the moments we reach out to him over UAF — and they now carry a consequence they did not carry before.
Accepted, no team yet
He has taken the booking but has not assigned anyone to it.
Two reminders go out — the first at x, the second at x + y after acceptance.
Each one names the next step: assign a team.
Team assigned, slot day breaching
A team is on it and the slot day is approaching or has passed.
Further reminders go out as the day is breached.
Each one names the next step: get the install done.
What these messages say
Every one of them tells him what to do next — not what has happened, and not that something is merely pending.
Each states plainly that not doing it will affect his SLA. This is new. Until now these moments passed silently and he had no way of knowing they cost him anything.
Same principle as the rest of the journey: wherever waiting is his instinct, the app has to say what waiting costs. A nudge that only reports status leaves him exactly where he was.
What this needs from build
Each trigger point needs its own event for UAF to fire on: accepted-without-team at x, again at x + y, and slot-day breach.
x and y are not set yet. They decide how often he hears from us, so they need values before this can be built.
The copy sits under the same rule as the rest of the affirmation copy — expectation and consequence stated clearly, because the rules have changed and he is working from the old ones.
Customer side
What the customer sees when the day moves
The partner’s date is final — it is not sent to the customer for approval. That makes these two moments the only place the customer’s expectation gets set, and the only place a booking lost to a moved date can still be saved.
The message, when the day changes
“Due to high demand, your installation will be done on XX date.”
When the CSP changes the day
The customer app tells them the install has moved — as an announcement, not a request. There is nothing for them to approve, because the partner’s date is already final.
The reason given is demand, not the partner. He stays out of it, so a moved date never reads as one person letting them down.
The message goes out as soon as he changes the day, so the customer hears about it before the original date passes rather than after — which is the whole point of making the change free for him.
When the customer tries to cancel
Before the cancellation goes through, the app asks whether they are cancelling because of the new date.
If they say yes, they are offered a conversation with the CSP instead of cancelling — the two can agree a date between them directly.
The customer can still cancel. The conversation is offered, never enforced, and the cancel path stays one tap away.
So it ends one of two ways: both sides align on the same date and the install survives, or the cancellation proceeds as normal.
This carries weight on our side too. A customer cancellation costs the partner nothing, so he has no reason to fight it — and by the time it happens he usually cannot. If a booking is going to be lost over a date the partner moved, this is the last place it can be caught.
End to end
Every path in one view
Drag to pan · scroll to zoom · boxes are screens, the text on each line is what he taps.
reason sheet — the forkjob saved or still hiswaiting on someone elsetaken back
Latest round
What changed in the design
P41 timerStarts as soon as the CSP receives a booking, stops once he accepts.
FPN screen"पता समझ नहीं आया" now sits below the address, and has been removed from the rejection reasons.
Bottom sheet headlinesAll headlines follow a question format.
Rejection reasonsThe two primary reasons show upfront. The rest, and the custom reason, sit under "और वजहें". Choosing the custom reason opens a text box in place, and what he writes is what gets submitted and shown back to him.
Installation date screen"इस दिन ही लगाना है" sits below the date, to reinforce the commitment.
Day change transitionAfter he changes the date, the screen reinforces that the install now has to happen on the new date.
"Customer denied installation" copyReframed positively — we check the reason and his quality stays intact — instead of warning him about what happens if the reason is false.