Melissa Swartz | BCStrategies | June 22, 2018
It really is a crazy process
Most of the projects that I work on, large and small, at some point require porting of numbers from one carrier to another. Moving toll free numbers from one carrier to another is relatively painless. But moving DID numbers can be far more difficult than it should be. The process is highly regulated, and there are time frames for each step of the process. It should all be very predictable and well defined.
But it’s not.
The process can go smoothly … sometimes. But more often in my experience, it’s been challenging. A list of numbers to be ported is provided by the customer. The receiving carrier is responsible for coordinating with the carrier that currently has the numbers. The list of numbers to be moved should be validated (typically using a Customer Service Record [CSR] that shows the services that are billing on the account) and a date agreed upon by both carriers and the customer.
It seems simple enough. So what makes this so hard?
In some cases, the numbers are not portable. I have run into this in rural areas, where a non-dominant carrier can designate certain numbers as not available for porting. There are coastal areas where no other carriers want to co-locate because of the risk of hurricanes, so there’s no other carrier to move to. Another problem is that porting agreements between Telcos are not universal. We’ve seen situations where a number can be ported from Company A to Company B in one state, but in the state right next to it there’s no agreement and therefore no porting.
These issues are not typical, but they do come up.
The carrier losing the numbers typically is not thrilled about the loss. So there’s no benefit to them for being super-efficient or making it easy. They follow the rules, but if there is a task that should be done within 5 to 10 days, it is almost always completed at the end of the interval rather than the beginning.
Carrier records are wrong. This should come as no surprise if you’ve dealt with carriers very much. We have seen records that don’t show numbers we know are in use. We’ve seen records that have the numbers for other companies listed as belonging to our client. We’ve seen records where the information is fragmented and very difficult to find. All of these issues lead to the rejection of the request for porting the numbers.
One discrepancy will block the entire order. Any minor error results in a rejection. We have seen orders rejected because the receiving carrier submitted the customer name as “ABC Company Inc.” and the current carrier has the name as “ABC Company, Inc.” So the simple lack of the comma in the company name resulted in a rejection.
Furthermore, if there is more than one discrepancy on an order, you are typically informed of them one at a time. They don’t go through the entire order and find all of the errors; once they find the first error, they reject the order. It’s up to you to get the error fixed and submit a revised CSR.
Time frames start over. Once an order is rejected, in many cases the clock is reset. If the current carrier has five business days to respond to the receiving carrier, then even if the discrepancy is fixed immediately, the time period starts over and you usually have to wait the full five days again.
If there are multiple discrepancies on one CSR, you must keep going through this cycle until all of the “errors” are fixed. This can be quite time consuming.
Carriers have weird rules. Each carrier has different rules, so it’s worth the time to meet with your new carrier and have them walk you through their process. This is especially important if you are expecting to port multiple groups of numbers.
For one project I was working on, the receiving carrier had a rule that only one order at a time could be placed against their SIP trunks. (Having more than one order in place for a SIP trunk is called “stacking orders” and some carriers prohibit this). It took 30 days for them to get an order worked (if everything went perfectly) and during that time no other orders could be placed to move additional numbers to the SIP trunks. Once the first group of numbers was ported, another order could be placed, and it would take at least 30 days to be worked. We had 34 sites that were moving to SIP. They ended up creating some sort of workaround so that our project didn’t string out for 34 months, but as soon as the main work was done the “one order at a time” rule was back in place. You can’t make this stuff up!
So what can you do to make this process easier?
Recognize what you are dealing with. It’s a massive, illogical process, and you can’t let it drive you crazy. Prepare your boss and set expectations that there may be challenges.
Obtain your CSR information early in the process. As soon as you know you will be moving to another carrier, order a copy of your CSR(s) so you’re not waiting on them later. The bigger the project, the more important it is to take this step early.
Do a thorough comparison of the numbers you want to move with the numbers on your CSR. Don’t assume that the information in your CSR is correct. Be very detailed when comparing your list with the CSR; remember that one mistake will get your entire order rejected. Scrub your records with the goal of getting orders for any changes needed to the current Telco at least 90 days before you want to port the numbers. Make sure that everything matches, including phone numbers, account numbers, and addresses.
Give yourself extra time to get things done. Plan at least one order rejection into your time line for each port. Give yourself time to obtain your CSR information and even to place orders to get it corrected. Get your orders to the carrier 60 days in advance, even if they tell you they only need 30 days.
Recognize that the port dates will drive your implementation. You can create a plan and set target dates, but ultimately you will be at the mercy of the carrier so build some flexibility into your schedule. You cannot set a hard schedule until you have Firm Order Confirmation (FOC) from the losing Telco. You should try to get a FOC date at least two weeks prior to the time you really want to port the numbers. This will give you some room in the schedule for some minor issues, so that you are not within a day or two of your conversion, with fingers crossed, hoping for your FOC to come through.
Be prepared for numbers to port early. This is more likely to happen if you change the due date on an order, so avoid that if there’s any way possible. This can create a massive issue, and in our experience, executive intervention is the fastest way to resolve it. Getting executive contact information during the sales process will give you critical contacts that you could need in this situation.
Think about partial steps. If there is a problem with one number on an order, it may make sense to take it off of the order so that the rest of the process can continue. I received a list of toll free numbers that were on my client’s account from their carrier (carrier A). This same list of numbers was submitted by carrier B for porting, but was then rejected by Carrier A (remember — they are the ones who provided the list in the first place) because one number had a problem. We ended up taking that number off the list and re-submitting it (yes, the time frame started over) so that we could get the other 92 numbers ported.
Get creative. You can get a new number from your new carrier and forward the old number to it. Callers will still be able to dial the old number and reach you. Typically there is a cost for this arrangement, so you’ll need to do some math to see if this option makes sense in your situation.
Google and AT&T high-speed Internet services may seem like a bargain, but what are they costing consumers in privacy?
How do you make sure that your RFP gets the responses you need? How you phrase your RFP requirements can make all the difference.
An RFP that is issued at the proper time in the process, is supported by a thorough needs analysis, and clearly articulates the requirements of the organization, is an effective tool.
If artificial intelligence is part of your future, then the cloud must be, too.