Any tips for speeding up a re-connection after being "slammed"

liquidcore: Perhaps @Wheelbarrow01 could chime in :)

If you hate long posts, you might regret tagging me on this one 😂

There was a similar case back in early September that was discussed in this forum. I provided a detailed explanation of all the issues at play here. Unfortunately when that issue got resolved, the OP chose to delete the thread, so I am unable to link back to my original comments, but I will try to summarise again below. Brace yourself - this is a very long post but there is a lot to cover (and I've probably missed something out).

After consultation with the industry, Chorus recently decided to trial the removal of Losing Service Provider validation in a fibre transfer scenario. In reality this means that any RSP can now run a Transfer order on any fibre connection without having to know who the current RSP is. They still need to input the name of the Losing Service Provider, however right now, that information is not being checked to see if it is correct. Instead, the incoming RSP can select any LSP name at random, and the Transfer will proceed as if the name they have entered is correct. At the original end-date of the trial a month or so ago, RSPs generally agreed to the trial being extended. It is still ongoing and at this stage no decision has yet been made on whether the features of the trial will become permanent.

There are legitimate reasons why some industry players have long called for LSP validation to be removed:

1. Some smaller players are just resellers of larger players. For this reason, it can often be difficult to correctly identify the right LSP name. Let us say that customer Jim originally connected up with Aardvark Fibre Ltd, but Aardvark Fibre Ltd does not have a direct relationship with Chorus for fibre services - only copper services, so they choose to wholesale the fibre service as a second tier provider from Buffalo Internet Co. Jim gets billed by Aardvark Fibre Ltd but the service is ultimately connected with Chorus through Buffalo Internet Co. One day Jim decides to change RSPs and wants to connect with CamelNet. Jim tells Camelnet he's connected with Aardvark Ltd, so Camelnet runs the Transfer and selects Aardvark as the Losing Service Provider. Chorus reject the order as the LSP name is not correct. There are over 100 LSP names to choose from. That is a LOT of orders to run in the hopes of correctly identifying the correct LSP name, so a very frustrating and time consuming process for Camelnet to follow.

2. Some RSPs have complicated ownership structures as a result of years of larger players buying up smaller players. Let's pick up the example above. Jim stays with Aardvark Fibre a few more years, and in the meantime, Aardvark Fibre is swallowed up by Dolphin Com, a much larger company. Dolphin Com has a direct relationship with Chorus, so most of their customers have the LFC name Dolphin Com, but some may still be on the old Aardvark billing platform and are still being served through Buffalo Internet. You can see how this can very quickly get confusing...

3. To try and get around the nuances above, some RSPs have created robots to do all the legwork for them. When a consumer calls to request a Transfer to them, their automated robot runs the order - multiple times if necessary, and runs through the list of LSP names - one on each order - until the correct LSP name is selected and Chorus accept the order. Of course this sort of makes a mockery (personal opinion) of Chorus requiring the LSP validation in the first place, as the robot simply tries each name in turn until one works.

What we have been seeing for a few years now (prior to our Transfer Trial) is examples where Jim lives at number 6, but gives Buffalo Internet the wrong address by mistake. Maybe his letterbox says 6A but he's actually just 6 and his property manager who looks after both units doesn't know which is which (trust me, it happens). Or maybe Jim lives at 6 Bolton St Herne Bay but there's also a 6 Bolton St in Howick and the suburb is not correctly communicated (this also happens regularly). Either way, Buffalo Internet's first Transfer order is rejected by Chorus for the wrong LSP name (as the address is wrong), however rather than double check the address is definitely correct, Buffalo Internet assumes there's a second tier wholesaler issue at play, so they engage their robot to try all possible LSP names. Multiple automated orders are placed in quick succession until one is eventually accepted. Jim's neighbour Shirley subsequently loses service as the wrong connection has now been transferred, but Jim is still with Aardvark and could be completely unaware that anything has gone wrong.

Shirley calls her provider Echidna Fibre, who have no idea what's happened - all they can see is that their connection is no longer active at the address as it's been replaced by another RSP's connection. Echidna can't just transfer it back as they don't know which RSP has it. They try a couple of the main players but no joy, so at this stage all they can do is run an Abandonment order (Connect & Replace) commonly used in Move Address scenarios. This sends a notification to Buffalo that their customer may have moved out, but Buffalo are not yet aware that they've connected Jim at the wrong address, so they reject the Connect & Replace order (as is their right), and Shirley still has no service. Echidna eventually escalates the issue to Chorus, and it eventually makes it's way to the Chorus Service Delivery Manager. The SDM has to work backwards to find out what's happened (and what should have happened), then contact Buffalo's SDM, so that the mistake can be made known and corrected. This all takes time and manual effort.

The solution sought by the Chorus Transfer trial is to remove any roadblocks to allow any Transfer to be completed successfully first time. And in theory, if the Transfer is completed on the wrong address/service by mistake, it should be just as easy for the RSP that has lost service to transfer it right back again. Unfortunately as the validation removal is still only in a trial phase, some RSPs have actively chosen not to tell their frontline agents that the trial is happening. This is because LSP validation is still required for transfers of other services (such as copper voice services and DSL). If they advise their frontline agents that LSP validation has been temporarily removed for fibre transfers on a trial basis, their agents may get confused and try to transfer copper voice or DSL with missing or incorrect LSP details - which will of course fail and cause a lot of rework and delays for those customers. So without knowing that they can transfer the customer straight back in a matter of hours, they instead follow the old process of running a Connect & Replace order - which takes much longer and can possibly be rejected by the other RSP, requiring escalation to Chorus.

There are other risks that have been identified as a result of the transfer trial and these are currently being investigated to see what solutions can be found, and this is part of the reason that no final decision has been made on whether LSP validation will remain off permanently, or whether it will be turned back on again. But at this stage Chorus appears to have wide support from the industry for the validation to be permanently turned off, with very low volumes of complaints due to transfers being completed in error. Most instances of incorrect transfers have been reversed quicker than ever, but we appreciate some have not due to the existence of the trial not being communicated to some RSP frontline agents.

Of course I appreciate it appears to have had a big impact on the OP in this case, but from what I can tell it looks like Spark eventually managed to get it all sorted out without asking for Chorus assistance. I suspect Spark frontline tried the Connect & Replace process first, and when that made no progress, Spark's Fibre Connection Support team stepped in (who are aware of the trial), so they will have then canned the C&R, and run the transfer that eventually got the OP reconnected.

If you are still reading this, I commend you.

Caketiger

Wheelbarrow01