We recently ran a poll on this blog asking “Have you and your customers encountered issues with the existing MAC system and will the new one solve these?” Unsurprisingly, 50% stated that they hadn’t had any issues and believe the changes to be unnecessary with a further 38% stating a few issues had been experienced but that they didn’t think the new system would help. That’s an 88% majority that think the changes coming into force from June are unnecessary! So, why are Ofcom getting involved? After all, if it’s not broke - why fix it?
That’s a good question! Back in 2012 when the consultation began, Ofcom argued that they received numerous complaints on this subject and their own research showed problems with customer confusion, unnecessary delays, unfair costs and even slamming - although this was later agreed to be a much smaller problem than originally suspected. Therefore Ofcom set about to evaluate and change the current process and as a result the new Gaining Provider Led (GPL) system will take effect from June 2015.
Why GPL?
To quote Ofcom: “First, we believe that LPL (Losing Provider Led) processes lead to higher switching costs for consumers, both financial and in terms of difficulty. Under LPL consumers have to go through a process with their losing provider – who by definition has little incentive to help customers leave them. An LPL process would be likely to create significantly poorer customer experiences when, in contrast, the existing GPL process supports a positive experience.”
Ok, that seems reasonable but how big a problem is this? Is it really worth all the time, money and hassle that it is causing for Ofcom, providers and consumers? As far as we can see - no! A survey carried out by ThinkBroadband.com in 2012/3 (when the consultation began) showed similar results to our own more recent poll:
“6 in 10 users switched using the MAC process and overall 89% of users found the switching process easy. However, half of the users who couldn't use a MAC to switch found the process difficult.”
Surely, that would support sticking with the ‘easy’ MAC process then?
What’s happening now?
The new system is already causing confusion and issues for providers. As a wholesale provider, our resellers are required to apply for a RID (Reseller ID) - a code that will be required to identify a reseller in the new process. Without this RID new orders cannot be accepted and despite our best efforts this is already causing some issues and confusion amongst resellers that delayed in applying for their RID. Many have been assigned a temporary dummy code to use until a real code can be assigned- surely this makes a nonsense of the whole system which, by definition, requires ‘identification of the reseller’? As you can imagine this is causing providers a real headache!
It appears little thought (or consultation) has been given to the multi-tiered wholesale model which is widely adopted across the industry and affects many providers including Entanet. We have resellers with resellers of their own and whilst Ofcom have consulted with the biggest providers (BT Wholesale for example) they have not interacted with companies like ourselves or our wholesale customers who also have a large wholesale bases.
We support any process improvements that truly improve a customer’s experience and eradicate any complaints but we don’t agree that 1). the current MAC process actually caused that many delays and issues and 2). that the new GPL process will effectively provide a solution. Nevertheless, we will of course adopt the new system and comply with Ofcom’s requirements- regardless of our own opinion and experiences. Let’s see if they truly improve the ‘problem’ when the process comes into effect in June.
Have your say!
Have you experienced issues with the current MAC process? Do you think the new GPL system will improve these? Do you think the scale of the alleged problem warrants the implementation of a new system? Share your experiences and let us know your thoughts with a comment below.
Related articles
Further information
[cookiecontrol1]
[subscribe2]