Article • 4 min read
Innovate, explore and onboard with a sandbox
By Skip Moore, Senior manager, global development services
Last updated September 23, 2020
So, you want to change your workflow rules—specifically, where things are routed and who gets notified about new tickets. And in the first hour after deploy, you end up sending the CEO a thousand (1,000) notifications about tickets being assigned to them. At midnight.
Whoops. Should have used a sandbox.
Developers have been playing in sandboxes since the internet’s early-1970s toddlerhood. Then and now, these controlled computing environments allow developers to work privately, safe from real-world risks and ramifications. In light of the launch of Zendesk’s Premium Sandbox, here are three key ways in which using a sandbox can lead to a better product and more efficient agents.
Be creative without consequences
For developers and engineers, creativity means solving problems. A sandbox allows developers to play around — and make mistakes. Since this is not a production environment, they can train and practice, without fear of consequences. Creativity can flourish when you’re free to try out ideas and experiment, knowing there are no dangers or consequences.
A space like this is critical for innovation. Testing ideas live? Never the way to go. Agents would look at you and say, “I’ve got three-minute handle times. I can’t test this for you right now. I’ve got a backlog of tickets, and your app stinks, and we’re not going to use it.”
In a sandbox, so what if you accidentally send out a thousand emails? Since it’s to a test email, there won’t be a company all-hands to address the crisis, and your reputation with your customers won’t suffer.
Pretend to be your end user
A critical question is always: How does the end user experience this? How does the end user see things? If you don’t know, that’s a problem.
When you’re working with third-party integrations, you’ve got to sit there and do your best to engage with it as an agent would.
Set up a production environment and then use fake email address: The goal is to see the full flow of everything, to enable the agents themselves to run the full flow and see the results. You the developer must pretend to be an end user so the agents can then do the same, sending stuff into the Sandbox to see it how the end user sees it.
How do the end users get the emails? How is the email formatted? What data is being put in there? You’ve got a full 360-degree testing where you can be everybody in the chain.
Take notes. Watch where people look at things and see how they go through tickets. Pretend to be a customer, too. See how that interaction feels based on all that data.
The Sandbox allows you to be the end user to your own system.
Configure apps accurately — the first time
Chances are you’re familiar with this scenario: An app is released. Two weeks later, feedback rolls in: “Our agents hate this.” Turns out a bunch of managers and engineers got together and designed something that, say, prioritizes email in the layout. One big problem… The agents in question don’t want to see the customer’s email address. What they need to see first is the orders.
Inevitably, this is what happens when you don’t test applications in a sandbox.
People sometimes forget that the sandbox holds the data. If you’re building applications for your agents to use, it allows you to figure out how to lay things out in a way that works for the agent. Get the data the agent needs the most first. If the ticket’s about orders, show orders first. If the ticket’s about a refund, show the refund data first. Sandbox allows you to test some of these layouts. The agent can then come back, look at it, and go “No, that should be up here. That should be over here.”
When developers do the opposite and say, “I built this. Does it work for you?” the risk is huge. If an app doesn’t work for agents in production, they’re not going to play with it because they’re too busy actually trying to solve problems. With a sandbox, you’re allowed to take agents out for trial runs and watch them use an app.
The benefits of a sandbox boil down to this: an environment to train your agents and have app developers and third-party integrators test stuff. At the same time, your agents are also testing the UX design and trying to get that idea of how to make everything fly down the middle — and with the least amount of resistance.
