Response and Escalation
Problem Definition & Classifications
Direct Escalation Policy
When you contact the BlackBerry® Technical Support team, a support ticket is initiated. Each support ticket is assigned a unique ticket number (for example, INC00001234567), which is used to track your issue from initiation to resolution.
The support ticket number will be provided either at the end of a call with a support representative or via an automated email message receipt when contacting BlackBerry Technical Support through the BlackBerry® Expert Support Center.
Use this support ticket number for all communication relating to that specific issue.
Problem Definition and Classifications
All requests for support are initially deemed to be problems by the BlackBerry® Technical Support team. When you report a problem, indicate its impact to your organization to assist the assigned BlackBerry Technical Support representative in classifying the problem’s severity.
The severity classification of a problem is determined by the BlackBerry Technical Support representative and yourself.
|Critical||A critical incident is defined as a problem that causes a total loss of service for which no procedural workaround exists. This problem may affect either the BlackBerry® Enterprise Server or a majority of the deployed BlackBerry smartphones. The problem severely affects the ability to conduct business
Note: Research In Motion (RIM) support teams are paged 24 hours a day, 7 days a week for critical problems and the Problem Management Team will be contacted. You must agree to be available for engagement 24x7 until relief has been provided
|Serious||A serious incident is defined as a problem that causes a severe degradation of service. Your key business process is impaired but not disabled. You may continue your operation, but in a restricted fashion|
|Normal||A normal incident is defined as a problem that has slightly compromised your ability to conduct business. Your productivity loss is minor. The situation may be temporarily circumvented with an established work-around|
|Low||A low incident is defined as a problem that has marginally (or not) compromised your ability to conduct business. The productivity loss is insignificant. This may include a request for service, enhancement or "how to" request. There is little or no risk of impact|
Note: Severity classifications may be updated during the lifecycle of a problem being worked on by the BlackBerry Technical Support team if the impact to the customer changes. The severity classification will be assigned by RIM, in RIM’s sole discretion.
The BlackBerry® Technical Support team sets response-time goals based on the method of access.
|Method of Access||Response-time Goal|
|BlackBerry® Expert Support Center||The initial response time BlackBerry Technical Support representatives will strive to meet for incidents submitted electronically via the BlackBerry Expert Support Center is the next business day.|
Note: The foregoing response-time goals are targets only and RIM shall not be considered to be in breach of any of its obligations if it can’t fulfill such target times.
Direct Escalation Process
Should you have technical issues of a Critical and Serious nature and aren't satisfied with the response or resolution provided to you by BlackBerry® Technical Support, use the following escalation path to have your concerns addressed:
- Request to speak to a supervisor.
- Contact BlackBerry Technical Support Management. Provide your support ticket number and details about the situation, including the date and time of the occurrence, by email to TechnicalSupportManagement@rim.com. You'll receive a response within one hour.
If, after using one of these escalation paths, you'd like to request additional support or provide direct feedback to the Technical Support Executive team, email TechnicalSupportExecutives@rim.com. Your email will be sent to the Senior Management within Customer Support Operations at Research In Motion (RIM).
If you have general feedback regarding your technical support experience, email email@example.com.
To effectively troubleshoot and resolve a problem, Research In Motion (RIM) may require you to provide records, such as log files or configuration files. If the requested information is not provided, it may impede RIM’s ability to resolve the reported problem.
It’s assumed individuals involved in support of the BlackBerry® solution products and systems are familiar with the processes outlined in this plan. It’s also assumed these individuals have received the required user training on any BlackBerry solution product or system they’re supporting.
Examples of customer responsibility for support and system maintenance include, but aren’t limited to,:
- Daily/weekly operator preventive maintenance tasks
- Providing RIM with accurate information about systems and software being operated to allow accurate and efficient troubleshooting of submitted incidents
- Providing RIM with a current list of all BlackBerry solution SRP IDs to be supported on the subscription
- Ensuring Named Callers associated with an account are verified on a regular basis and any changes to assigned Named Callers are communicated to RIM
- Site preparation and related environmental requirements
- User privileges
- Data loading procedures
- Maintenance of a centralized reference library for related product and system documentation
- Archive, back-up, recovery and periodic testing plans
- Assisting RIM to research and verify compatibility of recommended software patches
- Performing basic, initial problem isolation and identification before reporting an incident to BlackBerry Technical Support
- Participating in evaluating problem escalation priorities, when necessary
- Coordinating, facilitating and participating in periodic support reviews and technology meetings
- Supporting products not supported by RIM
- Scheduling change implementation activity
- Reviewing system change activity prior to implementation
- Providing facilities outside the production environment to test changes before implementation
- Ownership of approval to change to the system
- Verification of functionality after a change to the system