Zendesk on Zendesk is a day-long discussion about a specific topic and how Zendesk Support uses Zendesk. Each session is hosted by a member of our Support team.

This session is about how Zendesk Support rolled out Voice. It covers:

• Update: Incorporating new Advanced Voice features
• Planning, including failover scenarios and tools to implement
• Testing, including testing your network bandwidth for VoIP telephony
• Rollout, including building heat maps to understand call arrival patterns

This session is hosted by Anna Rozentale, a Support Operations manager in our Dublin office. Anna comes from a solid multi-lingual, multi-channel support background, and endeavours to provide Zendesk's own Customer Advocacy team with the necessary tools, knowledge, training and best practices to excel at customer support and love their work at Zendesk.

See all the Zendesk on Zendesk discussions.

Introduction

At Zendesk, we like to use our own product as much as possible; or, as some may say, drink our own champagne (we prefer not to use dog food analogies in this company). There are many benefits to doing so, including cost-effectiveness, keeping our data to ourselves and seamless integration.

But more importantly, using our own product allows us to be the first to test new features as they’re released. Then we can provide valuable feedback to the developer team, as well as spot any arising issues without waiting for customer reports to come in. So it goes without saying that when it comes to phone support, Zendesk’s own customer advocate team uses Zendesk Voice.

The objective of this post is to tell the story of how we rolled out Voice for Zendesk Support.

Note that this session assumes the reader is familiar with the functionality of Zendesk Voice. This article will provide best practices for rolling out and using Voice for large-scale, multilingual, and global customer support.

Update 12/14: Incorporating new Advanced Voice features

In addition to the information already outlined in this article, we wanted to provide an update to it and outline some of the work we’ve done in relation to implementing Advanced Voice features internally at Zendesk Support. Since Advanced Voice features are already available to purchase to all of our customers, we’re hoping this will be useful to you when considering or rolling these out.

Warm transfer

Call transfer was the first Advanced Voice feature that we started using internally at Zendesk; it’s been available to us as a standalone beta feature some time before it was announced as part of Advanced Voice package. Conveniently, it became available to us at the time when we were rolling out Zendesk Voice for support initially, so we were immediately able to train Zendesk Customer Advocates on the feature and how to use it.

Despite having early access to the feature, we haven’t found a strong use case for it yet as we’ve only been using Voice for one of our departments - Support. Warm Transfers often come in useful when a customer requires to speak to a specific advocate on the phone (which wouldn’t happen often as all our advocates are well trained in all aspects of the product).

However, we found a need to transfer some calls from Support to Sales team in one of our multi-lingual support offices. Therefore, we’ve trained specific Sales Reps to use voice so language-specific calls can be transferred and this facilitated a smooth, customer-friendly way to route customer calls to the department or agent best equipped to help them.

Beyond training, warm transfers require no set up but we found it’s extremely helpful to give brief training and especially do some roleplay before using Warm Transfers in practice. Ultimately, call transfer can be extremely beneficial if your organisation is using Voice to enable your customers to reach several departments - despite the option to route customers to the right group is now available using our IVR, you’d be surprised how many might still end up not in the right place!

For more details, see Transferring a call.

IVR

IVR was a much-expected functionality native to Zendesk Voice. Prior to the beta, we have been using an external system for our phone tree that would then forward to our Zendesk Voice numbers. This was resulting in extra complexity, as well as extra cost. As IVR became available to us, I worked to port our main Voice numbers to Twilio (our Voice service partner) and have the main IVR operational out of our Zendesk instance.

While native IVR helped alleviate some of the complexity, we haven’t been able to move off the 3rd party system just yet. There’s a couple of reasons for that.

First, as previously mentioned, only our Support team currently use Zendesk Voice. Our Sales team, who are also taking inbound calls, have not transitioned to Voice yet and it is, therefore, necessary for the IVR to forward back out of Zendesk when the caller selects the option for Sales. Fortunately, this is really easily done using IVR in Voice as the IVR offers the ability to forward to voicemail, a group, a number or another IVR menu level.

Our second use case for it is failover, which we’ll discuss in a little more detail below.

If you don’t yet have a set workflow for where your calls are routed, the most efficient setup would be to route to one group. In the event that you need multiple groups associated with an IVR option, the workaround would be to route to a number from IVR and associate that number with multiple groups. However, using that workaround leads to incurring extra costs as Voice will essentially be making two calls - that will also reflect accordingly in the Call History panel.

Generally, having an IVR enables your customer service team to increase efficiency, as well as improve customer satisfaction and agent happiness as it can help filter out calls that the team are unable to help with. Be careful when recording your main IVR message - make sure you come across as friendly but stay clear. Don’t use internal terminology - instead of “risk operations” it might be better to say “our finance and billing department”. This will help you get your customers to the right place faster.

For more details, see Routing calls with IVR.

Failover

Once failover is switched on, it’s really easy to use - the only thing that’s necessary to configure is a failover number.


Of course, you’d like your failover number to be external to Voice as this will activate when Voice or Zendesk aren’t operational.

In our case, this was easy as we had a fully configured external solution that we used previously. That way, we can easily redirect calls to an alternative number that mirrors our Voice set up exactly. This is not the most cost-effective solution; however, it does allow to provide a full, uninterrupted service in cases of outage. Other workarounds may include a single phone number on an alternative service, which would connect to a recorded greeting informing customers that your phone service is currently unavailable and offering other contact avenues.

For more details, see Adding a failover number.

Part 1: Planning

Before launching Voice for Zendesk Customer Advocacy, we were using a system called IfByPhone. This system was used for creating schedules for agents who are designated to take calls for specific phone lines. Support agents had to login to IfByPhone to become available on the call distributor, which would then route calls to each agent’s Skype number, and the call would ultimately be taken via Skype.

After the call, the agent would go into Zendesk and log a ticket to track the call, or to continue communicating with the customer if follow-up was necessary.

In essence, we were using three different systems to perform an essential function of a support organization. Moreover, a support agent had to be logged in to all three systems to take a phone call and log it.

With Voice, we wanted to move away from this complicated model to a more streamlined setup that allowed us to use two systems (which will very soon be just one: Zendesk) and required agents to be logged into only one (just their Zendesk interface).

Thus, the task at hand meant redesigning our telephony infrastructure as well as changing behavior that support agents were used to.

Planning your failover scenario

Software and systems are prone to errors and outages, no matter how well-designed they are. Zendesk Voice brought us many benefits but also one concern we had to plan for: if our system goes down, how do we ensure customers are still able to get support over their preferred channel?

I cannot stress enough how important it is for each company striving to provide consistent multi-channel support to have a failover scenario. Each support organization has different needs, and there won’t be a one-size-fits-all solution, but it helps to look at what other systems you’re using to facilitate any other internal workflows and leverage those. Are you using Google for Work for your email and calendar provision? Try setting up Google Talk to act as your backup solution. Using Skype? Another solution for your IVR? Consider those.

Make sure that all emergency processes are documented as thoroughly as any other workflows for your Support team. Especially if your support organization is global, you should aim to have at least 2 POCs in each region who know how, and have access to the tools needed, to switch to your emergency failover scenario.

Planning your workflows

Naturally, if you’ve already provided phone support before, you’d want your Zendesk Voice to be set up to mirror existing workflows. You may need to create new groups for your agents if you’ve got a dedicated pool of phone support agents that did not have a group in Zendesk before.

For us internally, this part of planning and setting up was quite easy - our Tier 1 support group are our first point of contact for customer, and therefore we had no doubts they’d have the necessary skills to field phone calls. We also had groups already set up for the different foreign languages we support.

In planning which staff will be taking phone calls, be sure to also check what role they’re in and whether their role has the necessary permissions to take phone calls. We found out quite close to launch that most of our Customer Advocates did not have this enabled for their role!

Agent role settings in Zendesk

It’s also important to plan handling out-of-hours support for callers. Even if you are a 24/7 business, you may have callers opting to leave voicemails when the wait time on your phone lines is longer than they’d like. Consider if you’d like to provide customers with that option. If not, you can re-record the greeting or switch off the “Voicemail” greeting.

At Zendesk, we use the default Zendesk Voice greetings which prompt the caller to wait while we look for an available agent or press 1 to leave a voicemail.

To handle voicemail tickets, we built a trigger that then bumps the priority of a voicemail ticket to High so that our support team can pick it up and arrange a callback as soon as possible. Other than this, we do not have separate workflows (views or dedicated agents) for handling voicemails but should your organization require them, they’re extremely easy to implement using business rules.

Part 2: Testing your setup

In general, the key to getting launches or rollouts right is meticulous planning. The key to getting new tool rollouts right, however, is meticulous testing . Once you have it all planned out and documented, testing is the next important step in the process.

With Zendesk Voice, there were two sorts of testing that we needed to complete with Zendesk Voice to be sure it would work to our standard: network and workflows.

Testing your network

If you haven’t used VoIP for your telephony provision before, the first step is configuring and testing your network. We used Skype prior so we were relatively confident that our network could handle the traffic.

You need to open specific ports for Zendesk Voice to best ensure that the data you are sending from your network during a phone call will reach the recipient on the other end. Zendesk Voice passes traffic using a protocol known as UDP. By default, many routers block this traffic in an effort to protect your computer, so these ports must be opened.

Further information about opening ports can be found in our Help Center:

• Configuration instructions to open the correct UDP port range
• Video tutorials on opening up your computer ports

Once you have confirmed that the full range of ports are open, proceed to test network capacity and speed using an external tool. We use Speedsight , but there are other online tools available, some of them free.

It’s important that the testing tools you use offer an option to select the number of users who will be simultaneously taking phone calls: the more calls your agents take at a given time, the more bandwidth your network will need, and the tests need to reflect that.

Example of a network test using Speedsight

There are two main metrics offered by most speed tests that will determine how suitable your network is to handle VoIP calls:

• Packet loss is measured in percentage and should be as close to 0 as possible.
• Jitter is measured in milliseconds and should also be as close to zero as possible.

The further these metrics are from the ideal, the more your audio quality is likely to be affected by your network issues.

For network testing and opening ports, make sure you partner up with your IT point of contact - they are an important stakeholder whenever rolling out new systems is concerned!

Testing your call workflow

When you have enough confidence in your network bandwidth, set up some test numbers in Voice. We had one number created and, at first, it was associated with a test group containing only the project team in charge of the Voice transition (later on, we added agents to the group).

The test group's objective was to understand whether routing would work correctly. If you’re using an external IVR system, find out how it integrates with Voice, and set up your IVR to have a hidden menu item so you can test the full call cycle. Our IVR is currently hosted in IfByPhone, which forwards to a Voice phone number (provided by Twilio) depending on the menu item selected in the IVR.

Be sure to observe the following:

• How long does it take to get through?
• Are any inconsistencies or delays in the flow?
• Is the resulting ticket in Zendesk assigned to the right group?

Also, try testing from different numbers - ideally from different countries - such as Skype numbers, mobile numbers, landlines. If your phone workflow includes making outbound calls, test that thoroughly, too, by making calls to a diverse set of numbers.

During the testing phase, we found, for example, that some of our agent roles did not allow them to take phone calls, and that most were unaware they could select a phone line to call from when making outbound calls. As a result of these findings, we created additional workflows and expanded the training material that was initially prepared.

When you’ve completed the bulk of phone line testing, add some experienced agents to the test group so that they can take the first practice calls using Zendesk Voice.

Testing with real calls

If your setup allows for it, try to create a “halfway point” before fully going live: make a portion of live customer calls go through Voice (again, routed to your support staff who are already familiar with Voice), while all other calls get routed through whichever other system you are using.

We did this at Zendesk to ensure certainty in launch readiness and to highlight gaps in process documentation, which were filled promptly before go-live.

For an inside view of some of the auxiliary processes and best practices that were not obvious to us at the planning stage, take a look at these Zendesk Voice tips .

Part 3: Rollout and beyond

Setting up Zendesk Voice is extremely easy; therefore, the bulk of the work we needed to do to facilitate the transition was in advance of the rollout.

If you have mapped out the telephony infrastructure, ensured your network has bandwidth, and your agents are properly trained and aware of when the change will take place, making the switch will be quick and painless.

Agent training

Regarding training, we used existing training material, covering the basics of how Zendesk Voice works for agents, supplemented by clarifications, examples, and our learnings from the testing phase.

It’s a good idea to document any workflows before running the training so that you’re able to easily explain and point your agents to the right resource. It’s also advisable to plan training sessions ahead of time, so that unforeseen questions raised by agents can be discussed and signed off as a procedure where needed.

As Zendesk’s support organisation spans 6 offices around the globe, we coordinated the training to be delivered by our Voice “product champions” - that’s what we call experts on a particular product area - as there’s one in every region and they’re very knowledgeable about using Voice. They did a brilliant job at training. And at earlier stages in the project, they also helped coordinate testing and advised on potential problems we could run into, based on their experience with our customers.

So definitely try to leverage the wealth of knowledge and experience your support agents have! You probably won’t have dedicated experts on Zendesk Voice on your team but perhaps there’s someone who previously worked with telephony systems or managed phone support you can look to.

Reporting and monitoring

An important consideration that we, perhaps, didn’t give enough attention to while planning the rollout was reporting. While Voice makes it easy to track calls coming in to your support line as tickets, you might need to do a little background work to establish robust reporting procedures and a seamless integration with any other analytics tools you might be using.

At Zendesk, we use a dashboard software to display support stats on TV screens in our offices around the globe using Ducksboard. It has many pre-built widgets that plug-in nicely into Zendesk to display important metrics.

However, there isn’t a ready-made widget to display Voice stats. We used a custom script to pull agent availability schedules and number of calls in queue. It’s also possible to build your own widgets based on any of the metrics available in Voice native reporting. Note that you need to be able to do this internally within your organization as this is not a service Zendesk provides.

Example of a support dashboard using Ducksboard

Reporting and call volume

A useful tip for reporting on your phone support: build a heat map using Insights.

We used the heat map functionality in advance of the rollout to understand call arrival patterns and be able to staff the phone lines at the busiest times, but it’s a good idea to use heat maps consistently as a visualisation of when you need more staff on the phones.

At Zendesk, we estimate that a Tier 1 advocate’s capacity is 4 calls per hour, with the average call lasting 8 minutes plus 2 minutes wrap up time. We added a buffer to allow our Customer Advocates to also work through tickets or any other actions necessary following a call.

With Voice, you can build a report like this easily using the a filter available to show only tickets created by the Voice channel (filter attribute should be ‘Ticket via’).

Remember that Zendesk admins can toggle agent availability state if you need to ensure adequate coverage during busy periods.

Heat map report for Zendesk call volume

Feedback and improvements

Beyond reporting, it was important for us to have a steady feedback stream so that we continue to improve the product.

To this end, the Voice team built a feedback app (it’s still in beta, so please contact us if you’d like to try it out!), that enables agents to rate a call and submit feedback on call quality, directly in Zendesk, right after a phone call.

The ratings and feedback verbatim is passed on to Twilio, our Voice service provider, who will use it to analyze reports of bad call quality, making the troubleshooting process faster and more efficient.

That's it!

The Voice product is rapidly developing - the developers are hard at work on new features and improvements, and hopefully we’ll be able to share exciting updates soon!

As with any changes in product, at times they warrant modifications to support workflows which need to be managed appropriately. It really helps to have a global POC and nominated backup POCs that can help understand how changes to the product should be dealt with, as well as troubleshoot and triage any questions/problems your support team is having with Voice. This could be a support operations person in your company, an IT staff or an experienced agent/team lead.

We hope this information is helpful to you if you’re thinking about building your phone support toolkit or if you’re already using Voice but not sure if you’re realizing its full potential.

For more tips on getting the most out of Voice, have a look at our Fine Tuning Phone Support session. Also, check out all of our Voice resources .