Install and configure the support convergence, auto-response, and article suggestion snap-ins so that customer conversations are acknowledged automatically.
Ensure that every customer org record in DevRev contains the following:
Pain points and primary use cases
Success plan for the account
Meeting notes and meeting recordings
Next steps and action items
Define a small number of tags to help categorize tickets. For example, at DevRev we have the following: bug, feature-request, other-request, question, incident.
Designate one or more support agents to be on call. Add those agents to the Support group inside Settings > Groups and as default owner in the Support Routing snap-in. Default owners are notified through email and the DevRev app as soon as a new conversation is started.
Respond as quickly as possible to any new conversation. Respond promptly (within 1 hour) to new messages on existing conversations. Change the stage of conversation to awaiting customer response as soon as you have responded.
In Updates, filter by Type > Mentioned. Respond to those updates first.
Create a ticket if you are not able to resolve the conversation in 20 minutes. As soon as the ticket is opened, move it to the escalate stage. The owner of the ticket will be the owner of the customer org where the conversation originated, usually someone from customer success or sales.
Ask follow-up questions to get full context of the problem.
If article suggestion did not help the user, search in the customer-facing documentation or knowledge base and share any relevant results.
If you judge that a message that starts a conversation is invalid (such as spam), mark the user record with the spammer tag and move the conversation stage to archived.
If you are tagged on a conversation of which you are not the owner, let the owner know to respond. It is beneficial to retain the same point of contact for the duration of the conversation unless the owner refers some other user.
If the conversation has a customer org which is unidentified or is new, add yourself (the support agent) as the owner of the ticket. Try to find the appropriate owner for the customer org and update the customer record accordingly.
Change the stage of the conversation to hold if there are tickets linked. This means that support is asking for help from engineering.
Regularly follow up with the customer on any ticket in the awaiting customer stage. If no response is forthcoming in a reasonable amount of time as defined by your SLA, mark the ticket as resolved.
Critically assess the severity of the ticket according to the impact to the customer’s business. Blockers are those tickets which are critical to customer adoption or operations. Each account should have some balance of high, medium, and low severity issues.
If the customer states any new concerns or requests in the course of discussions on a ticket, open new tickets and create associations.
If the customer does not confirm the resolution, move the ticket back to in development and let the engineering/PM team know of the feedback.
Provide regular updates to customers on open/in-progress tickets. The proper update frequency is determined by the severity of the ticket.
Make sure all tickets have the customer org field populated.
Cancel any internal ticket without a customer org that has been created by a developer. Ask them to create an issue instead.
If a customer reports a concern that the documentation on the public site is incorrect, missing, or insufficient, open a ticket so that the part owner can update the documentation or route the report to someone who can.