← Operator library Fiber Operations

Connect ISP CRM, Billing and OLT Data Without Losing Boundaries

Define safe workflows between customer records, billing state and fiber access equipment while preserving a trustworthy source for each fact.

What this note covers

Define safe workflows between customer records, billing state and fiber access equipment while preserving a trustworthy source for each fact.

Integration should connect evidence, not merge everything

Customer, financial and optical systems answer different questions. CRM identifies the relationship, billing owns charges and entitlement, while the OLT reports access-port and ONU state. A useful integration links these records with stable identifiers without pretending that one database should overwrite all others.

Customer

Own contact, location, service and organizational relationship.

Billing

Own package, price, invoice, payment and entitlement state.

Fiber

Own OLT, PON, ONU identity, optical readings and observed status.

Workflow

Translate approved business events into controlled device actions.

Create a durable service chain

Model customer to service to ONU to PON to OLT. MAC address, serial number and vendor identifier need normalization and change history because field replacements are normal.

Do not infer ownership from the first matching username alone. Installation and replacement workflows should bind equipment deliberately and require confirmation from the access device.

Separate observation from intent

The platform may intend an ONU to be authorized and assigned to a service VLAN; the OLT can prove what is currently configured and whether the ONU is online. Store both states and surface drift.

Polling must respect vendor limits, command variations and partial responses. Use CLI or supported APIs for the required data and SNMP as an explicitly tested fallback, not a source mixed silently with another device.

Turn alarms into customer context safely

An optical alarm becomes more useful when operators can see affected services and open incidents. Billing staff do not need OLT credentials, and field staff do not need unrestricted financial access.

Bulk disable or reprovision actions require preview, tenant scoping, audit evidence and post-action read-back.

Operational caution: Never identify an OLT solely by an address that is also forwarded to a MikroTik; a shared endpoint can make RouterOS identity and traffic appear as OLT data.

Evidence before rollout

Signal Required proof
Service binding Every managed ONU maps to one authorized service or a visible exception.
Source labels Each field shows whether it came from CRM, billing, CLI, SNMP or operator input.
Vendor proof Commands are tested on the exact vendor and firmware family.
Drift detection Intended and observed VLAN, state and profile differences are visible.
Role control Financial, support and device actions have separate permissions.

Put the plan into operation

  1. Inventory. Normalize OLT and ONU identifiers and remove ambiguous endpoints.
  2. Map. Bind a pilot service chain from customer through PON.
  3. Observe. Collect status without applying configuration.
  4. Reconcile. Resolve mismatches and document ownership.
  5. Automate. Enable bounded actions with preview and read-back.
  6. Expand. Add vendors only after command and fallback tests pass.

The decision standard

Approve the integration when a support agent can trace one customer to the correct fiber evidence, device data never overwrites financial truth, every action is scoped and recorded, and vendor failure produces a visible unknown state rather than misleading data.

Research basis: ITU-T GPON management recommendations; TM Forum information framework concepts; Vendor OLT management documentation. Validate implementation details against the releases, contracts, and local regulations governing your network.

Continue with ISPbills

Put this guide into practice