Valentina Akpan: Founder of Rellatech, providing administrative and operations support to executives, founders, business owners and teams. Her background combines technical support, customer success, administration and operations.
The Starting Point
The company was moving a medical clinic's four phone lines away from its old carrier, through a wholesale porting partner. The first port request came back rejected because the reseller field held the losing carrier's name, when it should have been left blank.
There was a second problem in the same order. Every line had been saved with disconnect selected, which would have cut the clinic's service instead of moving it. The carrier fixed the disconnect setting through a support ticket, but the order still could not go ahead.
What I Did
I resubmitted the port the same afternoon. This time I left the reseller field blank, ran the number check before submitting, and looked at the data the portal was about to send to confirm that all four lines showed disconnect as false. I also asked for an earlier date than the original request.
The carrier confirmed the new order that evening, for the date we had asked for.
Around the resubmission, I updated the company's number inventory with the new dates and kept the carrier's ticket and the customer's ticket in step. I cleared the automatic rejection and cancellation notices, told the clinic the confirmed date, and set a reminder for an hour before the cutover.
Then I added two rules to the team's porting procedure, so the same rejection does not happen on the next order: leave the reseller field blank when the losing carrier owns the numbers, and check that no line is set to disconnect before submitting.
What Went Into the Work
The reseller field left blank
The first request was rejected because the reseller field held the losing carrier's name. When the losing carrier owns the numbers, that field has to be empty, so I left it blank on the new order.
Every line checked for disconnect
The first order had saved all four lines with disconnect selected, which would have cut the clinic's service instead of moving it. Before submitting, I checked the data the portal was about to send and confirmed that disconnect was false on every line.
The number check run first
I ran the number check before submitting the new order, rather than finding a problem after it had gone in.
An earlier date requested
I asked for an earlier date than the original request, and the carrier confirmed the new order for that date.
Both tickets kept in step
The carrier's ticket and the customer's ticket both showed the same status and dates throughout, and I cleared the automatic rejection and cancellation notices so nobody would act on an old message.
Two rules added to the procedure
I added two checks to the team's porting procedure: leave the reseller field blank when the losing carrier owns the numbers, and confirm that no line is set to disconnect before a port is submitted.
Why It Matters
A rejected port can push the move further out, for a customer who was expecting it sooner. Finding the cause the same day, fixing it in the order and asking for an earlier date meant the clinic did not lose time because of the rejection.
The disconnect setting mattered even more. If that order had gone through as it was saved, the clinic's lines would have been cut rather than moved. Checking what the portal was about to send, not just what the form showed, is the step that catches that.
The two new rules in the procedure mean the next person submitting a port has both checks in front of them, whether or not they have seen this rejection before.
Tools and Skills Used
Number porting, carrier coordination, ticket management, record keeping, customer communication and writing procedures that the rest of the team can follow.
Who This Is For
This case study is worth reading if you are:
- ●A telecom or VoIP provider whose port requests keep coming back rejected, or take too long to confirm.
- ●Running support tickets and carrier tickets in separate places and finding they drift apart.
- ●Looking for someone who fixes the problem in front of them and then updates the procedure so it does not come back.
Need help with similar work?
Tell me which part of your operations needs attention, who is involved and any dates you are working towards. I handle support queues, carrier coordination and the records around them within the scope we agree.
Book a free call