“Can I speak to a human being please?”: Spotlight on the DevResults Helpdesk
Helpdesks are fairly ubiquitous nowadays, but you may still wonder who is waiting on the other end of help@devresults.com to answer your questions. The current DevResults Helpdesk is the result of dozens of iterations, and it is still very much a constantly evolving work-in-progress. So what can it do for you?
Who staffs the support desk?
DevResults maintains an on-call team comprising one software developer and one data scientist at all times. It’s their job to field and resolve Helpdesk tickets, allowing the rest of the DevResults team to focus on new features and other projects. Engineers typically rotate every three weeks (the length of our development sprints) whereas the Data Team cycles out weekly, with liberal use of “tag-outs” as life or illness intervene.
In the early days, our Helpdesk was staffed by a single data scientist (sorry Leslie!) but that approach didn’t scale well. We added an engineer to the rotation to ensure that bugs and other technical issues got immediate attention without disrupting on-going feature development work. If there are no bugs to squash, that engineer has carte blanche to do so-called “grease work” — the odds-and-ends tasks that result in small quality-of-life changes for users but never rise to the level of a top priority.
DevResults has never hired specifically for a support or on-call role – it’s always been staffed by experienced, senior team members. There may be cheaper ways to respond to help tickets, but we find the regular cycle of user interaction to be beneficial and grounding for everyone; it forces us to get familiar with every corner of our platform and take note of how people are using it. If we get the same question two or three times, maybe we need to write a new article in our Knowledge Base. If we get the same question weekly, maybe we need to rethink how a page in the app is designed.
Rotating on-call duty is also an opportunity for us to go beyond the mechanics of the site and offer our clients advice on evaluation methodology, M&E strategy, and change management as our prior experience and expertise allow. We don’t offer any formal consulting, but we do what we can to make people’s lives easier when they ask for our opinion.
How to find us
Both the Helpdesk email — help@devresults.com — and the “Help” menu inside of DevResults go to our ticketing system. We encourage users to take advantage of the in-app “Contact help desk” wizard because it quietly reports a bunch of helpful information to us, like which browser you’re using or what page you were looking at when you contacted us.
There are lots of ticketing systems out there, but we like Freshdesk because it's easy to use and integrates with our company Slack #help channel. Most of our users prefer to use email for communicating with our Helpdesk, but Freshdesk does give users the option of tracking and responding to the ticket in Freshdesk itself if they prefer.
How to write better help tickets
Few topics arouse more passion from software professionals than the dos and don’ts of writing help tickets. We don’t expect anyone to follow our own internal rules for writing tickets, but it doesn’t hurt to know what information we require to track down a bug or register a feature suggestion. If you don’t tell us, we’ll just ask!
We have a simple template for (internally reported) bug reports:
- Steps to reproduce: how did you get to a bad place?
- What I expected to see: what should it have done?
- What I saw instead: what did it do?
Likewise, we have a slightly longer template for logging feature suggestions:
- Current functionality: what does it do or not do now?
- Use case, user story, or problem to solve: what do you need it to do instead?
- Proposed workflow or functionality: how do you suggest we solve the problem?
- Mockup: a simple sketch (Microsoft Paint works fine) of how and where?
The key with both bug reports and feature suggestions is to clearly define the problem to be solved, not necessarily the solution itself. The problem may seem obvious to you, but there are lots of reasons we need to know that context. Sometimes, there’s an alternative solution to the problem that may be non-intuitive but ultimately more elegant and robust for other users, including the ticket-writer. In other cases, there’s actually already a tool that addresses the issue, you may just not know about it yet.
Again, consider this as advice for getting the most out of your software and your vendors, not a requirement! It takes a bit of time to write a good help ticket, but in the end, your problem gets resolved faster with less back-and-forth if you invest the time upfront.
Setting up your own Helpdesk
The DevResults Helpdesk will always be a part of our service to clients, but many organizations — especially large ones — set up or already have in place their own ‘frontline’ internal help desk. We strongly encourage this practice.
We get a lot of help tickets that we can’t answer because they have to do with organizational policy or clients’ internal systems. Even when the question is specific to DevResults, we’re often unaware of the guidance or norms that have been established by site owners. And last but not least, there’s lots of stuff that even brand new site owners can answer, like how to reset a password.
For all these reasons and more, it’s in everyone’s interest to have an M&E or program help desk — nothing more than an email account shared by site owners — which can always elevate incoming, DevResults-specific tickets to us. Many of our clients who use these systems report that they are indispensable tools for program quality assurance!