Depending on the application, help desks and bug trackers have roughly 80% overlap in terms of basic functionality. However, that last 20% makes a big difference in determining whether they’re truly good at one or the other.
Individuals vs. Teams
Help desks are about supporting an individual. Whether that’s a question, a support request, or just comments, each support request stands alone. The individual’s request history may be relevant, but it’s still focused on the individual. As such, with a help desk, people’s visibility should be limited to only public issues or those that belong to them.
Bug and issue trackers are about multiple people collaborating on a shared goal. So, it’s important for everyone to have visibility into each other’s work loads. This is the single most important defining characteristic because it affects and informs all of the other design decisions.
Limitless vs. Discrete
With help desks, you can’t always predict who your users will be. For instance, if you sell software, you could have thousands or millions of users. As a result, you need to either accept anonymous or semi-anonymous requests or provide a means for users to register and create an account.
However, complete anonymity is a dangerous idea. A significant number of requests require additional details or clarification because very few people are thorough enough to submit all of the necessary information on the first request. If you can’t follow up with someone, you can’t get this information.
With a bug and issue tracker such as Sifter, there is a basic assumption that the people involved are on a well-defined team with a discrete number of team members. Under these circumstances, it is possible for each team member to have a manually-created account.
Since everyone in Sifter has their own account, the concept of accountability is baked deeply into Sifter. We’ve always felt that the best way for work to get done is for one person and one person only, the assignee, to be responsible for the solution while one person, the opener, is responsible for the problem, or, more accurately, facilitating the solution and providing the necessary information to the assignee.
With an anonymous request, there’s no way to follow up for that additional information. In fact, even if you think you’ve fixed the problem, you have no real way of knowing whether you did indeed fix the problem for that individual.
The exception to the rules is open-source software which needs and involves elements of both a help desk and a bug tracker. The participants are limitless and undefined, and everyone should have access to all of the issues. Similarly, there will be active participants who both discover and fix bugs, but there will also be people who are only interested in sharing their individual needs and are not necessarily interested in the project as a whole. These are subtle but important differences that complicate things for us. Ultimately, we’d like to support open source projects, but we have to focus first and foremost on our core goals.
We’d love for Sifter to work great as a help desk, bug and issue tracker, and open-source bug and issue tracker. It would obviously increase our potential customer-base, and what business wouldn’t want that? However, we also firmly believe that if you chase two rabbits, you won’t catch either.
Our decision to make Sifter what it is wasn’t accidental or contrived. We built the tool that we always wished we had in order to work with clients. We understood that we couldn’t be everything to everybody, so we chose to focus on supporting a client/consultant or developer/stakeholder relationship for well-defined teams.
This isn’t to say that Sifter can’t be used as a help desk, but it’s definitely not designed to behave like one. Every decision about responsibility and workflow has been carefully considered and explored, and we’ve had to make some decisions that impede Sifter’s ability to work as a help desk in order to make sure that it really works at being a bug and issue tracker.