As an start-up enterprise software company, we work very hard to cultivate and nurture long-term relationships with our client organizations. Support data is presented at every QBR and it is very important to demonstrate our commitment to the success of those organizations' end users in social media.
We make ourselves available (by way of Zendesk) in phone (Zendesk Chat), email, social media and api-enabled channels. Of course, to scale our support program and to help our end users achieve success with our platform, we also invest in self-service solutions. Striking an appropriate balance between contact center availability and the promotion of self-help opportunities is a real challenge.
Our self-service channels include the Zendesk Help Center (see screenshot), a Facebook Business Page, a Twitter account, a Google Plus account, customer support FAQ pages on our corporate domain, training materials and regular emails to our user base containing paths to self-service content.
Whenever we or a social media service experiences a service disruption, we utilize each of these channels, as appropriate, to let our customers know. We use an announcement banner like this one.
We also quickly create macros to make our messaging consistent and to prevent an inundation of tickets which could easily overwhelm our contact center.
Our self-service content includes knowledge articles in the Help Center (including screenshots), product and social media video tutorials produced by our communications team, custom product wizards (decision tree applications) and videos created with Screenr in the Zendesk knowledge base. Links to this content are also distributed via macro within tickets.
Incoming Requests and Routing
Customer requests via email, api source, phone and social channels all come in to the general customer support queue (Zendesk View) and are routed to the appropriate staff member via Zendesk Trigger based on their affiliation with the customer's organization or their subject matter expertise.
The attached redacted screenshot depicts a trigger where one agent is assigned to tickets belonging to certain organizations, and to other tickets which may be in German. You can see that we try a key word match (based on a bit of case mining and Google Analytics data) to detect this where the ticket submitter is not already an established user in our system.
For instance, tickets which contain words related to billing questions are routed to a staff member who specializes in those question. Tickets originating from Acme Corp (for example) are assigned to the representative who has the greatest amount of expertise in that organization's use case and idiosyncrasies. We use Zendesk's organization domain identifier to route tickets by organization. Tickets originating from social media channels are assigned to specially trained team members who can meet the different SLAs for those channels.
We are able to route approximately 90% of all incoming requests in this manner. Sometimes, a customer will send us an email with no content and a vague subject line, such as "help" and the email domain is not one that we recognize. In those cases, the on-duty queue manager will manually assign the ticket the the correct inpidual or Zendesk Group. CS Representatives are also encouraged to look at the general queue from time to time to self-assign any yet unassigned tickets.
General How-To questions and common technical questions typically receive a customized macro response. Each team member slightly modifies the macro to reflect an understanding of the customer's specific scenario as well as to provide customized tips to match that scenario. The macro is basically used as a template rather than an auto-response.
When we run across an issue which cannot be addressed in this manner (possible product defect) we may ask the customer for more information, such as computing environment details, screenshots or Screenr video. We then attempt to reproduce the issue within the application ourselves. If we are able to reproduce the issue, we may be able to resolve it ourselves through configuration. If re-configuration is not possible or warranted in that instance, we escalate to an account manager for non-technical issues, or to our Engineering team for deeper technical investigation.
Please note, however, that we always respond to the customer first, before escalating, before entering private notes, and before consulting another team. A quick and thoughtful human response is our most important KPI and tends to be the leading indicator of our CSAT.
Handle Time Optimization
Our team uses a lot of custom fields which help us to keep better records and to troubleshoot more effectively. To decrease handle time, we try to auto-populate/select each ticket field base on API-data, the customer's comment text (via Trigger), their organization data, and macros. Ideally, the agent reads the customer question, applies the appropriate macro, makes a few small edits, then commits the changes without having to populate/toggle any other ticket fields.
Tickets that must be escalated have a macro applied to them containing an escalation template (see attached screenshot) and triggers to assign the ticket to the Account Management or Engineering Groups within Zendesk. The template includes questions such as: user ID, URL of page where issue was discovered, related Zendesk ticket number, screenshot/video of the error, steps to reproduce the error, and some other custom IDs associated with our product.
Once in the Engineering queue, our on-call Engineering team self-assigns tickets based on their particular product expertise. They remain responsible for that ticket until it is fully resolved, even after their on-call rotation ends. Designated on-call Engineers actually sit with Customer Support Agents so they can answer questions in person during their 1 week shift, as needed. Once they have identified the root cause, they create a ticket in their team's ticketing system and note the URL of the ticket in the Zendesk private note.
The agent may also use the Zendesk Linked Ticket app to make this connection. They indicate an ETA for deploy and then reassign to Customer Support so we can message the customer appropriately. To make sure nothing gets lost in the shuffle, we have a variety of Automations plus the SLA targets in Zendesk to let the responsible CS team member and managers know if a ticket is languishing.
Once we are notified by Engineering that an issue has been resolved and deployed, we test the solution ourselves (whenever possible) and let the customer know that it should now be functioning as expected. We offer the customer the chance to rate the interaction via Zendesk survey 24 hours after the ticket has been marked as solved.
If we need to get confirmation from the customer that the product is working as expected following the deploy, we mark as Pending. If the customer doesn't respond within 24 hours, we send a reminder (see redacted screenshot).
If they still do not respond within another 24 hours, we mark as Solved through a Zendesk Automation. If the resolution from Engineering resulted in new information for the Support team, it is the assigned representative's responsibility to add the new information to our knowledge base and internal training site, including relevant screenshots and videos.
Different ticket metrics are monitored, daily, weekly, monthly, quarterly and annually to assess and enable us to act upon trends. We use Zendesk's standard Analytics, plus Insights . We also use GoodData natively, as well as Google Analytics, CrazyEgg, MixPanel, Salesforce, and ClickTale for more in depth analytics on customer usage of our self-service solutions and ticket forms.
Metrics include (but are not limited to):
- Response and Resolution time
- Month-over-month contact rate among all users and active users by organization (B2B)
- % of users who submit multiple tickets
- % of tickets by contact channel
- Categories and organizations with highest and lowest CSAT
- Top ticket categories by volume and resolution time
- Escalation rate by category and organization
- Self-service metrics (forum views, wizard views, searches, social media self-help, etc.)
- Root cause analysis (pie chart) for top 3 ticket categories (we usually look at 200 tickets from the previous month in each category)
I hope this is helpful!
Cette publication n’accepte pas de commentaire.