Behavior of 'on-hold' in Zendesk and associated Handbook guidance
Problem Statement
What is the problem?
On-hold in Zendesk previously allows support engineers to put the ticket back on hold when the four days expired. It now requires a response back to the customer.
While the handbook states
After four days the ticket will move back to open status, requiring an update to the user.
in practice, Zendesk wasn't enforcing this, and so we were able to use on-hold
to achieve certain other goals.
Why is this a problem?
Customers are aware there's an on-hold status, even if it isn't visible to them. We have to send an update to the customer to put it on hold and stop the clock, so we often say "I'll put the ticket on hold while I investigate this" or similar.
Customers have therefore learned that there are benefits to on-hold
Zendesk doesn't nag them for progress on the ticket.
email is hardly used across a lot of GitLab teams.
But, like a lot of our customers, at my last four employers, email was key to workflow and communication, and fighting to keep my inbox manageable was a major problem.
If we can share the email nirvana we now work in via the the gift of a little less spam to our customers, why not?
The ticket stays open
We use Zendesk day in, day out, and have a sophisticated interface to view and search tickets. The customer UX isn't the same, and customers often feel that if a ticket is closed, it's gone. It's not on anyone's radar.
So, for a number of reasons, they often ask us to keep the ticket open. I will provide examples in comments of customers who wanted to return to the tickets after that xmas/new year holiday.
Being able to just pop the ticket on hold and/or promise to follow up with customer when they were back in the office was a trivial and easy way to provide a great experience.
Proposal
Allow support engineers to use 'on hold' as a tool.
We've been leveraging a 'bug' in the workflow logic to achieve a goal we've shared with the customer: to set aside the ticket until a future date, not an arbitrary time (four days) in the future.
If it's a fixed timeframe, then actually, a calendar week would be more useful. Customer says "We want to see if this workaround is effective, please can we keep the ticket open until we're sure?", responding "Yes: we'll put the ticket on hold for a week and check in then." incorporates a sensible time frame. We couldn't do that before.
But, better would be the ability to state and choose an arbitrary time period.
Customer says 'I'm out of the office now until 18th January, but it's my top priority to test your workaround when I return. Please can you keep the ticket open until then.'
A good customer experience is to agree with what they've asked. It's not unreasonable. We are encouraged at GitLab to take time off, why shouldn't we support our customers in doing the same?
We respond: 'Sure - I'll put the ticket on hold until 20th January so you can clear down your inbox! We'll be in touch to see how you're getting on with the testing.'
It'd be more efficient if we could then get Zendesk to watch the clock for us, and then we've got a clear next step when it reverts to open
.
DRI
PERSON will act as the DRI for this issue.
/assign PERSON