From bug report to bug fix: optimizing the Customer Support journey

Products reaching millions of users also mean getting many support requests. Our team of 17 support agents receive 450 new tickets daily. Some of those tickets might be frequently asked and easily solvable, but others require reaching out to engineers to gain more insights. Imagine having to reach out to engineers for each of those tickets: that’s a huge impact on productivity.

Optimizing the customer support journey will impact your team's productivity while speeding up the time it takes to go from bug report to bug fix. With the right upfront insights, support agents can indicate whether a bug fix is needed without bothering engineers.

Indicating repetition

Improving the customer support journey starts by indicating repetitive tasks and questions. Repetition can happen at several levels, including conversations between support and users, as well as between support and engineers.

Our mobile apps support team often reached out to our mobile engineers, after which they got questions like “Which app version is the user using?” or “Is the user already using the latest iOS version?”. It’s also common to see the same issues happening again:

The Transfer for this user also failed because of low storage on their device.

— A mobile engineer answering a support agent question

Repetitive questions and product failures can lead to repetitive chats between users, developers, and support agents. While the best solution would be to solve those issues entirely, we have to optimize for scenarios that won’t disappear.

Empowering support agents

By empowering support agents to answer common scenarios themselves, we reduce the disturbance for engineers while we increase the productivity of the whole support team. Commonly asked questions should have an answer per user without requiring an engineer. Ideally, support agents would also be able to indicate patterns between tickets and validate whether users run into the same issue as other users. The latter will ensure agents only occasionally reach out to engineers for a common issue.

Introducing Diagnostics Reports

Providing answers to common questions and speeding up repetitive tasks can be done by creating so-called Diagnostics reports. Our iOS team embraced these reports and open-sourced their framework accordingly:

GitHub - WeTransfer/Diagnostics: Allow users to easily share Diagnostics with your support team to improve the flow of fixing bugs.
Allow users to easily share Diagnostics with your support team to improve the flow of fixing bugs. - GitHub - WeTransfer/Diagnostics: Allow users to easily share Diagnostics with your support team ...

Users can reach out to support from within the mobile apps by sending an email that will have a Diagnostics Report attached:

An example of a user's email containing the Diagnostics Report as an attachment.

The attached Diagnostics Report contains information about the user’s device, app version, and sessions. An example Diagnostics report looks as follows:

An example of a Diagnostics report sent through Collect.

It’s an HTML page with a floating menu on the right that allows navigating through several sections quickly. The report is built out of chapters that can be customized per client to fit their needs better. Our mobile apps created links to tools like Firebase and Datadog to open crash logs and session data specific to the user. Repetitive tasks like finding back a user in those tools become easier to perform, reducing the time engineers need in case support does reach out.f

The support team can quickly answer questions like OS and App versions without replying to the user:

Generic system information shows details about the user’s environment.

Before these reports, agents had to have several back-and-forth conversations just to get basic details for a user.

The session overview shows system, debug, and error logs that will act like detailed breadcrumbs while analyzing. Support agents can enable filters to show error logs only, allowing them to indicate repetitive issues for our users:

Besides navigating quickly using the menu, support agents can control filters for session logs.

Smart Insights

While the Diagnostics report enables support to get answers, it’s not always to know where to look for answers. The Smart Insights chapter allows anyone to answer common questions quickly, even if they’re new to Diagnostics reports:

Smart insights provide quick answers to commonly asked questions.

In this case, the intelligent insights show which experiments are active for the user, how much storage is left, and whether an update is available. Support knows there’s nothing essential behind the user issue as long as there are only green checks. If the user used an older version, a ⚠️ sign would be shown instead.

Clients can implement custom smart insights based on system logs, thrown errors, or other details they can get out of the user’s environment.

Close collaboration between support and development

Support teams need to work together with client teams by checking in bi-weekly. Each check-in will focus on updating client teams with the latest trends in support tickets and finding out what repetitive scenarios we might have.

Optimizing the customer support journey is an ongoing effort. New scenarios of repetition will appear, while previous ones might disappear. Engineers must stay updated to optimize the Diagnostics reports based on the latest insights. Doing so constantly empowers support agents and reduces the time engineers might spend giving support the answers they need.

Conclusion

Optimizing the customer support journey impacts the support and engineering team’s productivity. At the same time, your users will more quickly get an answer for their issue leading to happier customers. Diagnostics reports provide valuable insights for support agents and engineers, removing the need to have back-and-forth conversations to extract primary user data.