What any solution for checking a CSP’s Resolved tap must respect. This page sets limits; it does not prescribe the design.
When a CSP taps Resolved, Wiom’s system already checks whether the customer’s internet is up. Then it closes the ticket either way. One in three closures happens while the system check says the internet is down, and those customers come back 3.4 times as often.
Three things go wrong at once:
The worst subtype is recharge done but no internet: the customer has paid and still has no connection, and 49.1% of those close while the check says down.
What the solution must respect, whatever its design. Set by the PM and checked against the Customer OS lean register in the Customer OS PRD kit. “Recovery” is the Recovery OS v3.0, “SQ” is SQ Driver v2.0, and C2 and C4 are rules of the Customer OS constitution. Every time limit is a parameter, listed below the table.
Words used here. Resolved: the CSP marks the ticket resolved. Verification: the state a ticket is in after Resolved, until Closure. Verdict: Wiom’s check of the customer’s internet after Resolved, passed (up) or failed (down or no data). Reopened: during Verification, the ticket goes back to the CSP. Closure: the ticket is closed, for good.
| ID | Guardrail | Related OS rules |
|---|---|---|
| Scope | ||
| G1 | Version 1 covers only no-internet tickets: internet supply down (ISD) and recharge done but no internet (RDNI). | SQ V1 limit: a ping can’t see speed |
| Checking the fix | ||
| G2 | The CSP must mark the ticket Resolved before it can reach Closure. This step is mandatory. Resolved is a claim, never proof that the internet works. | REC-01; SQ-16; Recovery §10.1 |
| G3 | The verdict is passed if the internet is seen up within the check window after Resolved. In version 1, one ping is enough. For recharge done but no internet, the verdict is passed only if the customer’s plan is also active, because the router can be up while the plan blocks the internet. | SQ-16. Conflicts with SQ-09 (no state change on a single data point) and with CP-SQ-33: the 30-minute check window is below its 2–24 hours |
| G4 | Every decision follows fixed rules. No scoring models or predictions. | REC-08 |
| G5 | The customer’s answer counts only as a plain yes or no: a button, a key press, or an agent recording it. Tone and free text are not answers. The customer “doesn’t answer” only when no yes or no comes back on any channel Wiom used to reach them. | REC-10 |
| Closing a ticket | ||
| G6 | A ticket reaches Closure only when at least three of these four are true: the CSP marked it Resolved, the internet is up, the customer has been told, and the customer said yes or stayed silent while the internet stayed up. G8 and G9 are the two exceptions, pending the governors’ ruling: G8 closes on silence even if the internet dropped during the wait, and G9 closes on silence with the verdict failed. | Recovery §5.3; rec:closed |
| G7 | If the customer says yes during Verification, the ticket reaches Closure immediately, whatever the verdict. | Recovery §5.3; SQ-03 |
| G8 | If the verdict is passed and the customer doesn’t answer, the ticket reaches Closure 48 hours after Resolved. Silence on its own is neither a yes nor a no. | REC-11; CP-REC-12. Conflicts with Recovery §5.3: silence counts only while the internet stays up |
| G9 | If the verdict is failed (internet down or no data) and the customer doesn’t answer, the ticket reaches Closure 7 days after Resolved. | Conflicts with REC-01, the rec:closed gate, SQ-11, C2: Closure without proof the internet works |
| G10 | Every Closure records why it happened: the customer said yes; the customer didn’t answer for 48 hours with the verdict passed; or the customer didn’t answer for 7 days with the verdict failed. | Product decision |
| G11 | The resolution signal goes to Quality only at Closure. | Support Resolution OS (signal on CLOSED) |
| When the customer says it isn’t working | ||
| G12 | A ticket that has reached Closure is never Reopened. | Nothing leaves rec:closed |
| G13 | If the customer says it isn’t working during Verification, the ticket is Reopened immediately, whatever the verdict. It goes back to the same CSP, who is told it is the same issue, not a new one. Internet up is only a proxy for the fix, so the CSP diagnoses the issue again. When the CSP marks it Resolved again, a new Verification starts. Version 1 sets no limit on the number of rounds; we will learn whether one is needed. | REC-11; Recovery §10.2 |
| G14 | If the customer gets in touch about the same issue during Verification, it is neither a new ticket nor a no. The customer is told the CSP is still working on it. | C2; C4 |
| G15 | If the customer says it isn’t working after Closure, a new ticket opens. | REC-12 (a repeat within 30 days is a failed fix); C2 |
| Telling the customer | ||
| G16 | Wiom contacts the customer about the fix only once the CSP has marked the ticket Resolved and Wiom has a verdict. If the verdict is passed, the customer is told the issue is fixed and can say if it still isn’t working; their reply shows whether the underlying issue is really resolved. If the verdict is failed, the customer is asked whether the issue is resolved, because the router may simply be off while nobody is home, or Wiom’s data may be wrong. Wiom reaches the customer by app notification, SMS and an IVR call. | REC-09; REC-15; C4 |
| G17 | In version 1, a message counts as told once it is sent. Wiom does not check delivery. The Verification windows run from Resolved, not from when the customer is told. | Conflicts with REC-18 (delivery tracked separately from sending) and REC-23 (told means delivered) |
| Telling the CSP | ||
| G18 | Once the CSP marks the ticket Resolved, the CSP sees that Wiom is verifying the fix, and sees the verdict. If the ticket is Reopened, the CSP is told the customer said it isn’t working. When the ticket reaches Closure, the CSP sees why (G10). | CSP-side, outside the Customer OS |
| The CSP’s TAT | ||
| G19 | The CSP’s TAT counts only the time the CSP spends on the ticket, inside the CSP’s working hours. Time spent verifying, by Wiom or the customer, never counts. | CSP-side TAT, outside the Customer OS. Conflicts with the Support Resolution OS: its resolution clock runs from intake to Closure without pausing |
| G20 | When a ticket is Reopened, the CSP’s clock resumes where it stopped, and the final TAT adds up every round. Example: raised 11:00, Resolved 15:00 (4 hours), in Verification until 17:00 (not counted), Reopened 17:00, Resolved again 20:00 (3 hours). TAT: 7 hours. | CSP-side TAT, outside the Customer OS. Conflicts with the Support Resolution OS: on a repeat, its clock resumes from the original intake, Verification included |
| Verdict | Customer says yes | Customer says no | Customer doesn’t answer |
|---|---|---|---|
| Passed (internet up) | Closure, immediately | Reopened, immediately | Closure after 48 hours |
| Failed (internet down or no data) | Closure, immediately | Reopened, immediately | Closure after 7 days |
| Parameter | Value | Used in | OS reference |
|---|---|---|---|
| Check window | 30 minutes | G3 | SQ Driver restoration window CP-SQ-33 is 2–24 hours, so 30 minutes needs the governors |
| Verification window, verdict passed | 48 hours | G8 | CP-REC-12: 24 hours default, 12–48 hours allowed |
| Verification window, verdict failed | 7 days | G9 | No OS equivalent |
| CSP working hours | 11:00–21:00 IST, every day | G19 | Support Resolution OS working window, which already governs the 4-hour resolution TAT (P91) |
| Case | Where it stands |
|---|---|
| The internet comes up after the check window, while the customer is silent | Open. Today the ticket waits for the customer’s answer, up to 7 days. The CSP knows the ticket was marked Resolved while the internet was down. Whether a later recovery should change the outcome is still to be checked. |
| The customer’s plan expires during Verification | Open. A real case; how to resolve it is still to be worked out. |
| The same CSP can’t take a Reopened ticket back (inactive, suspended, left, territory lost) | Known and rare. No fallback in version 1. |
| In the passed lane, the internet drops after the verdict, and the customer stays silent | Accepted for version 1: the ticket reaches Closure at 48 hours (G8). |
The flow at its simplest, drawn from the table above. The guardrails set what must hold at every step. If the customer says it isn’t working after Closure, a new ticket opens.
flowchart TD
A["CSP marks the ticket Resolved"] --> B{"Verdict: is the customer's internet up?"}
B -- "Passed" --> P["Customer told it is fixed"]
B -- "Failed or no data" --> F["Customer asked if it is fixed"]
P --> PA{"Customer"}
F --> FA{"Customer"}
PA -- "Yes" --> C1(["Closure"])
PA -- "No" --> R(["Reopened: back to the same CSP, same issue"])
PA -- "No answer for 48 hours" --> C2(["Closure"])
FA -- "Yes" --> C3(["Closure"])
FA -- "No" --> R
FA -- "No answer for 7 days" --> C4(["Closure"])
R --> A
C1 --> Q["Quality gets the resolution signal"]
C2 --> Q
C3 --> Q
C4 --> Q
classDef closed stroke:#1d7648,stroke-width:2px
classDef back stroke:#b2291f,stroke-width:2px
class C1,C2,C3,C4 closed
class R back