No one ever said that being a software company CEO is an easy job. The responsibilities are endless and you must constantly monitor every area of the organization, especially customer activity and the product roadmap. While technology can't solve all of a CEO's problems, the appropriate toolset, properly implemented, can go along way toward transforming a rocky road into a smooth highway with well-defined mile markers.

CRM's Limitations

For 13 years, I was the CEO of a very successful software company which targeted a specific vertical industry. We were an early and enthusiastic adopter of sales-focused CRM technology, which allowed our sales, marketing, and executive teams to work closely, yet spend less time briefing each other on the various stages of projects and sales—all the essential information was at our fingertips.

However, as the company grew, we quickly realized that while CRM was great for sales and marketing, it was woefully lacking for customer service and completely ignored the product development group. As is all too common within software companies, our customer support group ran a basic "help desk" application and our product management and product development groups (the folks who actually created and fixed our products) used a completely different "bug tracking" application.

Having these two departments use different software products resulted in the creation of very distinct organizational silos which prevented any meaningful communication between them. If a bug was reported by one of our clients, there was no easy way to pass it to the developers, so we resorted to e-mail. The customer service group would lose track of the bug's status and had no useful information to report back to the customer.

Of course, while the customer service group and product development group could not talk to each other, the sales and executive teams were left completely in the dark.

It became abundantly clear that having a bug tracking system with no concept of a "customer" was organizational suicide.

Back to being a CEO: I vividly remember the proverbial "straw that broke the organization's back" phone call. A high profile customer called me, irate about a certain problem. I pulled-up our help desk and found the issue, but saw that the problem was actually a bug and had been sent over to the developers. I pulled up the development system, but had no way to search for the individual client! I could not list all the bugs assigned to a particular client, since our bug tracking system—like most—had no concept of "customer."

After a lengthy struggle with the client, I experienced the "aha!" moment and realized we needed much better integration between customer service and development.

It became abundantly clear that having a bug tracking system with no concept of a "customer" was organizational suicide. The two most important things in a software company—our products and our customers—had to be integrated in order to maintain (and hopefully surpass) our level of success.

Connecting Help Desk to Development

I surveyed the market for a solution, but was unable to find anything. There are a lot of great help desk applications out there, and there are many great choices for bug tracking systems. The inherent problem, however, is that the help desk applications had no real understanding of the product (i.e., no help desk could connect the software and the problem), while the bug tracking systems had no notion of a customer.
Since we were a software company, I quickly sketched the outline of a product that would do what we needed and pulled a developer from a revenue-generating project to code it.

The end-result was a great software tool that was quickly embraced by everyone in the company. The customer support group had the application open all the time and used it exclusively to track customer issues. When a customer called they could quickly find their record and view all the open issues, bugs, and even feature requests. They could also see the status of items that had been sent to the development group and were able to update the customers on the status of their requests.

We could finally track an issue from the initial call, through development's repair, QA testing, and final deployment to the customer.

The development team transitioned from their dedicated bug tracking system to our internal application and the movement of bugs and feature requests from customer service to the development group became a simple change of on-screen pull-down window. Since most bugs and feature requests came from our customers, this ended up being a great workflow tool. We could finally track an issue from the initial call, through development's repair, QA testing, and final deployment to the customer.

The sales team loved it as well since they were much better informed about problems at a customer site. Having one of our sales team proactively call a customer to let them know we were aware of a problem and working hard to resolve it created a great deal of loyalty and good will. Also, our sales staff could check the support system for open issues before calling a customer to discuss system upgrades and other incremental sales activity. Armed with knowledge, the sales staff could easily defuse most situations, while demonstrating to the customer that our company worked well as a team and was aware of all their issues.

Our executive team also used the product extensively. We could finally identify which customers were experiencing the most issues, what products were most problematic, and track the products owned by each customer.

The software soon became the centerpiece of our Monday morning meeting. The entire development team sat around our conference table as we displayed support application data on the projector and prioritized issues. The bug and feature list also helped us manage what was being worked on at any given time.

We sold the company a couple of years ago, and as I cast around for a new venture, kept coming back to that piece of internal software we wrote. I explored the market, but could not find another company that offered a similar solution.

As a software company CEO, I understood firsthand the benefits of integrating the customer service and product development teams under a unified software umbrella, but it seemed the rest of the world hadn't figured it out yet. The software marketplace was filled with "Help Desk" and "Bug Tracking" applications while I struggled to find one that integrated both critical departments.

New Solution

Seeing an opportunity, I hired a couple of key people away from the old company once my "non-poach" agreement expired. We started TeamSupport.com with the mission of creating a better version of the internal product we had all used at our previous company.

We realized that our previous product fell short in several areas and set about adding features:

1. For it to be well suited for both customer service and development teams, we had to add support for source control systems. Integration with a source control system allows the developer to check-in a piece of code and simply put the ticket numbers in the description. This adds an action to the ticket saying that it was addressed in a specific compile of the software and keeps everyone in-the-loop.
2. We also needed a customer portal. It is critical that customers be able to enter their own tickets and check on the status of existing ones. Anyone who has been involved in customer service knows that a significant percentage of calls are simply customers trying to get an update on an outstanding issue. Having a customer portal reduces these time-consuming interactions and could potentially pay for the implementation of the system!
3. The third missing element was integration with e-mail. We all know that a great deal of communication—both internal and external—is done via e-mail, so a very tight integration with the customer service and bug tracking systems is essential. In our implementation, inbound e-mails which reference a ticket number are added as actions to the ticket and sending e-mails back to the customer as simple as clicking on a link.

The end result is TeamSupport.com, which met all of our design goals and more. We knew we had to satisfy the demands of each department individually in order to have the product deployed on an enterprise level. With this in mind we created a world-class help desk application which also functions as an enterprise-wide bug tracking system.
Not surprisingly, we use TeamSupport exclusively within our own operations. When a support call or e-mail comes in, it is logged as an issue in TeamSupport for the customer service group to address. If it is a bug or a feature request, they simply change the ticket type to "bug" or "feature" and it is automatically forwarded to product development.

Back to where we started. Being CEO of a software company is not an easy task, but having the right tools makes my job a heck of a lot easier and it lets me focus on what's really important: Creating, selling, and supporting software.