How Freshworks solves customer problems
Freshworks is extremely passionate about customer happiness and we love resolving customer problems quickly. Our customers create tickets when they face a problem or want a question answered. This article talks about how our support and engineering teams from one of our core products work together to solve these problems quickly and create moments of wow for customers.
How we handle tickets
We have our own support portal, which is the Freshdesk product itself, and our customers reach out to us through this portal. Our support agents look into these tickets and respond to the customers from the Freshdesk Support portal. At times, there are tickets that need assistance from the engineering team. They are then assigned to the engineers. Our engineers work on these tickets and resolve them within an agreed time frame.
Categories of tickets
The tickets received by Freshdesk are categorized into the following buckets.
- Tickets that require clarification: These are the tickets that can be handled by the support teams themselves and will not require any engineering assistance.
- Tickets that require troubleshooting: These are the tickets that can be handled by the support team with engineering assistance.
- Tickets that require a bug fix: These are the tickets that would require a code change from the product and can be handled by the engineering teams.
- Tickets that satisfy a custom request for a specific customer: These are specific asks from customers, where they would require a certain export or a bulk update from the backend.
- Tickets that require a feature change or an enhancement: These are feature requests or enhancements, which need to be prioritized by the product management team. The engineering team works on these as part of one of their roadmaps.
The internal support portal
All tickets received by support agents are automatically moved to an internal Freshdesk powered support system for our engineers to triage and resolve them within an agreed SLA. The reason for having an internal support portal is to measure engineering SLAs and configure rules specific to the engineering team. We didn’t want to disturb the main support portal since that is where all the interactions between the support agents and customers happen. Automation rules have been created and these rules create a replica of tickets that flow into the support portal along with the status, subject, and any comments added between these two portals. Configuring the internal portal was seamless and easy as Freshdesk supports all the required functionalities to make this work. The two portals are linked in such a way that the engineers become the support agents and the support agents become the customers of the internal support portal.
How we handle our maintenance load
In Freshdesk, the squad model is followed and each squad has a set of developers, technical leads, QA engineers, a product manager, and a designer. We follow a few different models to handle the maintenance load.
The in-house model
- All the maintenance work is managed from within the squad and all the work items are considered as planned sprint items.
- Custom requests and tickets that require troubleshooting are handled on an ad-hoc basis by the squad as soon as they come in.
- The maintenance work load is distributed between all the squad members.
- This method works best for small product teams where the maintenance load is lesser.
Dedicated team model
- A dedicated team can be formed outside the squads, and this can be a 20-25 member team.
- This team focuses only on maintenance work and does not contribute to feature development at all.
- This method works well for big teams where the maintenance load is heavy.
SWAT model
- A virtual squad can be formed in the SWAT (Swift Action Team) model where a couple of engineers from within the squad are pulled out for maintenance work for a short period of time, which may be a sprint.
- The engineers can be rotated once their tenure in SWAT is done, and they can thus work on both features and maintenance work in the corresponding sprints.
- The SWAT model can also have members from across different squads coming together to solve a common problem for a span of time.
- This method works best for big teams where there is an equal split between feature development and maintenance work.
The SWAT model is followed in Freshdesk since equal importance is given to feature development, technical debts, and maintenance. The SWAT model also creates a sense of ownership and accountability because the team that fixes the bugs is the same team that engineered the features.
The SWAT team of Freshdesk
There are multiple SWAT teams in Freshdesk, and these SWAT teams have up to 10 engineers working on maintenance. The core responsibilities of these engineers include solving all customer reported issues, security bugs, and performance bugs. These are rotational cycles where the engineers would pitch in for a sprint and resolve tickets and then move back to their corresponding squads to build features. While few engineers contribute to customer reported tickets, the others contribute toward resolving bugs and improving the app’s performance. There would always be a question about disturbing the squad’s composition. In this model, the sprints are perfectly planned only for the people who work on feature development from within the squad and not for the engineers working on SWAT. This way, the squad’s sprint progress is undisturbed, and while the feature development squads work in the ‘scrum’ model, the SWAT team works in a ‘Kanban’ model.
The weekend warriors
There is a Quick Action Team that is always available to resolve urgent issues of high priority that come on the weekends. The team quickly pitches in to resolve these issues within a few hours to ensure that our customers are not blocked even on weekends. There is also a team of engineers who are available outside business hours so that if our customers face any issue that is hindering their productivity, these engineers are available—no matter how late at night it is— to quickly jump in to resolve the issue.
The metrics
The key metrics for all the customer-raised tickets are the ‘resolution SLA %’ and the ‘average resolution time’. The resolution SLA% is calculated based upon the number of tickets resolved within the SLA divided by the total number of tickets resolved. These are measured and tracked on a weekly and monthly basis, and there are automations to trigger reminder emails if a ticket is about to breach the SLA. There has been a good increase in the SLAs. That’s because there was a SWAT team in place. Having the internal portal helped achieve this as well.
The permanent solution for all customers problems
There are chances that the tickets that are received from one customer today might be received from another customer tomorrow. There should always be a permanent solution to all the customer issues and the teams should be able to find and address them. The engineers dive deep into every single ticket reported by the customers and come up with a set of patterns to see if the issue can be fixed permanently by pushing out a code change. These tickets are also categorized to identify product areas that require immediate attention so that a target is identified to be fixed permanently. These bugs are also picked up as part of the SWAT sprints and there is a reduction in the inflow of customer tickets once the bug fix goes live. There is also a deflection program where the support agents are trained to analyze and address customer issues by themselves so that these do not land up in the engineering bucket. There are also a bunch of documents that are shared across all customer facing teams to guide them to get to the root cause of the tickets by themselves. At the end of one quarter, the inflow of tickets coming to the engineering team had gone down by 15%.
Customer satisfaction is an integral part of any product, and engineering teams are important contributors toward solving customer problems and making them happy. The ticket handling and ticket deflections are all powered by Freshdesk’s inbuilt Automations and Freddy’s intelligence.
In our upcoming blog, we’ll take a deep dive into a bunch of other things done by the engineering team to ensure that customers are delighted with our product and service.
