This project serves to identify the use for all “non-standard routing plans” and ensure we record the use and reasons where applicable.
The ops/management team receives a report detailing Porta’s routing plan changes on account for the past week (per account/number). From this report, a summary is drawn to highlight the followings:
- Most used “non-standard routing plan”
- Account with “non-standard” routing with the highest volume of minutes
Action to be taken from the summary report:
- The report is sent out every Friday ( current status)
- One or more parent cases to be opened with Support. The case will have details of what needs to be investigated and provide the accounts / routing plans details (grouped) (Clarence G.)
- CSRs will proceed and create multiple child cases per customer and assign it to the new Queue that will be created for this project. Grading as the following example:
- Cases will be opened as per the routing plan used and/or the group of numbers per customer
Required:
- New Queue on SF
- Grading example to be provided for CSR (to avoid the case being shown under the portal)
Pointers on the how to work the case:
When addressing one of those cases, the Tech should look at (non-exhaustive list):
-
Check the history and other cases associated with the Number/SIP Trunk account ID. Search the number/SIP trunk account ID in Salesforce to see if you can trace any historical record in previous support cases of routing changes applied to determine the reason for the current routing plan being used.
-
If no related historical information can be found in Salesforce. The next step will be to check the last time the number/SIP trunk was used in Porta and run the XDRs to see the frequency of the traffic across the account ID.
-
For Enterprise/Premium customers, please consult with/involve the associated Premium Support Engineer on whether routing can be reverted to LCR.
-
You can check the audit logs under the account ID in Porta to determine whether changes were applied within the past 6 months. (This will display the date, time and user name who carried out the change) - That person can be asked for context or reason for the change.
-
If there is a record of the routing change in Salesforce(old cases), then check whether a related case was opened with the problematic egress carrier to see if the issue was resolved.
-
With regards to call forwarding to external numbers scenarios, check the routing simulation of the destination Ring To number under the customer’s profile using the current routing plan and compare it to the Routing Simulation of routing plan “Direct - US POP All Routes” or “US POP All Routes” to see if you still observe a difference.
-
If the number can be changed back to LCR, place an on-net test call from your Softphone to the number using the current routing plan being used to ensure calls are terminating successfully and to the correct destination. Next revert the account ID routing plan to an LCR routing plan (“Direct - US POP All Routes” or “US POP All Routes”)
-
If the option is available on Spearline, place two off-net test to see whether you are getting the same result. We need to keep in mind routing changes previously applied to accommodate accurate calling CLI delivery. If routing was changed to counter calling number CLI discrepancies, then there is no need to revert the routing plan to LCR.
-
For routing plan change previously made due to call audio quality, one-way audio, call disconnection, 2-way silence or DTMF scenarios without the issue being reported to the related carrier, the tech would need to investigate and try to open a new trouble ticket with the offending carrier.