ISP Billing ISP Billing Documentation
Italiano Back to website
Services and provisioning

Integrated connectivity-service provisioning

Prepare catalog and address data, verify coverage, and create traceable provider drafts before commercial activation.

Last updated: 2026-08-19

When the provisioning panel appears

The embedded provisioning panel appears only when the customer service instance is still In progress, its catalog service is marked as a connectivity service, and at least one supported coverage type is selected. Supported families include FTTH, FTTC, FTTC/VDSL2, VDSL2, and EVDSL according to the configured provider flow.

If the panel is absent, check catalog classification, coverage types, service state, provider module, and operator permissions before assuming a fault. An already active or terminated service deliberately follows a different lifecycle.

Configure the service catalog

Open the catalog service settings and identify it as connectivity, then select only the technologies the offer can actually provision. Configure commercial price, recurrence, activation rules, required fields, and the intended technical module independently; the coverage label does not perform provisioning by itself.

Review changes against existing instances. Expanding a catalog service to another technology or provider may expose new actions on in-progress customers, so confirm product eligibility, provider contract, billing conditions, and operational ownership first.

Prepare customer, service, and address

Create or select the correct customer, installation address, catalog service, and in-progress service instance. The address must belong to that customer and contain normalized town, street, and a street number that can be separated from the street text, for example “Via Roma” and “10”.

Verify fiscal identity, contacts, installation contact, address codes required by the provider, selected offer, and operator ownership. Provisioning snapshots these values, so correcting them only after draft creation may not update an already prepared provider request.

Coverage verification

Run coverage from the customer service so the result remains connected with that installation address and commercial context. The checker can identify evidence such as FiberCop/TIM FTTH, Open Fiber FTTH, EVDSL, or FTTC/VDSL2, depending on active sources.

Read the provider evidence, technology, address match, and offer compatibility. Coverage detection is qualification information: it is not a resource reservation, accepted order, appointment, or guaranteed activation. Correct an ambiguous address before selecting a provider path.

Providers and operational availability

The panel shows only provider modules enabled and configured for the ISP, wholesale offers eligible for the service, and actions allowed by the signed-in role. A provider must also have valid credentials, endpoints, identifiers, directories, and any required background processing.

A visible provider name does not prove that write operations are ready. Test its connection in the dedicated module, confirm the contracted workflow and environment, and grant least-privilege provisioning permission to the responsible team.

Create the FiberCop draft

When the saved coverage evidence includes an eligible FiberCop result, the FiberCop module is active, the operator has write permission, and provisioning storage is available, select the action to create a draft.

ISP Billing stores a snapshot of customer, service, address, and verified technologies and creates the traceable draft before opening the next EASY IP NGA step. Check the generated identifiers and do not create another draft merely because the next form was closed. Complete mandatory address, contact, profile, SLA, and delivery values, review the XML or order summary, and submit only when authorized.

History and reconciliation

Provisioning history should identify the provider, local and remote order references, draft or submitted state, linked order, timestamps, latest notification, and operator action. Use it to determine whether work must resume locally, at the provider, or through an automated notification flow.

If a remote request may have succeeded while local saving failed, search the provider by the stable order reference before retrying. Reconcile incoming notifications with the correct customer service and preserve the original chronology rather than replacing inconvenient states.

Common operational errors

  • Panel missing: verify in-progress state, connectivity flag, technology, module activation, and permission.
  • Coverage unavailable: normalize the installation address and confirm active coverage sources.
  • Provider action missing: check contracted module configuration, offer eligibility, storage, and write role.
  • Duplicate draft risk: inspect provisioning history and provider records before repeating creation.
  • Order rejected: correct the exact address, identity, profile, SLA, or provider code reported by the workflow.
  • Service active too early: keep commercial activation and billing aligned with real delivery and commissioning.

Checklist

  • Mark connectivity and coverage types
  • Configure provider modules
  • Keep the instance In progress
  • Assign a complete address
  • Run coverage from the service
  • Separate detection from orderability
  • Review the saved snapshot
  • Complete the provider draft
  • Reconcile history and notifications
  • Activate billing only after delivery