A few weeks back, I talked about my struggle with my burnout. Working on SupportBee hasn’t been easy. We are bootstrapped in a crowded space full of deeply funded startups. Though we have been profitable for a while, scaling up has been quite a challenge. When I found myself burnt out in 2014, I decided to take a break from working on SupportBee and take some time to relax. Once I felt a little better, I started playing with a new idea — Hackint.at, a Github meets foursquare sorta app for helping programmers meetup. While my team kept working on SupportBee, I traveled to San Francisco and learnt iOS programming to build a version of the app and show it to hackers there. It was great — a clean slate with not much legacy to worry about. However after eight months on, I decided to shut it down and focus my energy back on SupportBee. Let me tell you why.
A clean slate is a wonderful thing. The possibilities are endless and obstacles seem very mountable. Compare this to a business that you have been in for a few years. You know about all the obstacles and challenges, the hairiest ones! Even though it’s comparing apples to oranges, at the time the possibilities of a new project seemed very liberating compared to the challenges of a business that wasn’t growing as fast I would have liked. However that wasn’t an entirely accurate picture.
Customer support is a complex domain. Software that makes life easy for it’s users embraces this complexity and finds a way around it. When we started SupportBee in 2011, we didn’t really understand the domain quite well. We had done customer support for Muziboo and knew that there had to be something easier for companies like ours that wanted to deliver friendly customer service. However we didn’t understand the nuances of customer support or the trajectory of companies that scale up and need to scale up their support. The software we original built reflected our understanding then. After spending a few years in this space and interacting closely with over a 1000 companies, we had enough data points to map out the domain. We understood the use cases as well as the edge cases. This has given us the understanding to build and test great solutions and to me, that’s priceless.
Let me give you an example. When we started out, I believed that a ticket has a requester and then a bunch of agents. However a lot of tickets have people CC’d on them. Should these be treated as requesters as well? What’s their role and how does it affect the ticket handling?
There are countless other things we learned that help us build much more usable and powerful interfaces and workflows. The more I thought about the domain in all it’s complexity, the more excited I got. Almost every software that claims to be “easy” today ignores the real complexity of the domain. I believe that we are going to see radically new approaches to handling customer support interactions in the future and I want SupportBee to be leading the way there, just like we did with email like customer support software back in 2011.
There will be new customer support companies in the future and some of them will be more funded than us. However I believe that it’s our understanding of the domain and our ability to execute on that understanding that will help us craft great software and attract customers. There are great product, engineering and hiring challenges to be solved and I am very excited about taking them on.