As Customer Success Manager and Support Project Manager, my job is to make sure clients are happy, but also to ensure that the Technical Support Team and the Development Team are communicating properly in order to achieve that.
My day to day tasks involve writing and improving support documentation, taking care of our community forums, and tracking and test bugs and resolutions. I not only have to understand how things work, but why they work the way they do. If something ever goes wrong, I can pinpoint the issue better, and then communicate results and updates to both the rest of our team and to our clients.
Zendesk and Jira have extraordinarily improved our team's support process, allowing us to efficiently deliver a great app. These tools have become much more than just bug or ticket trackers, but have allowed us to more appropriately communicate with our clients and keep them in the loop as to what happens behind the scenes.
Our support process is divided into 4 parts: the support request, bug verification and reporting, QA, and final delivery.
The Support Request
One of the biggest challenges I’ve had is creating a simple and easy way for our clients to submit support requests. We cater to both our clients and their clients, so requests need to be streamed depending on the requester and the type of request.
We decided to allow our clients (who we call “Organizations”) to directly submit queries through our Support Center with Zendesk by including a ‘HELP’ link in our app’s header. This way they are immediately rerouted to our Knowledge Base, where they can first check if a help document is already available. Success rate: 85%! Only 1 out of 7 searches results in a support ticket.
Our request form includes basic fields of information (who they are, browser info, request type and detailed info), most of which we have made mandatory. This ensures that we get all information required beforehand, speeding up the process.
Within the app we also have a Contact Us form for both our clients and their own clients. All requests from Orgs are directly linked to Zendesk thanks to their API, which allows us to catch all sorts of really neat info as well, like their userID and browser type. Depending on their clients’ requests (we call them “Participants”), the ticket will either be sent to us using the API, or to the responsible Organization. This has immensely improved our SLA and decreased the amount of requests the Amilia Support Team deals with on a daily basis.
Once the support request is submitted, it is then rerouted to a specific inbox. I made it a point to have all requests, whether sales, billing, or technical to go directly through to Zendesk. This ensures that all client history is in one place and one place only - avoiding misinformation and allowing for better issue tracking. This is where it got a bit tricky... thankfully Zendesk is easy enough (and crazy enough!) to be able to manage it.
I first set up different views depending on the agent group.
Example: Sales, Info, Technical, Billing, Feature Requests
All emails that go to sales@ will automatically be rerouted to sales@myhelpdesk.zendesk.com
All emails that go to info@ will automatically be rerouted to info@myhelpdesk.zendesk.com
When they come in, they are automatically tagged and placed in specific views, so agents can quickly pick them up. Sales doesn’t see support tickets, and support doesn’t see sales or billing, so the teams can focus only on their own tasks. (Unfortunately, as a manager I see EVERYTHING!
Since implementing this process, our team has solved 424 of 491 tickets in the past 30 days. That’s 86% of all tickets solved!
Bug Verification and Reporting
Level 1 Support is in charge of verifying all bug reports. If the bug is reproduced as reported, then it is immediately escalated to Level 2 (in this case, me.) I test the bug once again, and if I can verify the issue, I use the Zendesk-Jira bridge to connect the issue to Jira. While on Jira, all tickets are placed On-Hold in Zendesk.
Find out how to set up Zendesk with Jira here
Within JIRA we manage several other projects, so in order to manage them all accordingly, all important on-going projects (like Support), are posted on the JIRA banner.
Within that JIRA case, called ZENDESK_BRDIGE, I post tickets in order of importance. We are three different people working on this project, so it is imperative that things are constantly updated to avoid confusion.
The flow goes something like this:
Tickets (in order of importance) are assigned and added to the board.
All solved tickets of the week go under Completed.
All tickets for which we are awaiting further info go under Pending.
All tickets that require a release go under For Next Release.
All other tickets are placed under the specific co-projects.
Within the Zendesk ticket, I can see who is currently working on the issue in JIRA and what the status is. All JIRA comments are immediately linked to Zendesk as private comments, which allows all agents to be up-to-date and communicate with the Dev Team without having to login to JIRA directly.
We also manage Feature Requests and Accounting with the same process.
Tip: We allowed Jira to be able to sync fields with Zendesk so our Dev team is able to see client details without having to go through Support. While it is extremely helpful in that sense, keep in mind that this also means that when a status is updated in JIRA, it is also updated in Zendesk. Because of that, we ask developers not to solve cases, simply to add a comment - either if the issue was fixed directly in Production or if it is ready for the next release, otherwise the ticket is also solved in Zendesk without any notice to the agent.
QA and Final Delivery
Once the Development Team has fixed the bug, they will either tag the JIRA case as either “fixed” or “for next release.”
“Fixed” means that the bug was fixed directly in Production.
“For next release” means that it was merged with our QA version and is ready for testing. It will be rolled out with the next release, which happens at least once every week.
All “fixed” issues are tested first by level 2, and then by level 1 before advising the client (because more tests are better than one!).
All issues merged in QA are generally tested by more than one person, and not necessarily from the Support or Dev Teams either. With really big releases (like new features), we ask everyone from the CEO to Marketing to run tests, and of course, our QA Analyst. This allows us to catch things from different points of views. All comments are, of course, logged in JIRA.
Once all tests are done and the package is ready to be rolled out, I take all tagged “for next release” cases from JIRA and compile release notes. These release notes are posted in our Support Center and pinned to the front page. (They’re also posted in French AND English, but setting up Dynamic Content is a blog post for another day... )
--
And that’s it! Of course, this process is always under review and improvement - the life of Support is never static, never dull, and in constant evolution!
