A broadband service can show as activated while still being unusable or incorrectly configured. Treat provisioning as its own evidence problem rather than letting it be dismissed as a generic Wi-Fi fault.
Key points
- Separate activation date from the date the service actually worked.
- Record every technical diagnosis and later correction.
- Ask whether the fault is line, ONT, router, authentication, addressing or backend provisioning.
- Preserve engineer notes where they contradict first-line support.
- Check delayed-start or loss-of-service compensation separately from any other remedy.
First: what type of failure is this?
“Broadband not working” can mean several different things. A line may never activate; the ONT may be provisioned against the wrong profile; authentication may fail; the router may be configured incorrectly; an add-on may not have been applied; or the customer may be behind CGNAT when a feature requires inbound reachability. Diagnose the category before arguing about blame.
The account saying “active” is not the same as usable service
Providers often have separate order, network and billing systems. One can show complete while another is wrong. If billing began before the service actually functioned, record the promised start date, the system's activation status and the first date on which the service worked normally.
Do not accept a technical shorthand that does not explain the network
A provider may say that a static IP is required for port forwarding. That can be true as a product-policy requirement, but it is not a universal networking rule. A public dynamic IPv4 address can support port forwarding; CGNAT or provider/router restrictions may block unsolicited inbound traffic. Ask whether the connection has a public address, whether CGNAT is in use, what add-on was provisioned and what changed when the issue was fixed.
Engineer attendance can be decisive evidence
Where a field engineer de-provisions and re-provisions equipment, changes the ONT profile or identifies a provider-side configuration problem, ask for the visit outcome and job notes. A later backend fix can materially undermine an earlier assertion that the customer simply needed different equipment or an optional paid add-on.
Keep support access in the chronology
If the fault lasted longer because technical support was unreachable, include call attempts, queue times and missed callbacks. This does not automatically create a fixed compensation entitlement, but it can show avoidable delay and poor complaint handling.
Remedies can stack conceptually, but do not double-count
Depending on the facts, the consumer may need a service fix, refund of wrongly charged add-ons, automatic compensation, a billing adjustment, cancellation rights or additional complaint redress. Explain which failure each requested remedy addresses. Do not ask for the same loss twice under different labels.
What to ask for
A focused provisioning complaint
- Confirm the root cause and the systems/equipment affected.
- State when the service should have worked and when it actually worked.
- Explain any contradictory technical diagnoses.
- Refund charges caused by an incorrect diagnosis where appropriate.
- Apply any automatic compensation due.
- Confirm what was changed to prevent recurrence.
Evidence worth keeping
Delayed activation and a fault after activation are not always the same event
If the service never worked on the promised start date, preserve the order and activation record. If it worked and later failed, record the first point at which service was lost. The distinction can matter to diagnosis and to any automatic-compensation calculation.
A provider may describe an order as “complete” because an order-management system reached its final status. Ask a different question: when was the communications service actually usable? If the answer is later, ask what provisioning step remained incomplete.
Router, Wi-Fi and network provisioning are different layers
“It is your Wi-Fi” is not an adequate answer to a fault that persists over Ethernet or concerns authentication, IP addressing or network-side configuration. Conversely, a weak wireless signal does not by itself prove a network provisioning failure. Test methodically.
| Symptom | What to isolate | Useful evidence |
|---|---|---|
| No connection at all | ONT/modem state, authentication, line status, provisioning | ONT lights, router WAN state, provider fault reference |
| Works by cable but not Wi-Fi | Wireless coverage/configuration | Ethernet speed test compared with Wi-Fi tests |
| Internet works but inbound services fail | Public IP, CGNAT, firewall, port forwarding, provider policy | WAN address, public-IP check, router rules |
| Feature starts working after backend change | Provider-side provisioning/profile | Engineer notes and exact change made |
If support tells you to buy an add-on, record the diagnosis behind the sale
If a paid static IP, replacement router or higher package is sold as the solution, ask why it is technically required. If the eventual fix proves to be an unrelated provider-side configuration error, you have a clear basis to ask for the unnecessary charge to be reviewed and refunded.
Do not assume the add-on was necessarily mis-sold simply because a different fault was later found. Preserve what was actually said: whether the add-on was described as mandatory, merely recommended, or one possible workaround.
When an engineer contradicts first-line support
Treat the engineer outcome as new evidence. Ask the provider to reconcile the earlier diagnosis with the engineer’s findings, rather than simply accepting “it is fixed now”. Useful questions include:
- What was misconfigured or incorrectly provisioned?
- When did that state arise?
- Which team or system could have detected it earlier?
- Was any paid product added because of the earlier diagnosis?
- Did the fault affect the recorded activation date or compensation entitlement?
- What change was made to restore service?
Automatic compensation: check the trigger, the provider and the dates
Ofcom’s automatic compensation scheme applies only to participating residential fixed broadband and landline providers and defined events. It is not a universal compensation code for every technical problem. For delayed start, complete loss of service and missed appointments, check the current Ofcom conditions and rates against the actual chronology.
If the provider is not a scheme signatory, or the fault does not meet a scheme trigger, that does not automatically end the complaint. Billing corrections, contractual remedies, discretionary redress and ADR can still be relevant depending on the facts.
Common provisioning responses, and the next question
| Provider says | Ask next |
|---|---|
| “The line is active.” | When did the service first pass a usable connection test, and what systems show that? |
| “It is your router.” | What network-side checks were completed and what result rules out provisioning? |
| “You need a static IP.” | Is that a product policy, a CGNAT workaround or a technical necessity on this connection? |
| “The engineer fixed it.” | What did the engineer change and what was the root cause? |
| “Compensation is automatic, so wait.” | Which scheme trigger has been recorded and from what date? |
What to write
Ask for a root-cause answer, not another generic fault update.
“Please confirm the actual root cause of the activation/provisioning failure, the date on which the service became correctly provisioned, and the technical change that restored it. Please also reconcile that finding with the earlier advice that I needed [product/add-on], and review any charge or delay caused by that advice.”
Continue from here
Related telecom guidance
Official sources
Check the rules behind this guide
Technical configurations vary by provider. Ask for the actual diagnosis rather than assuming one network design applies to every service.