In reply to a post by jpm:

Not an Openreach issue IMO, the physical link is good and the ordering process worked as it should do. It’s not Openreach’s responsibility to check that migration orders are legitimate - it’s 100% on BT for not properly cancelling the transfer or checking the cancellation had gone through properly.

I agree

not sure you could call it ‘slamming’ per se but after a “repair” all the lines on our lane were transposed

Nope, I’d call that a jointing error.

They could put in process for that. Wouldn’t necessarily have to be an automatic rejection. They could pass it to a human to call and make other checks.

It was a major PITA jointing error.

In reply to a post by Pheasant:

It was a major PITA jointing error.

That is for sure.

In reply to a post by Zarjaz:

I’d call that a jointing error.

Seen it happen a fair bit on large cables where there are a number of clear wraps in the cable bundle.

In reply to a post by Pheasant:

That was Sky slamming was it not as I recall?

Yes, so as with EE in this case a lack of due diligence on their part.

As the notifcation of transfer was only sent by email, and from a different address than other correspondence so ending up in a spam folder, it was only when the service changed poeple realised something was going on. I'm sure the loosing provider would have been more proactive in rejecting the transfer request than BT in this case.

Interestingly I just tried an FTTP order against my own line using IDNet and they now request the ONT serial number to be entered where the installation type chosen is "Use Existing ONT":

IDNet FTTP order snapshot

It wasn't always this way with their ordering system. Quite the opposite in fact. So good on IDNet for putting in place some proper checks and diligence for migrations.

It wasn't like that a few days ago when it was being discussed.

Indeed squire. Coincidence or what 😅