//This is part 2 / 5 of a blog series written in collaboration with Fluent in Support.//
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.
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.
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.
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:
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.
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:
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:
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 teams need to collaborate with support teams to lower escalations and improve customer experience. Some of the methods include:
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.
Trigger: This is the time-based trigger that gates the condition. This has 3 aspects.
Action: This is the action to be taken based on the trigger and condition. This further has 3 aspects.
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.
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.
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:
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.
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.
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.
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!
Is this flowchart close or far away from the process at your organization? Let me know if you have questions or comments at email@example.com. I'd love to hear from you!
Once you have established a process across teams, the next hurdle is to automate this process especially when your teams and data are spread across several tools. In this blog post, I dive deeper into how to automate your process using internal SLOs across your cross functional teams.