Madhav Bhandari is the Head of Growth at Hubstaff, a provider of staff-monitoring software.
Conventional wisdom advocates the concept of ‘all hands support’ – getting everyone from the CEO to the lowliest intern supporting customers so the entire team understands the customer’s problems. It’s a great goal, but is there a downside? What if your dev team starts spending much more time than usual on support and it eventually starts impacting your business?
Our Churn Issue
Around January 2015, we noticed an unusual increase in customer churn. A user churn rate of 3.9% had increased to 7% in just a couple of weeks.
We’re a revenue transparent company, so yes – these are our real numbers. 🙂
And it didn’t stop there. Over the next couple of months, our user churn slowly increased to a peak of 9.8%! This was alarming, so we decided to go a little deeper to find the root of the problem and understand this sudden increase in user churn.
Diagnosing User Churn
It isn’t easy to figure out the source of churn. It can be caused by a variety of factors, such as a bad user-onboarding process, unsatisfactory support, confusing product pricing and more. We needed to look at all aspects of the business to get a diagnosis for the source of the problem.
We checked everywhere. We checked our analytics and user onboarding and found nothing unusual. Our customer support was also great. We were scratching our heads trying to figure out what was causing the churn, until someone in our team suggested we check the time data.
Our entire team tracks time taken on all tasks that we work on. This makes managing schedules easier, plus we can see what everyone’s working on – a boon when your team’s 100 percent remote. Not to mention, we can use that data to optimize our business growth. We use our own time tracking software, Hubstaff, to track time on our tasks/projects.
It was when we went through our development team’s time data that we found something very startling: Our developers were spending 40% of their time on support!
That meant our developers were spending only 60% of their time on development. It just wasn’t enough.
Developers and Support
Of course, developers will always participate in resolving customers’ technical issues.
When a developer ‘ships’ a certain feature in our product, he owns that feature. So, if an issue arises with that feature three months down the line, that developer will be the best person to fix it. Sometimes, developers also diagnose problems arising from the customer’s end — technical issues that really cannot be diagnosed by the regular support team member.
However, it can get hard for developers to keep track of time they spend on support versus development. In order to understand customers’ issues better, developers often tend to go deep into conversations with customers.
Therefore it’s important for your development team to better organize their tasks so that there is a good balance in time spent on both resolving customer issues and shipping new features. Otherwise, business growth is affected (as you will notice below).
What the Time Data Revealed
So, coming back to the startling time data we found, we decided to investigate a little further. We discovered:
- Less time spent on development = Increasing backlog of feature requests – Because our developers were spending so little time on development, our backlog of feature requests from customers was at an all-time high.
- Increasing backlog of feature requests = Higher number of unsatisfied customers – The support team told us our customers were upset that their feature requests weren’t being implemented on time and they couldn’t afford the delay.
- Higher number of unsatisfied customers = Increasing user churn – So a lot of customers were closing their accounts and moving to other competitors that had those features. Our projects were moving very slowly and management was wondering why that was happening.
We couldn’t afford those delays, nor could we afford losing any of our customers. It was hindering our company’s growth.
Fixing the Churn
We brainstormed with our team to fix this problem and we came up with the following solutions:
Solution 1: Expand our support team
We had to make sure that all support requests were cleared out as fast as possible and ensure that any communication between customers and developers was via our support team. If any issue needed to be resolved, and if the development team needed more information about an issue, they had to let the support team know.
We hired new support team members (whose hourly rates are typically lower than developers), developed a process for them to start assisting our existing support team, and got them on board.
Solution 2: Set up a ‘sprint process’ for the development team
We also made sure that our development team members had their work priorities set in the right direction. They needed to own their tasks and make sure they completed them in the designated time period. These tasks would be prioritized based on our product roadmap and what would help us most to achieve our yearly business goals.
We set up a sprint process for our developers based on the process that our marketing team already follows. We agreed on what tasks our developers needed to complete in a given timeframe (usually a week or two) and made sure they got them done. All tasks were selected so there would be a good balance between shipping new features and resolving existing customer issues.
We also started daily standups on Slack where each team member answers the following questions:
- What did you do in the last 24 hours?
- What do you plan to do in the next 24 hours?
- What (if any) impediments exist that prevent you from doing your work?
- Is your sprint list for the week currently on track for completion? If not, why not?
This gave much clarity to each team member to organize his/her work week. It also ensured a certain level of accountability on the sprints so another situation like the above doesn’t arise again.
- New support hires reduced the load on support – Our new support team members reduced the overall load on the support team (consisting of many developers), and they were efficient. It took about a month, but everything is running smoothly now and our developers have more time to work on development.
- Development team’s priorities were back on track – Thanks to our sprints process, our developers are now spending the majority of their time to complete their development sprints on time. This helped realign everyone’s priorities, which helped move the business forward faster than ever before.
- Our developers were happier because they could now spend most of their time on development projects, which is what they enjoy more.
- Customers were happier – We have started delivering features week after week. Our support time has sped up incrementally and we now typically respond to our customers within 1.5 hours. We also provide 24/7 support.
- We moved projects forward faster and management was no longer wondering why projects were taking so long.
- We were able to hire support people for lower rates than developers, which helped increase our company’s bottom line.
Over the next few months, we eliminated our backlog of feature requests and delivered new features regularly and efficiently. Our developers began nailing their tasks every week.
Results By the Numbers
We were highly satisfied with the results overall, but we still needed to look at our business metrics. The real question was – did we reduce our churn?
We went into our Baremetrics account and found that, over the 3 months after implementing the change, our user churn reduced from a peak of 9.8% to a healthy 4.2%.
Here is the link to our user churn chart
And we have almost tripled our revenue in the last 12 months.
Time Data Saved Us
If we hadn’t analyzed the time data, it would have been very difficult for us to discover that our developers were spending too much time on the wrong tasks, or that our support process had a serious flaw. By the time we figured out the issue, our business could have gone down even further. Churn can literally make or break your business.
Having a record of your time data and knowing where your team is spending their hours is very critical for businesses. There are countless number of articles that talk about the important business metrics like churn, LTV, CAC etc., but in my opinion – the most important business metric is your team’s time data.
From the above incident, I’d like to share two key takeaways:
It’s absolutely imperative to know your time data.
It gives a clear overview of your business on a weekly or monthly basis. It will help you diagnose problems down the road and preempt them. Better yet, it can help you avoid wasted time and unfavorable situations altogether.
Ownership of tasks helps in setting priorities in the right direction.
Set up sprints, ensure team members own their tasks and trust them to deliver on time. This helps set up the right priorities for your team and your business.
A Simple Way to Track Time on Support
We built Hubstaff, our time tracking software, to help you better manage your team. Apart from time tracking, Hubstaff also takes screenshots and monitors your team’s productivity levels throughout the day.
Your business can now track time on your individual Freshdesk support tickets and understand exactly where time is being spent.
- Know if your team members are spending more time on support for free accounts versus paid accounts
- Know if your team is spending more time on business development-related queries versus support
- Know how long each support ticket takes to get cleared
- See how tickets are being worked on with random screenshots taken every 10 minutes
- Know how your team is performing with the help of activity levels
- Close Freshdesk tickets directly from the Hubstaff timer
So in short, this time data will help you take corrective action on a daily basis to best optimize your support process.
Screenshot of productivity levels of our team
You’ll also be able to determine which of your support agents are working the hardest to provide the best customer service, so you can reward them accordingly.