The greatest challenge of making a software usable is in making it bloat free. More often than not, even products that start off as simple and usable get bloated with a host of unrelated features within a year or two of being in the market. Companies keep expanding the scope of their products to add value to a wide range of customers. Even within a chosen domain, it is difficult to support all use cases by not constantly expanding the scope of a product.
So the difficult question is: Should you remain usable by keeping it simple or should you add value by adding features? How should a company resolve this dilemma? The danger of the first choice is that you may only appeal to a narrow market. The danger in the second option is that the software can become too unwieldy to appeal to target customers.
When we launched SupportBee, we were clear about what we wanted to achieve. Our overarching philosophy was to help our customers keep customer support human with the help of a simple and usable software. We crafted a feature set that aligned with our philosophy. We obsessed as much about what we should not be, as a company, as we did about what we wanted to be.
In the first year, it was easy to for us make decisions about the product and its road map. As our product was getting used by more and more customers, we found it difficult to cater to the needs of our customers without compromising on the values we set out the achieve. With the various features and options that our customers were presenting to us as ‘required features’ for their workflow, we had to make a decision - a hard one at that. We dreaded the idea of implementing them all for fear of becoming too complicated and unwieldy. At the same time, we wanted to make sure our product took care of our customers’ needs.
To give you an example, when we launched SupportBee we did not want to have the concept of ticket numbers in the help desk system for the reason that ticket numbers make interactions more transactional than conversational. However, in a little more than a year, we were catering to customers whose email volumes were so high that a case id or a ticket number was a functional requirement to keep track of thousands of their customer emails. When customers loved SupportBee for everything but could not continue using for lack of one feature or another, we had to make a decision.
We made our decision to transition SupportBee into a fully functional and hosted App platform that will support various workflows through built-in internal apps and third party apps. We moved from being a simple software with a rigid philosophy to a powerful platform with flexible workflows. Our goal was to build a support software that will lend itself to all workflows without dictating a philosophy.
We implemented the ticket number feature as an internal app that can be added to a customer’s SupportBee, if they needed it. We also built a host of other internal apps to render workflows based on customer needs. These features were not initially planned for SupportBee. Instead of discarding feedback just because they did not align with our roadmap, we started taking up those requests and implemented them as apps. Better still, we made SupportBee highly customizable by letting customers build their own features through apps.
We offer a fully functional API and Webhooks feature for customers who are interested in building and hosting the apps themselves. For example, the company Phusion, who is one of our customers, decided to implement a script for Service Level Agreements to work with SupportBee since we do no not offer the feature natively. Another user wrote a Python script to export tickets out of SupportBee.
Today, SupportBee is a functional software with all the basics and essentials, to which you can add more, to render the workflow that you need. SupportBee is the best help desk software, not for what we offer as features, but for how we made it easy for our customers to add features they want, thus preventing software bloat.
