You can read the original blog post here: https://www.nicereply.com/blog/control-quotient/
I wrote a blog for Freshdesk based on my experience of Onboarding a remote colleague in Support.
You can read the original blog here: https://blog.freshdesk.com/onboarding-remote-support-agents/
I’m going to summarise my talk at the SD Expo 2018 in this blog. The purpose was to share different ways in which Support can help the Engineering team in being more efficient and effective. (I’ve also attached the Slides at the end.) #supportforengineering.
I’m pretty sure at one point or another you would have heard your engineering team complain that X, Y, and Z information is missing from the JIRA ticket. Or, the fact that Support tries to get almost every bug prioritised as an important one. All these things lead to frustration and lack of productivity because you’re chasing each other for information and prioritisation.
I’m going to talk about some of the things which can help both the teams in terms of productivity and getting things done asap.
Make use of API responses:
We’ve learnt over time that it helps engineers to understand the problem quickly and easily if you add the API response when logging an issue.
Its simple: Right Click -> Inspect Element -> Network tab: Click on the API response to see the details (as shown in the example image below.
Log bugs with all the required details:
Its always a plus point to have a sample bug or feature request template but even if you don’t want to force your support team to use one, they should still cover all the handy information in it.
It should include but not limited to:
All these details in the ticket means you can avoid a lot back and forth communication for requesting details, not only between Support and Engineering but also between Support and the Customer.
Pro-Tip: Try to add some emojis and humour to the Jira tickets. It can have psychological impact 😉
Having a dedicated Bug Basher to prioritise bugs:
Well, yes, everyone’s reported bug is important to be fixed. But the next question is which one is more important among all the important ones. Having a dedicated bug basher means this gets prioritised (based on your selected metrix) , chased and done in a timely manner.
This will also ensure that the bugs get triaged before reaching the engineering team. I’m sure that you will agree that sometimes there are chances that the bug marked is not actually a bug.
Handling such exceptional cases at a triage stage can not only help you save your engineers’ time but it can also help you highlight where you need to train your team on….which brings us to the next point.
Develop in-depth product knowledge:
Along with general product training it’s also important that your support team is kept up to date with all the changes happening with regards to your product, be it rolling out new feature or a bug fix.
You need to ensure that your support team is the first to use any new product change that is going to be rolled out to the customers. This will not only help you with QA’ing but will also ensure that your Support team is able to answer any questions related to the change and can handle it independently.
Have Engineering<> Support meeting once a month:
This can help you bring more collaboration between both the teams. You can use this discuss things which can allow both the teams to compliment each others’ work. This is because you will get to hear from someone else’s perspective on how your work is impacting theirs and from there you can work on making things better.
In addition to all this it’s important to have brainstorming sessions with them. It will help you understand their way of thinking and working. Go for it even it means arranging them on your own.
While these things can make your Engineering team more productive, this also means better turnaround time for your customers which is a win-win for everyone involved.
Link to Slides: SD Expo
I’ve always wanted to have a website listing all my work. This has been a dream since the days when I hadn’t even written any blogs or attended conferences. Then came a point when I thought that I’ve got enough stuff hosted at different places and its about time that I put it all together. But I still didn’t cross the finishing line to get started. And, finally one day I signed up for a domain name and a WordPress account to get started…..because when you start paying for a subscription you start making time to put things together.
After giving it a lot of thought I decided that it’s best to link all my existing work as it is and use this to be the place for writing new stuff going forward. So, here we go with the list of blogs that I’ve written so far and the webinars that I’ve given.