On this page
Guwahati, India
IST
Projects
/ Horizon
Case study · 2025 · Personal project · AI · Enterprise · Systems design
Predict before
the complaint arrives.
An AI-assisted operations console that tells telecom support teams what’s about to break, who it will hit and what to do next - before a single customer calls.
Role
Solo · end to end
Timeline
1 week · November 2025
Type
Personal project
I did
Research · Systems · AI/UX · UI · Prototype
In 30 seconds
Horizon, on one screen
01 · Problem
Support learns about outages from angry customers - hours after the network showed signs.
02 · Insight
The signals already exist. They reach the wrong role, too late, in a language nobody can act on.
03 · Solution
One shared incident that explains the cause, counts the customers at risk and suggests the next step.
01 · The problem
Towers fail in clusters, silently. Support finds out last.
6:40 pm. Tower 001, Sector 23.
Uptime 87% and falling. 2,847 people connected.
None of them have called yet.
Networks run as Region → Sector → Zone → Tower. When one tower degrades, a whole cluster of customers drops at once - and the signs are scattered across 7 channels nobody sees together.
The same outage, as support sees it today
Problem statement
Telecom support teams can’t see a network problem until customers complain - and even when early signals exist, no single role can turn them into coordinated action.
The opportunity: start the response at the first signal, not the first call - about 2 hours earlier in the Tower 001 scenario.
02 · Research
Every signal already exists. It just lands with the wrong person, too late.
RQ1
How do support teams find out about network issues today?
RQ2
What does each role need to act before complaints escalate?
RQ3
How should a prediction be explained so non-engineers trust it?
Who sees each signal, and where it gets lost. Engineers see alarms but not customers; agents see customers but not the network.
Desk research: six sources, one pattern.
Rising network complexity makes early detection hard
Networks now span 5G, fibre, VoLTE/VoWiFi and many devices, so support teams struggle to spot issues before customers complain.
Source · Ericsson
Proactive monitoring cuts downtime and support load
Predictive analytics plus automated anomaly detection can reduce MTTR by up to 43%.
Source · IEEE Xplore
Telecom problems come in clusters
Networks run as Region → Sector → Zone/Tower, and issues usually hit a whole cluster, not one user.
Source · ITU Telecom
Reactive maintenance raises cost and risk
Fixing after failure leads to high operating costs and frequent service disruptions.
Source · IAEME
Early detection + automation lower repair effort
Proactive fault detection and automated maintenance reduce unexpected downtime and repair overhead.
Source · Sutherland
Predictive maintenance improves reliability
AI/ML analytics keep equipment healthy, cutting downtime and making service more reliable.
Source · CelerData
The pattern
Outages hit whole clusters, and catching them early is cheaper - so Horizon works per tower and counts customers, not tickets.
4 insights that shaped the product
Insight 01
A prediction is useless without a next step.
Alerts are accurate, but agents still interpret them by hand.
→ Issue cards: cause + next action
Insight 02
Severity isn’t priority. Impact is.
No tool counts the customers about to be hit.
→ Rank by customers affected
Insight 03
Same incident, different eyes.
Agent ≠ engineer ≠ zone lead ≠ supervisor.
→ One incident, role-aware lenses
Insight 04
Support doesn’t end when the fix starts.
Calls continue until service truly stabilises.
→ Live recovery before closing
Competitor analysis: each tool covers half the job.
Tool
What they offer
Gaps
Design opportunity
Ericsson · Network analytics
Predictive monitoring · AI anomaly detection · strong 5G insights
Too technical and engineer-focused · no customer-impact view · no simple explanations
Plain language · agent-friendly UI · customer impact at a glance · one-click actions
Nokia Care · Device care
Real-time diagnostics · device-level insights · automated troubleshooting
Complex UI · limited prediction · device-focused only
Clear alerts · area-level predictions · simple workflows
Zendesk · Customer service
Ticketing · automation · chat workflows
No network insights · no prediction · issues reported by hand
Network + customer data together · auto-detected issues · predictive alerts
Salesforce Service Cloud
Customer 360 data · case management · automation and AI suggestions
Not telecom-native · no outage prediction · heavy customisation
Telecom-ready · early warning system · simple, lightweight UI
Horizon’s differentiator
Predicts issues early and explains them in plain language, so support teams act before customers complain.
Explainable AI - “why this is happening”
Ranked by customers affected
Agent workflows + supervisor triage
One-click customer SMS
Every team in one tool
03 · Who it’s for
Four roles, one incident - and no shared picture.
RS
Riya
Support agent
Is this caller part of a bigger outage?
Needs
Status + a script for the caller’s area
IK
Irfan
Zone lead · main user
Which tower, how bad, who’s free?
Needs
Warnings ranked by customer impact
AS
Ahmed
Field engineer
What’s wrong - and where exactly?
Needs
A brief with evidence and site details
AP
Anita
Supervisor
Is anything about to blow up?
Needs
Cross-zone view + proof predictions work
Proto-personas from desk research and role mapping.
Three roles in detail - what each one needs from Horizon.
Riya · Support agent · 27
Irfan · Zone lead · 34 · main user
Anita · Supervisor · 42
Who
Frontline agent who needs quick, clear answers to cut repeat calls.
Field coordinator who needs early tower warnings to prevent outages.
Operations leader who needs to see escalations coming.
Responsibilities
Handle daily complaints · troubleshoot network and billing · file tickets · update customers · escalate
Monitor tower health · dispatch field engineers · coordinate repairs · track repeat failures
Oversee sectors and teams · maintain SLAs · review performance · lead during outages
Pain points
Too many tools · no real-time sector status · repeat calls for the same outage · no early alerts
Scattered data sources · no impact count per zone · no early tower warnings · slow manual prioritising
No real-time analytics · hard to tell regional from local issues · late escalations · no prediction history
Needs
One sector console · simple AI root cause · quick customer notifications · fast actions (SMS, ticket, affected list)
Zone-level dashboard · predictive tower alerts · built-in engineer assignment · high-impact zone list
AI prediction dashboard · complaint surge alerts · clear action suggestions · team and issue breakdowns
Goals
Faster resolutions · fewer calls · clear customer communication
Less downtime · a more stable zone · fix issues before escalation
Prevent major escalations · reliable service · fast, informed decisions
Journey map · Irfan, zone lead · one outage
Same outage, two experiences: today vs with Horizon. Emotions mapped from role research (hypothesised). The gap between the curves is what Horizon is designed to close.
Stage
01 Detect
02 Assess
03 Investigate
04 Coordinate
05 Recover
06 Learn
Today · what happens
Nothing yet - the issue is hidden; teams wait for complaints
Agents take a flood of calls; Irfan checks scattered dashboards
Agents switch tools; Irfan checks tower KPIs by hand
Agents raise tickets; Irfan phones engineers
Engineers troubleshoot; agents keep customers informed
Tickets closed; patterns missed
Today · pain points
No early warning; blind to tower health
No sector view; no count of customers affected
Scattered data; slow diagnosis
Duplicate effort; no shared issue status
No live feedback; agents still get calls
No root-cause learning; outages repeat
With Horizon
A predicted issue arrives before any call
Issue card shows cause + customers affected
Assign an engineer and brief agents in one place
One-click fix, bulk SMS, ticket raised instantly
Watch recovery and the drop in complaints
Close, give the AI feedback, review patterns
Feeling
Unprepared → Prepared
Stressed → Clear
Confused → Aligned
Frustrated → Empowered
Anxious → Relieved
Tired → Confident
Revised problem statement
Four support roles need one shared, explainable view of emerging network issues - ranked by customer impact - so they can coordinate a fix before customers are affected.
04 · Key decisions
What I chose to show - and what I left out.
Three principles guided every call: explainable, impact-first, coordinated. The AI only suggests - a person always approves.
Scoping · Decision 00
The problem space covered outages, usage anomalies and billing. I designed network outages end to end first because one outage triggers the most simultaneous calls. Usage anomalies show up at customer level (moment 05); billing is phase 2.
Decision 01
From alerts to actionable issue cards
Instead of
A raw anomaly feed
I chose
Cause + confidence + customers at risk + one next action, on one card
Because
It answers “so what do I do?” without leaving the card.
Before · Raw alarm feed
→
After · One issue card
Cause · confidence · 2,847 customers · next action
5 alarms about one tower become one card that says what is happening, who is affected and what to do.
Decision 02
Customers affected is the headline number
Instead of
Rank by technical severity
I chose
A big customer count; severity becomes a badge
Because
It is the one number every role reads the same way.
Before · Sorted by severity
Two “criticals” look equal - which one first?
→
After · Ranked by customers hit
2,847 → 1,026 → 337: the order is the decision
Severity stays as a badge; the customer count becomes the headline that every role reads the same way.
Decision 03
One incident, role-aware lenses
Instead of
Four dashboards, or one identical view
I chose
One shared incident; each role sees a different density
Because
Shared truth keeps everyone aligned without drowning the agent.
Before · Agent · Riya, on a call
Is this caller affected? What do I say?
→
After · Zone lead · Irfan, fixing it
Why did it fire? How confident? Who is affected?
Both views read from INC-2041 - one source of truth. Only the density and the first question change.
Decision 04
“Resolved” is not the end
Instead of
Close the ticket when the fix is applied
I chose
Live recovery monitoring until calls actually drop
Because
Agents give callers a true answer, and the model learns from real outcomes.
Before · Closed when fixed
The ticket says fixed; customers say otherwise.
→
After · Open until calls drop
Health up, complaints down - then close
Close is only offered once recovery is confirmed - and what was predicted vs. what happened feeds back to the model.
How it came together
User flow · the scenario path is highlighted
Lo-fi wireframes · tested before any visuals
Interaction flow: one issue, handed across every role.
Horizon AI · suggests only
Detects a risk
Network anomaly, usage spike or billing issue
Horizon AI
Writes the card
Cause, customers affected, confidence, next step
Supervisor · Anita
Triages
Assign, notify agents, notify customers or approve a fix
Zone lead / engineer · Irfan · Ahmed
Fixes the tower
Reset, traffic shift or dispatch; updates status
Support agent · Riya
Answers callers
Sees if the caller is affected; ready script; SMS
Everyone · shared incident
One shared issue
Timeline, comments and live recovery in one place
Everyone
Closes + learns
Resolved, closed, and Horizon learns from the outcome - feeding the next prediction
A person approves every action - the AI only suggests.
05 · The product
One incident, from first signal to confirmed recovery.
Follow Irfan, a zone lead, through Tower 001 - starting 2h 14m before anyone calls.
01
Detect & understand
A prediction arrives as an issue card - cause, confidence and customers at risk, in plain language.
Cause written for non-engineers; evidence one click away
Confidence is always shown, never hidden
Solves Insight 01 · prediction → next step
02
Prioritise by impact
Issues are ranked by customers affected, and the map shows the blast radius.
2,847 customers is the headline - severity is a badge
Nearby towers and free engineers in one view
Solves Insight 02 · impact, not severity
03
Coordinate in one place
Assign an engineer, brief agents and message customers from the issue itself.
Every action auto-logs to one shared timeline
Agents get a ready script for callers in the zone
Solves Insight 03 · one incident, every role
04
Recover, then close
The incident stays open until complaints actually fall - then Horizon logs what it predicted vs. what happened.
Live recovery: throughput, calls, customers restored
Close & learn feeds accuracy back to the model
Solves Insight 04 · proof the fix worked
05
Zoom into one customer
The same prediction works at customer level: an agent sees if this caller is part of the outage - or has their own usage anomaly.
Zone-level outage and personal alerts in one view
A ready answer and script before the agent speaks
Solves zone + individual level
The same incident, through every other role
Riya, the agent, is covered in moment 05. Here is what the engineer, the customer and the supervisor see of INC-2041.
AS
Ahmed
Field engineer · screen 04
What’s wrong - and where exactly?
He gets a brief with the likely cause, evidence and site - not a vague “slow internet” ticket.
C
Customers in Sector 23
Affected customers · screens 05 → 11
Is anyone going to tell me?
The message the zone lead approves becomes an SMS before anyone calls - one source, no mixed messages.
AP
Anita
Supervisor · screen 10
What happened - and did the prediction work?
A shared summary: resolved before the first complaint, with what was predicted vs. what actually happened.
AP
Anita
Supervisor · screen 09
Is Horizon getting better over time?
Across incidents: prediction accuracy, lead time and false alarms - the proof the model can be trusted.
06 · Visual system
Calm by default - colour only when it means something.
Type
Urbanist
Headlines & the one number that matters
Inter
readable at console density
GEIST MONO
IDs, times, data
Status colour · always paired with an icon + label
Critical
Act now · customers at risk
Warning
Watch · trending worse
Stable / resolved
Confirmed, not assumed
AI / info
A suggestion, never an action
07 · Iteration
My first version looked finished. It answered the wrong question.
v1 showed everything the AI knew. Critiquing it against my own insights, I rebuilt it around what each role needs to do next.
Overview: from “everything” to “what next”
V1 · first version
V2 · redesign
In v1
In v2
Why
Issues listed per customer (Sarah, John…) with an AI risk %
Issues listed per tower, ranked by customers affected
Outages hit clusters - 47 callers are one issue, not 47
One global “AI accuracy 89.2%” tile
Cause + confidence on every issue card
Trust comes from explaining each alert, not a model score
Map, chat, status and team in separate panels
One incident with an auto-logged shared timeline
Coordination was where time was lost
Customer view: from 360° profile to the caller’s question
V1 · first version
V2 · redesign
In v1
In v2
Why
Full account, billing and contract details first
“Is this caller part of the outage?” answered at the top
It is the agent’s first question on every call
Generic actions: chat, call, run diagnostics
A ready script + outage ETA for the caller
Agents need a true answer, fast
Next: validate v2 →
5-person think-aloud with support staff · Task: triage 3 predicted issues · Measure: time to right action + trust rating
08 · Impact & reflection
Designing AI for operations is deciding when to act.
How I’d measure success · targets from the scenario, not test results
2h+
Lead time
Act before the first complaint.
Time between Horizon’s first warning and the first customer call.
−70%
Triage time
From signal to assigned engineer.
Root cause is found by hand across tools today (30+ min). Target: under 10 min once cause, impact and best-match engineer arrive on one card.
−40%
Repeat calls
Customers told before they call.
Calls about an outage that is already known. Proactive SMS and a ready agent script should cut them by ~40%.
What I learned
01 · Systems over screens
The problem lived in the handoffs between four roles, so I mapped them before drawing a single screen.
02 · Explainability is UX
An AI alert is only useful if a non-engineer can say why it fired and what to do next.
03 · Less, earlier
Every decision removed something. The best version shows one number, at the right moment.
“The strongest interface isn’t the one that shows the most - it’s the one that helps a team make the next decision.”
Mehnaz Basheer
Next project
Kibixy →