Provide instruction on how to disposition support tickets
Correct ticket dispositioning is absolutely critical for accurate tracking of information inside of Salesforce. This page will discuss the basic ticket dispositioning that needs be done to ensure the ticket is correctly tracked.
Step 1. First you must determine the Record Type. There are multiple types to be used in certain situations. Some may be self-explanatory, but descriptions are below.
- Support Standard: this would be used for all trouble tickets
- MACD: for any add, move, change, delete requests
- Account Management: For tickets that need to go to account management
- Billing: For updates to customer billing information, billing questions, etc.
- Customization: For customer requests that need to go to our Customization team for review.
- Demo: For sales to provide demos to customers
- Implementation: For all tickets in our implementation team.
- Master: For P1G or master tickets
- SPAM: For any SPAM tickets
- Salesforce Support: for all tickets sent to email@example.com
- TMACD: for all requests sent to our Telecom team.
Step 2. Once the record type has been selected, you will need to disposition the ticket. While each record type will have different disposition requirements, it is recommended you fill out as much information as possible for accurate tracking. The information needed is below.
- Status: New, in progress, on hold, resolved follow up, etc
- Support representative: While the case owner can be changed, this field is for the person ultimately responsible for progress and communication on the ticket.
- Contact: Be sure to put the customer contact here. Also verify that the information within that contact is correct (phone and email)
- Type: Problem, Request Information, TMACD, etc.
- Product: 3cx, Connect, Networking, Skype for Business, etc.
- Sub-Product: Hardware, Software, Voice, etc
- Issue: QoS, Model Type, Client Type, etc.
- Sub Issue: Cache, Config/Settings, Physical Issue, etc
- Other issue: field only needed if you select the sub issue as "other"
- Account Name: Assign to the correct customer account
- Location: Most companies have multiple locations; specify which location is in relation to the ticket.
- Case origin: Email, phone, chat, internal.
- External ID: This field is for tickets we open with our carriers or vendors. It's also good practice to put the external ID in a case comment for redundancy
- External carrier: to show which carrier the External ID is related to.
- Department: Use this if the case should be with support, billing, telecom, sales, account management, etc. While this is not a required field, it is critical that it is correct for correct tracking of a department's work.
- Parent case: If the case is associated with a previous case, or a master case, put that case number here.
Step 3. Case Priority: A detailed explanation of case priority and our SLA can be found in our case management policy here https://www.uc.solutions/CallTower_Internal/Support/Case_Management_Policy
Case Priority Disposition (Problem Cases)
Severity refers to the seriousness of the issue in regards to business impact or criticality of services affected. Issues are dispositioned as High, Medium or Low.
Customer is “hard down”; total impairment of critical voice/data services; severe business impact
Examples: circuit is down; DID returning a fast busy; 911 is not routing properly; phone is not registering, hardware failure
Partial or intermittent impairment of critical voice/data services causing severe business impact
Examples: Intermittent call drops; cannot transfer calls, intermittent voice quality issues, unable to retrieve voicemails
Services affected have low or no business impact; User is still able to use critical voice/data services; only select features are affected.
Examples: MWI light; unable to join Skype meeting from Outlook; presence not showing correctly; JIRA error while making provisioning changes; MACDs; requests for information; feature requests
Urgency refers to the magnitude of the issue by evaluating the number of individuals and the position or the value of the customer being affected by the issue. Issues are dispositioned as High, Medium or Low by meeting one of the following requirements.
An entire site is affected
5+ users are affected
2 – 4 Users are affected
Single user is affected
Note: Management can modify urgency for a customer as needed. Customers can escalate their urgency via management escalation and the support portal
Case Priority Disposition (MACD Cases)
All requests for a change to an account, services, user settings, etc. The department Support will be used on all requested changes for MACD, Implementation, Demo and Porting.
All MACD requests are handled by default on a standard timeline. Cases will be reviewed within 2 hours of being opened and assigned to the provisioning queue. Requests are typically completed within two business days. If a request cannot be completed within two business days, a communication will be sent to the requesting MPOC clarifying the estimated time to complete the request.
For an additional fee, customers may request an expedite on their requests. Requests will be placed ahead of standard requests in the provisioning queue. Cases will be completed or communication sent to the requesting MPOC within 24 hours of case opening. All expedited ordering or shipping costs will be passed to the customer.
Customer Expectation Date
All MACD cases will include a case expected completion date to be filled out. This field will be the date you have communication to the customer that their request will be completed. The typical Standard request will be completed in two business days; however, if an equipment order/DID order is part of that request, the expected completion date may be longer than two business days away. This date should be communicated to the customer and work should be completed by the date.
Case Closure Best Practices
The required fields should be accurately filled in prior to closing.
Resolved Follow-up Required:
This status is an active status of a case. Communication and regular follow-up with the customer is required. This status is used when either a solution to the case has been provided or confirmation the issue has been resolved has been received. This status is fluid and if a case believed to be resolved is not fully resolved the status should be reverted to its accurate state.
The goal of each support case is to bring it to full resolution by addressing the root-cause of an issue. Cases can stay in a resolved follow-up required status until conditions for closure are met. Cases should not be closed until one of the following is met:
Confirmation issue is resolved
The ideal circumstance to close a case occurs when the customer gives confirmation that the issue is resolved and gives permission to close a case. Cases may be immediately closed following a confirmation from the customer to close a case.
Technician validated issue is resolved through testing
In many cases, a technician can prove the issue has been resolved. Customer confirmation is still the ideal situation to ensure all concerns have been resolved. If you can prove the issue is resolved, keep the issue open in resolved follow-up required until the end of the business day to allow for a customer response.
Closed No Response:
If a customer fails to respond to your requests for needed information to continue working a case or to confirm closure, it may be closed no response. A diligent effort must be made to contact the customer to ensure we are doing all we can to resolve the issue before closing no response. At a minimum, three unanswered attempts must be made across two business days, utilizing at least two methods of communication, before closing no response.