//This is part 2 / 5 of a blog series written in collaboration with Rejoy. // If you haven’t already, please read our previous post on the introduction to the 4-step recipe.
There's no denying that collaboration between a product team and a support team is key for any SaaS business. But where do you start? In this post, we will provide a system to take your product and support collaboration to the next level.
Typically, the support team is in the middle of two parties; the customer and the product team, and their daily task is to communicate the reported issues to both of these parties.
Without proper information from the engineering team, support is not able to provide valuable information to the customer. The product team also needs support to get information from customers on how they can improve the product.
To fix this challenge, a system is needed with a clear objective of efficient workflows across support and product teams to provide the best possible support for the customers.
A good system covers responsibilities, agreements, feedback management, meetings, and measurements. When this is clear, check what you can automate to make things easier.
Let’s go over the 5 areas of the system in more detail.
1. Roles and responsibilities
When it comes to cross-departmental workflows, it is important to define roles and responsibilities. With well-defined roles, working towards a common goal becomes easier, because everyone knows the expectations.
A good way to define this is to use a matrix. Below is a RACI (Responsible, Accountable, Consulted, and Informed chart) template to manage activities across support and product teams. This is just an example illustration, and you should change it based on your environment.
Responsible: The team that performs the activity
Accountable: The team that signs off or approves
Consulted: The team that needs to be reached out for questions, feedback, or advice
Informed: The team that needs to be kept in the loop with any changes
2. Feedback management
Once the roles and responsibilities have been clearly established, the next step is to ensure feedback loop management across support and product teams. We’ll go over feedback across several interactions:
Raising the right escalation from support to product
One simple way to make escalations to engineering more efficient is to have clear guidelines on how these escalations are raised. The guideline should cover steps that need to be followed before an escalation.
For example; browse the knowledge base (KB) for an answer, search for similar tickets, and check a list of known bugs to avoid double-escalations. If the answer issue is found elsewhere, then add it to KB, to help the next time the issue arises.
Please notice, that it is the support team’s responsibility to understand the reported issue, before escalating it to engineers.
Sending necessary and sufficient info on escalations
It is useful to have escalations done in a standardized format, making it easy for engineering to parse the information.
It is helpful for engineering to have at least the following information:
Customer or user information (e.g. in a link format for quick access)
A detailed description of an issue; expected behavior vs actual behavior
Error messages, screenshots, recordings, log files
Steps to reproduce the issue
Support providing insights to product
To successfully pass Voice of Customer (VoC) to product, the support team should have aggregated information, so that it is not just the loudest customer’s voice. Sharing feature requests works the best with a template, this way all requests are stored the same way.
The request should contain at least the following information:
Number of times the request has been reported
Number of customers that have reported it
Revenue, renewal, and churn risk associated with customers
If possible, where the issue aligns with product roadmap
In addition, provide feedback on internal and external documentation to help improve self-service for both customers and support. Ultimately, this should lower the number of escalations to product.
Product supporting customer support
Product teams need to collaborate with support teams to lower escalations and improve customer experience. Some of the methods include:
Debugging tools for support: Internal tooling that enables support teams to debug and explore detailed information to resolve issues without reaching out to product.
Training and documentation: Detailed FAQs, videos, and training materials for support before any major changes are made to the product.
Self-service tooling: Aim for stellar self-service tools so that fewer tickets come to support in the first place. A great way to go about this is to get feedback from support on the internal debugging tools, release new features to the internal tool, and then over time push those features to the customer-facing self-service tool.
Feature prioritization: Involve support in the feature prioritization process. Maintain a simple template, even if it’s a spreadsheet, where support leaders can consolidate information on feature requests from the day-to-day support operations.
3. Agreement
As support and product are sharing the responsibility of customer’s experience, internal SLOs ensure that escalated tickets are resolved in a timely manner.
Coming up with great SLOs is an art and science, especially as it involves agreement across support and R&D teams. The solution is a 3-step framework: conditions, triggers, and actions.
Condition: This is the condition upon which out of SLOs are triggered. This has 3 aspects: customer, support ticket, and engineering issue.
Customer: This includes customer revenue, support tier, renewal, sentiment, etc.
Support Ticket: This includes priority, impact, type, etc, from support tools like Zendesk, Freshdesk, etc.
Engineering Issue: This includes the linked engineering tasks in tools like Jira, Asana, etc, which consist of type (bug, improvement, feature request, task..), priority, severity, etc.
Trigger: This is the time-based trigger that gates the condition. This has 3 aspects.
Time Without First Response: Time elapsed between the ticket being opened to getting a first response from the product team.
Time Since Update: Time since the last update made by the product team within tools.
Time Since Open: Time since the ticket is open without a resolution, with a linked engineering issue also being in open.
Action: This is the action to be taken based on the trigger and condition. This further has 3 aspects.
Email: Email alerts to specific email groups, individual people, etc.
Ping: Customized messages to a group of people, specific persons, or escalations among the management chain, if needed.
Label: Field updates in tools, so that they are highlighted in tools that teams use or used in dashboard filtering during team meetings.
While crafting these SLO definitions, we’d need to ensure these rules work to support SLAs, such as time to resolution, first response time, etc. An example is shown below to provide a rough idea of making use of this framework.
For more detailed information, read this ultimate guide on SLOs.
4. Meetings
Regular meetings between product and support enable team cohesion and morale. In addition, it acts as a good checkpoint for how the collaboration system is working. It is a great opportunity to share insights and align with topical information.
What
As with every meeting, this one too should take place only with a clear agenda and preparation. Consider having at least the following items on your list:
Metrics: volume drivers (TOP 3 reasons to contact support, TOP 3 reasons which types of issues increased), amount of escalations, SLO status
Status of high-priority bugs (important customer, high impact)
Aligning feature launches
News from product team, news from support team (e.g. new team members, new responsibility areas)
Who
Support team’s representation should include people that know the details of the issue, people that manage support teams, and also have a strategic view on overall support direction. This could be a Team Lead, Support Manager, Head of Support, or Director of Support. Some companies involve their Senior Support Agents in these meetings to help build relationships.
Product team’s representation should include people that can know the engineering details, people that manage engineers and product managers, and product management leaders that oversee the product direction. This could include, lead engineers, engineering managers, product managers, and Director of product development.
Frequency
Depends on the volume of tickets, the complexity of the product, amount of new features, and bugs. It is recommended to have this meeting at least once a month. Some teams like to have a meeting after each sprint, to plan items to take to the next sprint.
Outcomes
These meetings are usually informative, however, a clear understanding of how to fix the issue should be an outcome of the meeting.
Both teams should have a clear understanding of the current situation, high-priority bugs, upcoming feature launches, and action items to improve metrics.
On the qualitative side, everyone should feel supported and encouraged to continue their work and see that these meetings do matter.
5. Measurement
Finally, it’s important to measure if the collaboration is improving and how it is going. In the table below, we listed a few goals and metrics to consider.
Once you have the system established across support and product teams, it is important to automate the operational management of the system to reduce manual effort, enforce agreements, and meet your goals. Rejoy is one such tool that focuses on connecting support and product teams with internal SLOs on autopilot across your tools.
Collaboration can be easy if everyone is on board with the system. Make sure to set up a system that works for everyone and get everyone's agreement before beginning to work together. With a little bit of effort, collaboration can be a breeze!
In the next post, it's time to take a deep dive into knowledge sharing. Stay tuned for our post on how product and support can share knowledge efficiently!
Comentários