Fiber installations fail for predictable reasons: a site survey skipped a distance check, a technician didn't record which port on the OLT a customer was patched into, or a signal reading was eyeballed instead of measured. Every one of these gaps turns into a support call weeks later when nobody can explain why a specific customer's connection is unstable. The fix isn't more supervision — it's making the survey itself a structured record instead of a verbal report.

What a survey record actually needs to capture

A useful installation survey is a data row, not a paragraph. At minimum it should carry:

  • GPS coordinates (latitude/longitude) of the customer premises, captured from the technician's device at the time of the visit — not typed in later from memory.
  • Fiber distance from the nearest splice point or POP, since this determines expected optical loss and whether the site is even within budget for the planned ONT.
  • Signal strength in dBm — both received (Rx) and, where the ONT supports it, transmitted (Tx) power, measured with an optical power meter rather than read off a status LED.
  • ONT/CPE serial number, tied to the customer record at install time so warranty and replacement history are traceable.
  • Site photos — the pole or wall mount, the patch panel port, and the ONT LED state — timestamped and geo-tagged automatically by the capture device.

None of this is exotic, but it only works if it's required by the form before a survey can be marked complete, not left as optional free text a technician skips under time pressure.

The survey-to-activation pipeline

Treat installation as a state machine rather than a single event:

  1. Survey requested — triggered by a sales order or customer self-signup, assigned to a technician with a target site.
  2. Survey submitted — the technician completes the structured form above; the system flags any reading outside acceptable thresholds (e.g. Rx power below −27 dBm) for review rather than letting it pass silently.
  3. Survey approved / rejected — a network engineer reviews flagged surveys; approved ones convert into an installation work order, rejected ones go back with a reason (re-route required, distance exceeds budget, etc.).
  4. Installation completed — the technician confirms physical install, capturing the final signal reading post-termination, which is what should actually drive PPPoE provisioning, not the original survey reading.
  5. Activation — PPPoE credentials are provisioned against RADIUS only once the installation record is closed, so there's no window where a customer is billed for a connection that was never physically completed.

Every transition between these states should be logged with who made it and when. That log is the audit trail — not a separate compliance exercise, just a byproduct of the workflow being structured in the first place.

Reading attenuation correctly

The most common fiber troubleshooting mistake is treating any non-zero loss as acceptable as long as the link comes up. A GPON link can authenticate and pass traffic with a marginal signal and still degrade under rain fade, temperature swings, or a slightly bent fiber, failing intermittently in ways that are hard to diagnose after the fact. As a rule of thumb:

  • Rx power between −8 dBm and −27 dBm is generally within spec for most ONT receivers, but readings closer to the bottom of that range deserve a second look at splice quality before being signed off.
  • A reading that's dramatically better or worse than other installs on the same splitter leg usually means a labeling or patching error, not an actual anomaly — cross-check the port assignment before troubleshooting the fiber itself.
  • Record the reading at install time even when it's fine. Without a baseline, a technician troubleshooting a complaint six months later has nothing to compare the current reading against.

Field tooling: make it work without signal

Installation sites are frequently in areas with poor or no mobile data coverage — which is often exactly why the customer needs fiber in the first place. A survey tool that requires a live connection to submit will lose data at the worst possible moment. The practical answer is a form that saves to local storage as the technician fills it in and syncs in the background the moment connectivity returns, with photos queued the same way. This is a natural fit for a installable, offline-capable web app rather than a native app that needs an app-store update cycle to fix a form field.

Why this pays off in reporting

Once survey and installation data is structured and stored consistently, it stops being just an operations record and becomes a planning input: which areas have the highest average attenuation (candidate for a new splice point), which technicians have the highest rework rate, and which sites are approaching distance limits for the next service tier. None of that is visible from a stack of paper survey forms, but it falls out automatically once the same data model drives the install workflow and the analytics dashboard.