A call-quality self-check that tells users what's actually wrong
It reads the signals BOTIM already logs from each call — network type, VPN state, mid-call network switches, signal, the peer's side — finds what the user's bad calls have in common, explains it in plain language, and offers to remind them next time. Pick a real-world pattern below to see the diagnosis adapt.
Call Health — user-side call diagnosis & reminders
A self-service diagnostic inside BOTIM. From a user's own historical calls and the client signals logged alongside them, it detects what their problem calls have in common (VPN on, constant Wi-Fi↔mobile switching, weak network, a peer's bad connection…), explains it plainly, and proactively reminds the user before or during future calls. Turns "my calls are bad" into "here's why, and here's what to do."
The idea
Two halves of the same feature: look back to diagnose, then look forward to prevent.
① Retrospective diagnosis
- Scan the user's recent calls + the client conditions logged with each.
- Correlate quality against each condition — find the dominant factor, not a list of bad calls.
- Explain it in the user's language, with evidence from their own history.
② Proactive reminders
- Turn each finding into an opt-in nudge — "Warn me if a VPN is on before I call."
- Evaluate the live condition on-device at call time.
- Close the loop: the diagnosis becomes prevention.
What it can detect & the signal behind it
Each pattern is a client-logged condition correlated against per-call quality. Status = whether the signal exists in footprint today.
| Pattern the user hears | Signal used | Source | Instrumentation |
|---|---|---|---|
| "A VPN is usually on during your bad calls" | VPN active flag at call time | client footprint | verify / add |
| "You keep switching Wi-Fi ↔ mobile mid-call" | network-type change events within a call | kNetwork / call events | have |
| "Your Wi-Fi is often weak/congested" | network type + signal strength / SSID | client footprint | partial |
| "Some problems are on the other person's side" | peer-leg network + quality | server join (both legs) | partial |
| "Your app version has a known issue" | app / SDK version | client footprint | have |
| "Battery saver is throttling your calls" | low-power / background-restrict state | client footprint | verify / add |
How the analysis works
For each condition, compare the user's problem-rate with the condition against without it, over their recent calls. A large, well-supported gap = a likely cause; the biggest gap becomes the headline. Deliberately simple & explainable in V1 — no black-box model, so the "why" the user reads is literally the evidence. This is the [Analysis] companion made concrete.
Guardrails
- Minimum support (e.g. ≥ 3 calls with the condition) before a finding is shown — avoid noise.
- Correlation ≠ causation — copy says "usually happens with", not "caused by"; recommendations are safe suggestions.
- Rank by strength; show the top 1–2 only. Never dump every weak signal on the user.
End-to-end flow
Teams involved
Privacy & on-device
Sensitive signals — handle with care
VPN state, Wi-Fi SSID and signal strength are privacy-sensitive and platform-restricted (esp. iOS). Confirm what can be logged & surfaced; prefer on-device evaluation for the live reminder so raw state needn't leave the phone. Findings shown to the user are about their own calls only.
Phasing
Retrospective self-check
- Health summary from recent calls
- Top 1–2 findings from signals we already log (network switching, version)
- Plain-language explanation + tip
- "See the calls" evidence drill
Proactive nudges
- Opt-in reminders (VPN on, unstable network)
- On-device live checks
- Add VPN / battery-saver / signal instrumentation
- Peer-side findings
Personalized & proactive
- Surface it automatically after a bad call
- Richer pattern catalog + learned thresholds
- Localized copy, all languages
- Feed anonymized patterns to VoIP Quality
Open questions
To confirm
- Can we log VPN state per platform? (biggest V1 dependency)
- Is per-call network-type / handover already in footprint, or sampled?
- Peer-leg join — reliable for the "other side" finding?
- Where to trigger it — a menu item, or auto after a bad call?
Decided
- End-user facing, self-service (not CS-only).
- Explainable correlation in V1; no black-box model.
- Standalone module; reuse call-history telemetry.
- Reminders are opt-in, never nag.