Configuring your Zendesk Support to use a follow-the-sun model

If you've read our follow-the-sun blog post you're probably ready to look a little more specifically at what you can do in Zendesk Support and with your workflows to build your version of follow-the-sun support. If that's the case you're in the right spot!

Here we'll take a look at some areas to consider when implementing a follow-the-sun support model, go over Zendesk Support's process, and finally we have a real world example of a customer's question about his particular setup and our recommendations.

Using Zendesk Support features to follow-the-sun

Channels
When setting up for follow-the-sun support it’s important to consider how your customers are going to reach you. If you know how they want to get in touch, you can make sure you have the right options in place.

• Are all of the channels where you provide support going to be available at the same time? All of the time?
• Are your customers concentrated in particular regions? Are they from specific companies? Are they members of different plan types (i.e. premium accounts, free accounts)?
• How do customers contact you? Are most customers used to sending emails? Do customers prefer going to the web portal?

Sometimes there are unexpected benefits for offering a variety of options, maybe even at different times than normal. For example, some of our customers like that teams in other locations are available by phone outside their regular business hours because they appreciate the flexibility to call after their workday and talk when they’re free of interruptions.

Knowledge Base
This is a great resource for follow-the-sun support teams because it’s available 100% of the time. Customers can not only potentially find the answer they need right away, but you can learn a lot about what your customers are looking for by keeping an eye on search data and noticing if questions are submitted more often from certain pages.

• If your customers span the globe, it’s important to provide support in multiple languages so that everyone is able to get the information they’re looking for.
• Look at implementing a Community Moderator program. These power users might be in locations or have additional language skills that can complement your team. They can also help engage customers and build a robust and talkative community.
• Have agents subscribe to certain sections of your KB. If they see a question soon after it’s posted and answer it, they can help more people at once with that public answer.

Organizations
It can be much easier to build rules and routing based on groups of similar customers rather than handling each customer separately. Organizations don’t have to only include people from the same company. Think about how you help your customers. Are you an IT help desk? Maybe you can organize customers into cities, or buildings, for example. If you’re visiting someone in one place it makes sense to help people who are close by at the same time.

If you want to add another layer to the structure you might consider putting everyone from the same company in the same organization and then adding user tags to particular members of the organization - maybe that's how the building or city information becomes part of their record. Views can then be built on either property - organization or tag.

Groups
Groups provide a way to sort agents into responsive teams. You might consider grouping agents by team (Level 1), region (US), or both (Level 1-US) to help match them up with customers. Agents can also be assigned to a specific organization so that they see tickets from that set of customers quickly.

• What are the relationships between your agents and your customers? Who talks to who? Are there agents who only work with a certain subset of your customers?
• If there are times of the day when you have a light staff consider adding business hours, and then you can use them as a condition for notifying groups of agents when customers contact you outside of your main availablity.

Triggers & Automations
Triggers and automations are both great ways to build automatic actions into your process and thereby reduce the number of manual actions required to keep tickets moving.

• Tagging organizations or users means that any ticket those users create will have those tags. Tags can then be used in triggers to assign tickets to the right group of agents, increase priority, inform agents when tickets haven't been answered etc.

Views
Think of views like real-time reporting. If you need to have a current, up-to-the-moment list of a certain set of tickets then views are the way to go.

• If your agents are all working from the same set of tickets then it would make sense to have views reflect the entire pool of tickets rather than separating them by region or language.
• Or, group your views so that agents can focus on the tickets that are unique to their region.
• It may also make sense to have views related to some of your highest priority customers or certain high volume organizations.

Macros
One great thing about macros is that they provide consistency while giving you room to customize what’s being added to or changed on the ticket. They are particularly useful for escalating from one group to another because they can provide a template of what information needs to be filled out while correctly applying tags, filling out custom fields, and changing the group the ticket is assigned to.

• How do tickets move through your Zendesk Support instance? Are there escalation paths that can be smoothed out by asking the transferring agent for information up front with a private comment in a macro?

How Zendesk uses follows the sun in Zendesk Support

Tickets
At Zendesk, the focus is on maintaining agent accountability. Once a ticket comes in and is picked up by an agent, it generally stays with that agent unless another group’s expertise is needed.

Here’s a more in-depth look at how support requests filter through our five offices spread across three continents:

• All tickets that land in support.zendesk.com are sorted and routed to the appropriate groups (Support, Sales, Finance etc.) by triggers.
• All tickets routed to the main group land in the “Triage” queue.
• A more experienced team member is assigned to watch the triage queue at all times and assign tickets to the Support group that's most likely going to be able to resolve the issue. (Our agents are divided into three levels of technical expertise and corresponding groups).
• Tickets that come in without enough information to understand the issue often get the "pending unassigned" treatment: we ask for more information (with a macro) and leave it unassigned in the Product Support queue until the customer responds. This is a quick way to get in touch without spending too much time on a ticket that doesn't have enough information to be answered.
• For tickets that arrive in languages other than English we have macros written to route tickets to the appropriate language specific queue with details letting the customer know they'll receive help soon. This happens at the triage step before the ticket is assigned to a specific group.
• For voicemails that we can clearly identify as coming from a different region (sometimes people call in at 11pm and all available agents are on the phone!) we rename the subject with the region and leave it in the Unassigned voicemail queue until the appropriate team is available to call back during normal business hours. (Nobody likes being woken up at 5am to talk about triggers.)
• If a ticket needs to be escalated to a more advanced group of agents (or outside the Support group) we use a macro that has prompts for the information required by the next team in a private comment. Tags and custom fields are automatically filled out. These prompts are also helpful for the next team because they know exactly what information they are looking at when they open the ticket.

While we don't do daily handoffs, sometimes, if it's apparent an issue requires or will require a lot of back and forth or a phone call, we will re-assign a ticket to cut down on response delays. Those tickets are usually sent to the appropriate regional manager or team lead.

Views
In addition to the standard “My working tickets” view, and views for the main group each agent belongs to, we have a view for problem tickets that have been escalated to Dev sorted by topic so that every Advocate can see them quickly. Social media tickets fall into a separate view until assigned and tickets in languages other than English are listed in their own views which are only visible to the agents with that language expertise.

A customer example

By now you’re probably thinking about your own setup and goals, and you may want to see how some of the features and considerations above lead to actual settings and processes in Zendesk Support. Check out this example of a customer’s questions (posted in our forums) and my suggestions.

Question/Goal
We created separate groups for the three shifts of agents we have, but we can't create automations to move tickets from one group to another without a manual step. Our intent is to implement a "follow-up" checkbox which, when checked at the end of a shift, will cause a ticket to move automatically to the next group to be picked up and assigned.

Recommendations
For this situation I would suggest using triggers rather than automations (because triggers are event based) to move the tickets. Here's how this could be done

• Create 3 checkboxes, similar to “Move to region 1,” “Move to region 2,” and “Move to region 3” but with names that work for your teams. Keep these visible to just agents.
• Create 3 triggers, one for each region (make one, and then you can clone the other two and just change what needs to be different). The title could be similar to "Move remaining tickets from Region 1 to Region 2." The condition for the triggers would look for one of the checkboxes to be marked ("Move to region 2"). The action would then be that it reassigns to that group and unmarks the checkbox.
• Workflow: At the end of the shift for Region 1 have someone responsible for, or remind each agent to, bulk update remaining tickets with the checkbox for the next region. Once they do that, the appropriate trigger will fire and reassign the tickets to the next group.

It's not a fully automated process but it will help you move tickets around more systematically. It would also work in cases where you have to skip a region for a day (if that team is on holiday).

Another way of doing this would be to have one overall group per level (“Support Level 1”) and one queue for Level 1 tickets that agents from all regions can see. If agents leave at the end of their shift and feel tickets they had been assigned or worked on might need follow-up before they come back the next day, they could apply an "unassign_me" tag. (Assigning a ticket back to the same group an agent is in can't be done manually.) That tag would then get picked up by a trigger that assigns the ticket back to the main group (maybe it now falls into a “Pending unassigned tickets” view) where other agents will see it. If it is updated by the customer, then the status changes to open and it moves back to the main new tickets queue for Support Level 1.

Another option is to use the API and write a script that does the movement for you. This would let you factor in time much more than is possible through the UI.

Note: Thanks to Matt Picio for asking this question in the companion piece to our first Follow-the-sun blog post.