Escalation Criteria and Timeframes
The RPSS partner should escalate issues to Polycom technical support when a problem remains unsolved and:
- The RPSS technical support group has exhausted its knowledge including referring to:
- Polycom Knowledgebase
- Polycom Product Documentation
- Any other appropriate knowledge source at the RPSS Partner
- The RPSS technical support group has taken all reasonable steps to isolate, replicate, and troubleshoot in their lab environment
- Try and take steps to reproduce the issue in a lab environment.
- The RPSS technical support group seeks assistance in developing an appropriate action plan for resolution
- The issue has exceeded 48 business hours without resolution
- The customer is threatening to escalate to Polycom directly
General Information Needed When Escalating
When contacting Polycom support for assistance, please provide the following data:
Please note that failure to follow these escalation guidelines and to supply log file information may increase the time to resolution!
Product Families Listed Below in Detail:
- For best results, the RPSS technician should be onsite in front of the equipment so that Polycom can check settings real-time and perform needed testing. If remote access is all that is possible please let the Polycom agent know.
- The RPSS technician should have already removed or bypassed any third party devices in an attempt to isolate the problem to the Polycom product or identify the problem to inter-product compatibility.
RPSS and Customer Information
- Contact information for the CSP technicians who is contacting Polycom (Name, phone, and email)
- The reported Date and Time that the issue was brought to the CSP team by the shared customer
- Summarize what has been done to rule out third party equipment / software
- Detailed reports on support performed by partner prior to escalating to Polycom
- The Site Location and the name and address of the system's owner
- Unique Serial Number of the product
- Current running software version of the Product (Including all patches, hotfixes, that are installed Example: 188.8.131.52_J)
- Detailed Product configuration (model, options, peripherals, etc. Examples: PTC, ISDN Plink, MPMx Card)
- Data collection information retrieved from running diagnostics or gathering traces/logs
- As many details as possible on the network and the product environment (Example: Detailed IP information or network topology drawing)
- Information on any recent changes to customer environment ·(Example: Firewall change or software upgrade was recently performed)
- Any temporary workaround which is currently in place
- Detailed problem statement summarizing the technical problem or question. The problem statement needs to be clear and concise, indicating how the system is not working as expected, what other pieces of equipment are involved, what day / time was the issue observed and have the following details:
- How to identify the problem area and steps taken to isolate the issue.
- Must include what Polycom product(s) is problematic and the nature of the issue
- Steps already taken prior to escalating to Polycom
- Data collection information retrieved from running diagnostics or gathering traces/logs (exact traces/logs outlined in this presentation)
- As many details as possible on the network and product environment
- Severity level (critical issue, minor bug, etc.)
- Frequency of the Problem (regular, one time only or intermittent ongoing problem. How long between failures?)
- Provide any error messages and symptoms that have been experienced
- Answer to this question: Do you currently have access to the system?
- Answer to this question: Did it work before or is this a new install?
- Answer to this question: Is this used in a UC environment? If yes, which type of UC environment (Microsoft, IBM, Avaya, etc)