How to Build a Linux Service Business

Interested in enhancing your project by adding an efficient service function. Open source solutions exist that can help you build a high quality, low cost solution. Interested? Read on.

By centralizing a ticket tracking system on the Internet you can create a virtual 24 by 7 Linux support business. You'll want to use a combination of VoIP and a global clearing provider for taking payments. A system like this costs pennies to start and has the ability to scale rapidly.

The Need for a Friendlier Service Model

In the open source software market, you have to provide excellent service and provide easy access to your support personnel. Business people who believe they can built a viable company on unique software alone will fail. Unfortunately, not many successful service models exist and even consultants in this area have a difficult time managing a service-oriented function.

The best models I have seen use automation to cut costs. But those systems tend to annoy clients. Promising to provide a living, breathing person on the end of a phone call sounds great in a TV Commercial but rarely solves the problem. Have you run into a friendly service provider lately?

To give you an example, I had a lousy experience with a VoIP provider. I tried AT&T CallVantage for several months last year in combination with Charter Communications high speed cable. I discovered that both companies outsourced so many of their services that I could never get the VoIP system to work properly. I had to move back to copper to get reliable service and to bring the costs in line.

My Case Study

Three years ago, I noticed a significant trend of declining sales in the IBM business partner segment of a business I managed. I looked at every indicator I could find and nothing stood out as a problem. While tracking the cause of the sales decline, I noticed that my entire customer service department had go to lunch at the same time and left the phones unmanned for over a hour and a half.

I inquired and found out that in spite of policies to the contrary, the service personnel had followed this practice for several weeks. So, with their desks vacated, I logged on to one of their workstations and discovered the team was 85 days behind answering service requests. I could hardly believe it.

I went back to my programming department and discussed the problem with our head engineer. I asked him to research ticket tracking systems and come up with a high quality solution. Within a day, he came back to me and showed me a system called Request Tracker (RT) by Best Practical Solutions. I had worked with several enterprise level trouble ticket systems at major enterprises such as Gateway and Ericsson, but I had never seen a product of RT's quality.

My head engineer informed me that the product was free and open source. I felt dazzled. How could someone give this product away I asked myself.

I called a meeting of the development team and posed the problem. We decided to write every client in the old queue. I explained in an email that we had started auditing the service department and found significant delays. I wanted to know if the customer had received help from our company and had they solved their problems.

We used RT to do the mailing and it automatically assigned each customer incident a tracking number. The feedback created some intense situations and many customers felt betrayed. But using RT and splitting up the work load so that each engineer covered a three hour segment, we caught up with the service requests in less than ten days.

Within a week, our sales started to climb back to the levels of the previous quarter. After we caught up, we agreed to continue following the protocol of having engineers devote time to service requests. Our goal was to respond immediately with a ticket number which RT did automatically and to communicate with the customer within 30 minutes.

If I only Knew

Two years before I discovered the issues with my support center, we had built one of the first pay-per-incident Linux call centers. We built the business from scratch, stayed independent and finally became an outsourcer for a major Linux distribution. Initially, we received referrals from Red Hat and Caldera.

I had little problem finding Linux people to man the phones. A call center named Stream had lost a major contract and laid off many highly trained call center employees. As we grew, facilities and infrastructure kept us from scaling.

Red Hat and Caldera saw our business growing and began call centers of their own. Corel had abandoned their Linux business and we had difficulties working with Mandrakesoft. So, we abandoned the call center business and devoted our energies tobecoming a Linux ISV. We wrote Linux software which worked with Outlook and MS Exchange.

After seeing how well we managed our service department with RT, I realized that we could have used it to keep the costs down and to provide better service than we had previously. I wrote another business plan for a Linux support division with RT at the hub. The startup costs were insignificant and I found lots of people familiar with Linux in the Information technology field looking for work from California to Germany.

The model called for setting up a self-service web site with a significant database of FAQs. We also wrote howtos and built both backports and packages that the original Linux distributions refused to offer. The pilot focused on Sun's JDS Linux distribution.

The success of the web site convinced me to set up a pay-per-incident call center. Ready to launch, Sun decided to abandon its Linux desktop. Prior to that event we had some interesting opportunities.

One of the top five IT Consulting firms asked us to sell them a bundle of pre-paid incidents. We also had similar discussions with resellers and integrators. Because of our low cost structure, we could sell incidents and the channel people could resell them at a significant profit.

A Low Cost Start-up with Significant Potential

Two developments in IT provided a new model for a service oriented business. The first involved the use of VoIP using Skype and Asterisk . The second involved qualified Linux support people available globally.

In discussing the business plan with friends and acquaintances around the globe, I discovered a significant appetite among Linux people who wanted to contract and cover request queues. For example, I found people who excelled at Debian, Red Hat, SUSE, etc. Some excelled at DNS, databases, mail and other specialties. Some were good generalists.

Some of the people who contacted me wanted extra work and some wanted to simply work at home. The key to creating a low cost global communications system involved setting up Asterisk servers in locales where the contractors worked and then centralizing and exchange using one of the free VoIP services like Skype.

Using caching techniques, the request queues fill up and people manning RT can grab a new request when the next engineer becomes available. If an engineer grabs a request but can't service it, then he or she can pass it to an engineer who can. I've seen this work particularly well using RT.

My first call center produced opportunities over and above initial level one calls. In a majority of circumstances, the level one call turned into multiple incidents and/or projects. In fact, two case studies I wrote for Macmillan were the result of rollouts of Linux in two enterprises. We got those contacts because the businesses started using our call center, then our level two and level three technicians. They asked for us to answer tenders and we won the business.

So many people around the globe use Linux and desired to work in a Linux company that we had no scarcity of people wanting to join the business. I plotted out the locales where we could have placed Asterisk servers that could feed into an exchange that our telecommunication costs looked small. In addition many of the tickets closed could feed a knowledge base available from Practical Solutions that attached to RT.

Is this a Feasible Business?

When Sun backed out of the Linux desktop business, I felt that we wasted a year developing our pilot. We also lost the funding opportunities available by selling incidents in advance. Having walked over burning coals in my previous encounter with VCs, I had no desire to work with them again.

I doubt many people would want to work 90 hours a week for three years and have some person tell you to surrender your stock, sign a five year contract at the end of which you could earn back nine percent of your previous holdings. In addition, those people went to the other members of the firm asking them if they would move to another city while failing to inform you.

While I chose to delay a move to into another venture, I still see the value of Request Tracker as the hub of a service business coupled with VoIP technology. This model allows you to centralize your support in a web portal while using a distributed work force. Any software provider wanting to offer support to end-users, channel partners or resellers can use this combination to provide high quality service. Just make sure you man RT and get to your customers quickly.

What Else Do You Need?

By centralizing a ticket tracking system on the Internet and publicizing the business opportunity, Linux people should be able to organize a 24 by 7 support business. You'll want to operate it like a project and share the revenues. You should also be able to work with Asterisk to build a global VoIP exchange while clearing payments. I hope you will look into this as Linux is growing and users need support and are willing to pay you for it.