Since I started taking on the support tickets at HelpDocs, there’s been one thing that always stumps me.
Ok fine! There’s more than one thing.
But of the many parts of my day-to-day life that stump me most, knowing where to draw the line with things that aren’t “support expectations”—or even the best way to support a customer—is probably the one I struggle with the most.
Wait what? Draw the line? Surely you just “help”?
Let me clarify 😉
I’m guilty of making support a crutch instead of a safety net.
You see, going above and beyond is ingrained in our culture.
It’s in our blood.
We don’t just tick the boxes when a user is stuck or if something breaks. More often than not, we’ll struggle through with a customer to make sure they’re succeeding.
To remove as many hurdles as we possibly can as they use our software.
And it doesn’t matter what it is.
It could be helping with custom code, testing third-party integrations that aren’t technically supported, debugging crappy markup that’s copied over from Google Docs or Word other text editors.
Or it might be something as simple as shipping bug fixes within a day—In fact the majority of fixes ship within a few hours. It’s a humblebrag, and I don’t really care! 💪
Point is, we have and will always go above and beyond to deliver an assist that leaves the best possible impression of HelpDocs and the team.
Because an assist that helps our customers succeed by proxy helps their customers succeed too.
Everyone’s a winner.
But there comes a time when there’s a necessary limit. The point where going above and beyond expectations becomes an expectation.
And my problem is knowing where that limit actually is. 🙈
Help Customers Help Themselves
I’ve always been the kinda person who wants to help.
As kids, we were brought up to do our bit without expectation. We were taught that nothing was too much trouble. And that there was real value in helping someone who needed help.
No matter what they needed.
That’s something I’ve always carried with me. Being a default autodidact. It doesn’t matter what it is. I’ll try and find a way to help. And if I don’t know how to help right away, I learn how.
I guess I’d be the “Helper” archetype. The D&D Cleric. Someone invested in helping others succeed. Guiding them in some way to get whatever they need, or wherever they’re going.
And in my defence, this mentality has served me well. I mean hell, I’ve built a stable career out of it in one way or another. 🙃
But it’s also my weakness. Because I don’t know when to say no 😬
So when faced with support ticket after support ticket requesting help with custom code, I found myself overwhelmed.
The trouble is it’s always been a HelpDocs thing, despite not really being our thing at all!
When I first started tackling tickets, Jake warned they’d almost always offered up free custom code when asked. But it was always delivered with the proviso that we don’t offer help with customisation. 🤷♂️
But Jake’s the CEO. Jake knows the ins and outs of the codebase and built HelpDocs with their bare hands. Jake can do that kinda thing.
I, on the other hand, am not, don’t, did not, and can’t! 🙈 Not least because of my ability as a non-developer. But also because it’s not something we can really offer at the scale we’ve now reached.
On Becoming a Broken Crutch
It’s usually not extensive customisations.
How do I change this colour?
Can I hide this part of the template?
What if I wanna change these icons to something else?
They’re relatively easy tickets to deal with. But therein lies the problem.
A few quick Just add the color to your custom CSS or tiny _Sure! Try display:none !important;_ add up to a massive time suck and a precedent for more.
Even with a caveat that it’s a one-off and I’m not a developer just dropping the custom code opens the floodgates.
It sets me us up to provide custom help now and again. And “now and again” usually equates to “every time”.
Don’t get me wrong. It’s been a pretty awesome learning curve for me. 🙃
It’s forced me to learn the ins and outs of our templates.
To understand where the breakpoints are with our software, and what can be easily manipulated by our customers.
It’s also highlighted some areas that we could focus on as a team. Things we could build. Tweaks and improvements we could make that’d take minutes but save our customers hours.
Helping people figure out new ways to use HelpDocs is hugely valuable for everyone. And I love doing it! Because I love being helpful. 🙂
But there comes the point where being helpful becomes unhelpful. Because while I’m learning the ins and outs of our templates, the customer isn’t.
Yes, it might be a quick fix for me to offer up a code snippet and send the customer on their merry way.
And yes! It feels good to help out like that. Really bloody good in fact.
But doing it too much leads to a scenario where support becomes a crutch.
Where instead of customers looking for help or a little guidance from their teams of developers, they go straight to our support queue first.
And that changes everything.
Teach a Fish to Fish…or Something
If I had to draw a moral from this reflective rambling, I guess it would be something to do with teaching being more critical than hand-holding.
The old cliché about giving a fish versus teaching someone to fish.
It’s a weak point to bang on about. And one that I probably need to remember more often.
I think my problem is I like being the crutch because I care.
But perhaps support isn’t about being the crutch. Perhaps great support guides users instead of just fixing things for them.
Maybe I’m a little biased as a Customer Education Lead. But I’m starting to think the best way to set users up for long-term success is to teach them how to be successful. Whatever that looks like!