A Repeat Is Not a Root Cause.

A customer loses service. A technician restores it. Two weeks later, the customer is down again.

That sequence deserves attention. The second outage may indicate poor workmanship, incomplete diagnosis, a chronic condition in the plant, or a repair that restored service without resolving the underlying fault.

It may also have nothing to do with the previous repair.

That is the problem at the center of repeat trouble.

Telecommunications operators have measured repeat trouble for decades because recurrence is operationally valuable information. When the same customer, service or asset returns to the repair process shortly after closure, something deserves a closer look.

The risk begins when that signal is asked to establish more than it actually knows.

A repeat metric can show that two events occurred close together. It may justify reopening the earlier repair, examining the workmanship, reviewing the history and asking whether the first intervention held.

It cannot always establish why the second event occurred.

A repeat ticket means another trouble report was opened. A repeat failure means the same or a related condition occurred again. A failed repair means the earlier intervention did not adequately resolve the condition it was intended to correct.

Those conditions may overlap. They should not be presumed to.

Once a repeat begins affecting technician performance, vendor accountability, financial consequences or corrective action, the organization has moved beyond counting recurrence. It is making a determination about cause.

Why the pressure around repeats is real

Operators have good reasons to care about repeated outages.

The first interruption may be accepted as an unfortunate part of operating a network. A second outage shortly after repair changes the customer’s frame of reference. The question becomes less about when service will return and more about whether the provider itself can be trusted.

That judgment carries greater commercial weight in a market where customers often have more alternatives than they did a decade ago and where broadband has become embedded in work, education, commerce and ordinary household life.

The judgment also travels farther.

A frustrated customer can publish the entire experience directly beneath a provider’s own brand. Other subscribers add their stories. Competitors are recommended in the comments. Prospective customers can encounter the complaint while deciding whom to buy from.

A repeat therefore has consequences beyond another truck roll. It can affect retention, reputation and acquisition at the same time.

That commercial pressure makes accurate diagnosis more important. Penalizing the wrong technician, charging the wrong vendor, or redesigning the wrong process does not remove the customer consequence. It only reduces the likelihood that the next outage will be prevented.

The repair was more complicated than the code

Field repairs rarely unfold with the neatness implied by the final record.

Consider a customer with no light.

The technician tests the drop and finds poor performance, so the drop is replaced. Light improves but remains outside the expected range. The technician continues upstream and reworks a splice. The reading improves again, but another test points to a questionable condition near the premise. A pigtail is replaced, final readings fall within tolerance, and service is restored.

The trouble system then asks for a cause.

Was it the drop? The splice? The pigtail? General wear? Something else?

The technician selects the code that best represents the job and moves on.

A diagnostic sequence containing several observations, several interventions and multiple plausible contributors has now become one administrative field.

That field may later be used in trend analysis, technician performance, vendor reviews, repeat reporting or root-cause analysis. The database contains a precise category even though the repair itself contained more uncertainty than the code can show.

This is compressed causality: a complicated physical event is reduced to the level of resolution required by the operating system.

Some compression is unavoidable. Operating systems cannot preserve every observation at unlimited detail. The problem appears when the simplified record is later treated as though it contains more certainty than the investigation ever established.

What happened between the two tickets?

Now consider another case.

A vendor or technician repairs a fault on Monday. The technician enters a handhole, performs the required work, records test results and submits the required closeout information. The repair passes the operator’s prescribed acceptance process.

On Thursday, another party enters the same area. It may be another internal technician, a locate contractor, a construction crew, another service provider or an unrelated utility.

Something changes in or around the infrastructure.

On Saturday, the customer is down again.

The operator’s systems may contain a detailed record of Monday’s repair and little or nothing about Thursday’s interaction. From the perspective of the system, the sequence appears straightforward: the customer failed, a vendor or technician repaired the service, and the customer failed again shortly afterward.

The person or team associated with the earlier repair becomes the most visible candidate for responsibility.

Yet the operating history may be incomplete.

The last recorded actor may not have been the last person to interact with the plant. The last person to interact with the plant may not have caused the failure either.

This is attribution by observability.

The participant that documents its work thoroughly becomes easy to find in the record. Another party can touch the same infrastructure and leave little or no trace. A system intended to improve accountability can then create the opposite incentive: the most compliant participant becomes the easiest one to blame.

Acceptance should carry evidentiary weight

The earlier repair may also have passed every control the operator required.

The technician may have submitted optical readings, photographs, splice documentation and the appropriate closure information. The customer was restored. The evidence met the acceptance standard and the work was closed.

None of those facts makes the intervention incapable of failing later. A defect can be latent. A splice can perform correctly at closure and deteriorate. A required test can also have limitations.

If the earlier intervention is later identified as the cause of the repeat, the evidence should establish that relationship.

If the technician made a poor splice, the response may involve workmanship, training or individual performance. If another party disturbed the plant later, the issue may be access control, intervention records or field governance. If every prescribed check was satisfied and the defect escaped detection, the acceptance controls themselves deserve scrutiny.

Those operating problems require different interventions.

Classifying all of them as failed repairs may make the repeat measure easier to administer while leaving the actual failure mechanism unresolved.

The customer still goes down again.

What QC can and cannot tell you

Quality control establishes what the operator knows at closure.

A typical repair process may confirm that the customer is back online, optical levels fall within tolerance, required photographs have been submitted and the ticket is complete.

Those controls provide evidence about the state of the service when the repair is accepted.

They do not necessarily establish how the intervention will behave through time.

That limitation should shape repeat attribution. If work satisfied the required acceptance controls, a later recurrence should trigger investigation rather than automatically invalidate the earlier evidence.

The relevant question becomes whether the later failure demonstrates a defect in the original intervention, exposes a limitation in the acceptance process, or reflects something that occurred after closure.

Different markets expose different parts of the problem

Repeat trouble exists inside very different broadband operating models around the world.

The customer experience is simple: the service failed again.

The organizational path behind that failure can be very different.

United Kingdom: attribution inside a wholesale relationship

The UK separates much of the retail broadband relationship from the underlying access infrastructure through Openreach.

Retail communications providers depend on Openreach facilities to serve their customers, so network performance sits inside a wholesale commercial relationship rather than entirely within one vertically integrated operator.

Ofcom has long tracked repeat faults across Openreach services, defining repeat faults within specific windows following a previously closed repair. FTTP has been included in those measurements.

Openreach is also subject to regulated quality-of-service obligations across parts of its wholesale portfolio. Ofcom has previously found that Openreach failed to meet some repair and provision standards, illustrating that wholesale separation does not remove operating problems.

It does, however, make the commercial boundaries clearer.

The infrastructure operator is selling service to companies whose own customer relationships depend on that infrastructure. A persistent network problem therefore travels quickly into a supplier-performance conversation.

This model therefore makes attribution commercially necessary.

The discussion has to establish where the failure sits in the service chain, which organization controls that layer and which obligation applies.

France: preserve the intervention history

France exposes another part of the problem.

As its FTTH networks matured, operators and regulators encountered quality issues involving field interventions, degraded shared infrastructure and inconsistencies between information systems and physical plant.

The response has increasingly focused on preserving evidence about the intervention itself.

Arcep reports that operators have worked toward systematic photographic reports for field interventions so the condition of key network points can be checked before and after work. The regulator has also tracked technician and subcontractor performance, defective connections, correction rates and efforts to realign information systems with actual field conditions.

That creates a richer operating history.

When a failure appears after several organizations have interacted with shared infrastructure, the investigation can ask who entered the plant, what condition existed before the intervention, what changed, and what condition remained afterward.

That is a materially different evidentiary position from knowing only which repair ticket came before the repeat.

France still experiences workmanship problems and network degradation. Arcep's 2026 scorecard continued to identify defective connection work and called for stronger monitoring of technicians and subcontractors.

The value of the French example is not that the problem disappeared. Persistent operating pain pushed the system toward better intervention provenance.

Canada: wholesale competition adds another layer

Canada is moving toward broader wholesale use of incumbent FTTP networks.

The CRTC now requires major telephone companies to provide competitors with workable wholesale access to fiber networks, allowing retail providers to offer service using infrastructure owned by another company.

That adds another organizational boundary to repair and reliability.

A customer may buy broadband from one company while another controls much of the underlying access network. The retail provider owns the customer relationship, while the physical failure may sit elsewhere in the service chain.

Canada does not need a full separate theory for this article. It reinforces a broader pattern: once ownership and customer responsibility are separated, recurring failure becomes harder to resolve through a simple “last repairer” assumption.

Start with what changed

A more useful repeat investigation begins with a different first question.

Instead of asking:

“What did the previous technician do wrong?”

ask:

“What changed between the two tickets?”

That inversion changes the investigation.

It directs attention to the entire interval between closure and recurrence. Who interacted with the asset? Was construction taking place nearby? Did another technician enter the enclosure? Did the physical route change? Was the same component involved? Did the second failure present the same symptoms? Did the earlier repair remain intact?

The previous intervention is still part of the investigation. It simply stops being the presumed answer before the investigation begins.

The process can then narrow toward evidence.

Did the second trouble ticket involve the same service?

Was the same failure domain involved?

Was the same physical asset implicated?

What did the first closeout establish?

What occurred between closure and recurrence?

Does the current evidence demonstrate that the earlier repair failed?

Those questions turn the repeat metric into a diagnostic trigger instead of a causal shortcut.

Economic pressure eventually demands better diagnosis

Different market structures place the cost of recurring failure in different places.

A vertically integrated operator may feel it through truck rolls, support contacts, technician productivity, vendor cost, customer credits, churn and reputation.

A wholesale infrastructure provider may experience it more directly through service obligations and dissatisfied retail operators whose own revenue depends on network availability.

Either way, persistent failure keeps generating cost until the underlying condition changes.

An organization can respond by becoming more aggressive about the metric. It can tighten thresholds, impose penalties, add scorecards and escalate accountability.

Those actions can change behavior.

They cannot substitute for diagnosis.

If recurring failure comes from poor workmanship, improve workmanship.

If uncontrolled access is damaging infrastructure, improve intervention governance.

If inaccurate records are delaying diagnosis, improve the records.

If acceptance controls cannot detect the defects appearing later, improve the assurance process.

If the second outage was unrelated to the first, investigate the second outage.

The corrective action should follow the failure mechanism.

The number is not the outcome

Repeat trouble deserves serious attention.

A customer who loses service shortly after a repair has good reason to question whether the connection can be trusted. Operators have equally strong reasons to prevent that experience.

The repeat metric tells them where to look.

It should not tell them what they found before the investigation begins.

Recurring trouble can reveal poor workmanship, incomplete repair, weak records, inadequate assurance, uncontrolled intervention or two unrelated events that happened within the same measurement window.

Those conditions do not respond to the same intervention.

A dashboard can show fewer repeats while the underlying operating problem continues. Financial penalties can change who pays for the failure without changing why it occurred. Stronger accountability can still point in the wrong direction when the evidence behind it is incomplete.

The customer ultimately judges something simpler: whether the service stays working.

Misdiagnosing a repeat does not remove the commercial consequence. It makes the corrective action less likely to prevent the next one.