This document is offered compliments of BSP Media Group. www.bspmediagroup.com All rights reserved.
Jun 14, 2015
This document is offered compliments of BSP Media Group. www.bspmediagroup.com
All rights reserved.
Efficient and simple por1ng processes make one day por1ng a reality
Raymond Bouwman, Rabión Consultancy
Mobile Number Portability Implementa<on and Management -‐ Dar es Salaam, Tanzania, 15-‐16 nov 2012
About Rabion Consultancy… NP and Numbering Management and Domain Naming projects:
TRA Bahrain, OUR, Jamaica, TRC Jordan, TAS Suriname, European
Commission DG CNECT, DTZ Aruba, BTP St. Maarten, BTP Curacao etc.)
Operators (KPN, T-‐Mobile, Orange, UTS)
Service Providers
Enablers ( Vodafone Roaming Service)
Suppliers
AGENDA 1) The reality of shortening por<ng <mes 2) Stats 3) What is causing the customer experience? 4) Drivers behind 5) Who need fast por<ng <mes? 6) Drawbacks of fast por<ng <mes 7) Conclusions 8) Recommenda<ons
• 6
Brussels, 23 March 2009 EU Telecoms Commissioner calls for consumer right to change phone operator in 1 day
"Europe should be ambi1ous when it comes to empowering our consumers," says Commissioner Reding in her video message. "Because empowered consumers are the best recipe for strong compe11on on the market, investment into a=rac1ve services and, at the end, lower prices for all.“
"I want all Europeans to be able to switch their phone operator – whether mobile or fixed – within one single day, as it is already the case in Ireland and in Malta.“
Why ‘one day por<ng’ has become the standard/benchmark?
Examining the por<ng <mes: Average number of days to port a number (EU)
MNP FNP 2011 2,5 3,8 2010 ? ? 2009 4,1 5,9 2008 8,5 7,5
Not en<rely clear what ‘average’ means (average over countries, average over ported customer, or weighted average over the total subscribers etc.
na
na
na
na
na
0
2
4
6
8
10
12
BE BG CZ DK DE EE EL ES FR IE IT CY LV LT LU HU MT NL AT PL PT RO SI SK FI SE UK EU
Number of days needed to port a fixed number, October 2010 - October 2011
2010 2011
EU, DG Connect, Digital Agenda Scoreboard 2010-‐2011
na
na
0
2
4
6
8
10
12
BE BG CZ DK DE EE EL ES FR IE IT CY LV LT LU HU MT NL AT PL PT RO SI SK FI SE UK EU
Number of days needed to port a mobile number, October 2010 - October 2011
2010 2011
EU, DG Connect, Digital Agenda Scoreboard 2010-‐2011
na
na
na
na
na
na
0%
2%
4%
6%
8%
10%
12%
14%
16%
18%
BE BG CZ DK DE EE EL ES FR IE IT CY LV LT LU HU MT NL AT PL PT RO SI SK FI SE UK EU
Fixed number portability transactions, 2010 (Jan-Sept) - 2011 (Jan-Sept)
2010 2011
EU, DG Connect, Digital Agenda Scoreboard 2010-‐2011
na
0%
1%
2%
3%
4%
5%
6%
7%
8%
9%
10%
BE BG CZ DK DE EE EL ES FR IE IT CY LV LT LU HU MT NL AT PL PT RO SI SK FI SE UK EU
Mobile number portability transactions, 2010 (Jan-Sept) - 2011 (Jan-Sept)
2010 2011
EU, DG Connect, Digital Agenda Scoreboard 2010-‐2011
Learning from case studies and best prac1ce examples of effec1ve por1ng procedures and quick por1ng 1mes.. Less that 24 hours : USA (2,5h), Canada (<3h), Australia (3h), New Zealand, Ghana, Chile (2h), Ireland, Malta (4h) … 1 day : UK, Singapore, Lithuania, Luxemburg, Spain, Denmark, Poland. More than 1 day: all the rest…. In Ghana ‘17 minutes and 19 seconds’, but 45% within 5 minutes (while wai<ng in a shop)
Por<ng process -‐ <me components
Picture edited from European Commission Commijee, report 2010
Wai<ng <me before PR submission to donor
Processing <me at donor
Wai<ng Time before execu<on
Execu<on Time
EU Universal Service Direc<ve
Por<ng of numbers and their subsequent ac<va<on shall be carried out within the shortest possible <me.
In any case, customers who have concluded an agreement to port a number to a new undertaking shall have that number ac<vated within one working day.
Defini<ons Examples ’ Por<ng Time’ 1) Time between submission of the Por<ng Request by recipient
and the comple<on of the number por<ng execu<on (including the ac<va<on at the new network)
2) Time between approval of the Por<ng Request by Donor and the comple<on of the number por<ng execu<on (including the ac<va<on at the new network)
3) The actual Por<ng Execu<on
Defini<ons Examples ’ Por<ng Time’ 1) Time between submission of the Por<ng Request and the
comple<on of the number por<ng execu<on (including the ac<va<on at the new network)
2) Time between approval of the Por<ng Request and the comple<on of the number por<ng execu<on (including the ac<va<on at the new network)
3) The actual Por<ng Execu<on
Other points of ajen<on on Por<ng Time • Difference between Recipient-‐led process and a Donor-‐led process
(end-‐to-‐end cycle is different) • Service Providers or resellers in the chain: they may need processing <me • What if Por<ng Request is rejected, is this part (Time!) of the process? • What is a working day? Por<ng Only during Working Hours/Working Days, or 24/7
por<ng? What if requests arrive on Friday at 16.55 just before closing? • Condi<ons not allowing NP in due <me (within the requested por<ng <me frame)?
Postpaid in par<cular (Contract binding period, terms of no<ce, bad debt, suspension)
• Groups of numbers • Physical Limita<ons that need <me (PSTN fixed, SIM distribu<on!), • Central Systems Quota management
What is causing the customer experience?
1) The por<ng method procedure 2) The technical system implementa<on 4) Terms and Condi<on for rejec<ng the Por<ng Request
1) Por<ng Method • Simple Interoperator Messaging Processes • Effec<ve valida<on rules (but s<ll fulfill security requirements
and prevent fraud) • Only require customer/subscrip<on data relevant to the
process • Electronic authorisa<on instead of handwrijen signatures, no
exhange of paper forms
RECIPIENT DONOR CENTRAL SYSTEM
Por<ng request
Por<ng request ACCEPT
Por<ng executed
Por<ng execu<on
Tcs
T1
T2
T3
1) No specific por<ng Date and at Time agreed. Por<ng happens whenever it happens!
2) Receiving a message just triggers the next step message 3) Por<ng <me is T1 + T2 +T3 + Tcs’ + Tcs’’ + Tcs’’’ + Tcs’’’’
‘Go with flow’ por<ng
Donor handling time
Execution at
Recipient Execution at Donor
RECIPIENT DONOR CENTRAL SYSTEM
Por<ng request(por1ng date/1me)
Por<ng request ACCEPT
Por<ng executed Por<ng execu<on
1) Request for specific por<ng Date/Time. Por<ng Execu<on waits un<l por<ng Date/Time has arrived.
2) Capability to schedule Number Por<ng to take place in the future
Por<ng <me is T1 + T2 +T3 + Tcs’ + Tcs’’ + Tcs’’’ + Tcs’’’’ + Wai<ng Time
‘ Planned Time’ Por<ng
Por<ng Date & Time
Wai<n
g <m
e
T1
T3
Donor handling time
Execution at Donor
T2
2) Technical system implementa<on • Automated procedures, no (or minimal) manual interven<ons • No Batch Processes (<me consuming, non-‐real <me), but event-‐
driven • Overall Data Consistency and low fault rates (Central Database
solu<on, and Central Agent/Clearing system) • Provisioning Process (Number Ac<va<on) must be efficient and
reliable, and well integrated with Por<ng Execu<on
3) Terms and condi<on Reasons not to accept a Por<ng request (non-‐prepaid) e.g. : • Contract End date not reached • Terms of No<ce period before a subscrip<on has to be legally
terminated • Outstanding Payments • Bad Debt or other liabili<es unresolved Allowing any of these circumstances to reject a por<ng request will
not lead to the best possible por<ng <mes NP should be free of barriers if fast por<ng <mes are desired. For always fast por<ng <mes, keep Contractual T&C and Por<ng
Rules separately
Understanding the drivers behind reducing por1ng 1mes
• In general, Regulators are the drivers to short and efficient por<ng
• (Many) Operators may have objec<ons and see complica<ons (primarily commercial reasons)
• More important is to look at the customer: Q: Does ‘one por<ng <me fits all’? A: In general shortening Por<ng Times is a good thing, but the Por<ng Time should be just what the customer needs, and not necessarily the shortest possible <me
Why improve/shorten the por<ng <me? • Because Telecom Regulators want it • Maturity of NP solu<ons. Because it is technically possible • Because Customers do not want to wait, if no reason • Improvement of the Customer Experience, process that is
easier to understand • Contribu<on to more level of compe<<on in the Market • Benchmark between countries: faster is bejer!
Is a minimum por<ng <me required for all types of customers? CONSUMER PREPAID (shop order) : YES, Less than 10 minutes (while
wai<ng at the point of sales) PREPAID ON LINE SALES: NO, several days available, but quick
execu<on may be triggered by customer once SIM card received LARGE BUSINESS: NO, customer needs prepara<on and <me for
migra<on, Typically 4-‐6 weeks FIXED PSTN: NO, physical connec<on or LLU needs <me, Typically 2
weeks VOIP: YES even for online sales CONCLUSION: Do not get hung up on ultrashort por<ng <mes as a
rule, but make the Por<ng Process and the <ming fit to the customers’needs
DRAWBACKS on FAST PORTING TIMES? 1) ‘impulsive buying’, no <me to think it over twice. 2) No <me to ask the Donor for a bejer deal! (Remember
that MNP is a tool for more compe<<on and bejer pricing) 3) Non-‐paid customers may be surprised by unexpected/
unknown pay-‐off costs? 4) Higher risk to ‘Slamming’? 5) Prepaid Credit at the old network lost? 6) No <me to ask the Donor for a bejer deal! Remember that MNP is a tool for more compe<<on and
bejer rates. The number of ports nor the por<ng <me dura<on are goals in itself
Discussion Tanzania Por<ng Time defini<on?
Conclusions 1) Trend that average por<ng <mes are decreasing. Por<ng <mes
of 1 day or less have become common . Near real-‐<me por<ng bas become the reality.
2) The defini<on of ‘Por<ng Time’, and monitoring has to be carefully considered.
3) The barriers to reach fast por<ng <mes (1 day or less) are primarily of a legal nature. Technical barriers can be resolved.
4) Trade-‐of between ‘Fast Por<ng Times’ and ‘Por<ng Reject Reasons’
5) The Por<ng Time is not a ‘fit for all’. Various type of users and situa<ons need differen<a<on depending on customer requirements.
Recommenda<ons Regulatory authori<es have to : • Look into ‘Por<ng Time’ in a detailed and way • Provide clear and understandable defini<ons • Set realis<c and representa<ve targets, not only for por<ng
<me but also for valida<on <me, down <me etc. • Avoid ‘one-‐fits-‐all’ objec<ves • Take into account difference between customers,
proposi<ons, fixed vs. Mobile • Provide clear instuc<ons for monitoring and repor<ng por<ng
<me performance