How BSNL FTTH ops typically break

Every BSNL FTTH SSA we’ve looked at — ours included — fails in roughly the same five ways. Not because the people are bad at the job. Because the tools assume a steady state that doesn’t exist on a working network.

Here are the five, in the order you’ll meet them.

1. The new connection that takes three days

The technical install is twenty minutes. The customer waits three days because BSNL provisioning requires the right form (Form 39B), the right CLLI, the right exchange resolution, and a number plucked from BSNL’s pool. One typo on any of them and the customer’s welcome SMS doesn’t arrive.

The new-connection flow in FNW Flow has nine steps because the actual BSNL submission has nine inputs. Skipping a step on paper means the submission is rejected silently the next day.

“

We used to do new connections in a spreadsheet, and the BSNL portal in another tab. Twice a week, the customer's number was different from what the technician submitted.

2. The fault that nobody knew about

BSNL’s MOA dashboard sends a docket. The franchise WhatsApp group sees the customer call. The technician on the route doesn’t see either until evening.

Three problems in one: the docket lives on a desktop portal, the call lives in chat, and the technician’s phone only has WhatsApp. By the time the right person sees the alert, the customer has called three times.

The fix isn’t a fancier dashboard. The fix is putting the docket on the same phone that has the customer’s history, the OLT signal, and the technician’s route — and routing it by deadline, not by order received.

3. The OLT vendor lottery

A normal SSA runs OLTs from two or three vendors — typically some mix of VSOL, CDATA, and OPTILINK. Each one speaks a different CLI. Each one has a different web console. Each one has a different default password and a different way to read the ONU table.

This is a training problem, but it’s also a fault problem: at 9 PM, on a Saturday, with a customer’s family yelling about Netflix, the on-call technician should not be reading a vendor manual.

The reasonable fix is a single pane. Not a config copy/paste tool — an actual pane that knows what each vendor calls each thing, and translates.

4. The geofence that doesn’t exist

Attendance for field technicians is the most under-engineered part of FTTH ops. Most SSAs use either paper rosters or a generic attendance app. Neither knows whether the technician is actually at the fault site.

Two things you need at once: the technician’s GPS confirms they’re inside the assigned shift zone, and live tracking only runs between check-in and check-out. The second one matters for trust as much as the first one matters for accountability — your technicians won’t use it if it tracks them while they’re asleep.

5. The month-end nobody planned for

Revenue share. Fault penalty. BSNL invoice reconciliation. SSA dashboard for the franchisee’s own accounts. Each of these is a one-week project on its own, and they all happen between the 28th and the 5th.

The fix here is boring — you put the calculations in the same app that has the source data (connections per franchise, faults per technician, OLT uptime per pane), and you compute them in the background instead of running them once at month-end.

---

What we built because of this

Every workflow in FNW Flow exists because one of these five things broke for a real SSA. The new-connection wizard exists because of #1. The MOA fault engine exists because of #2. The OLT pane exists because of #3. FNW Attend exists because of #4. The revenue-share + fault-penalty modules exist because of #5.

If you’re running an SSA and any of these are familiar, you already know where to look. The interesting question is which one to fix first. We usually say: start with #2. If your team can’t see faults in real time, every other improvement compounds slowly.