Does Your Software Company Answer the Phone? [On Atlassian]

This is the first in a series on running a software business. Some of these are specific to running a software company like Atlassian, and some will apply to any business.

Answering the phone is one of those tasks companies often give little thought. Yet it can say so much about what kind of company you are and how you treat customers.

We have decided not to install an automated system, or IVR. We never really gave an automated system any thought until recently some people suggested we might consider it. Scott and I talked and both felt strongly that the company needs a personal touch. This is not a trivial decision for Atlassian when you have over 5,500 customers.

Once we made the decision to stick with humans, I realized how rare this is today in smaller companies, or any company, for that matter. But it’s not without its challenges. We don’t have a lot of administrative people, so right now, we share the responsibility between admin, sales support, pre-sales, marketing, and our customer advocates.

Some days in San Francisco the phone rings almost non-stop, and juggling customers with your normal workload is difficult. We have a number of days where we hit 70 phone calls. Most of these come before Noon due to our East Coast and European customers, so their timing is not nicely distributed.

I tell all employees that regardless of your job, it’s a good practice to jump in and answer the phone periodically, and find out why customers call. In our business, when you sell over the Internet and have virtually no outbound sales force, there is a dark side: you don’t talk to customers unless they call. So you need to take advantage of this opportunity instead of viewing it as a burden.

I also suggest to employees that, if the opportunity is there, to ask a few questions and learn something about the customer’s business and how they use our products. One five-minute phone exchange becomes a valuable morsel of data and even a shred of a relationship. Customers appreciate just knowing someone got their request and that someone is trying to solve their problem. I have never had a customer not want to answer a question; they are invariably interested in talking to someone behind that product they use.

The vast majority of calls are sales-related or technical support. Interesting things happen when you just pick up the phone. Here are three examples of my random answering of the phone:

• A woman from the University of California San Francisco was inquiring about consulting because they needed to solve some problems. My initial concern was about her satisfaction with our technical support or Confluence. But she quickly told me she loved our product and while they had some issues, UCSF intended to roll Confluence, our enterprise wiki out to the entire student population. What struck me was that UCSF is entirely a medical school, and this use was very exciting.
• About a year ago the CTO of Abercrombie & Fitch called, “This is not an angry customer call, but…”. My heart jumped. It turned out he was a second time customer, a supporter of our products, and simply needed priority put on a technical problem so he could roll out the wiki.
• One day a fellow from the US Army Intelligence and Security Command (INSCOM)) called to ask some questions. He mentioned that our product had been recommended by folks from SAIC, a large government contractor, which has a group that works exclusively in the intelligence community. We knew at least one intelligence agency used our products, but we did not appreciate to what extent. Thanks to this phone call, we discovered a considerable number of licenses being used for several agencies. Of course, we’ll never know for what purpose. ☺

I would never have had this information if it were not for the random customer call.

Answering the phone can be a source of debate in an engineering culture like ours. Engineers like issue trackers for capturing customer requests and support issues because the automation benefits save time and can result in faster, better support. Can’t argue with that. Engineers are inherently more comfortable with email and IM. One of our engineers have been known to unplug his phones.

People communicate different ways. Not every customer wants to rely on written communication. Making our company available by phone is hard to do, but we hope it makes a difference.

Is Mediawiki an Enterprise Wiki?

If you want an excellent description of what is entailed in making Mediawiki into an enterprise wiki, David Strom reports useful, practical information for anyone evaluating enterprise wikis. Harvard Business School professor Andrew McAfee’s orignial blog on Avenue A/Razorfish’s wiki was an interesting case study, but it didn’t reveal these important points that Dave Strom surfaced:

1. Razorfish has one full-time intern and two part-time developers that maintain their code.
2. Razorfish put in place some code that pulls information from their Active Directory servers (that) enables single sign-on.
3. Security matters a lot.
4. Part of the custom code they wrote was to enable search across all wiki and blog content.
   

It strikes me that if Razorfish invested all this effort and money, then the question needs to be asked: Is Mediawiki an enterprise wiki? Certainly not out of the box.

One full-time intern and two part-time developers is at least $50-100K for one year! Probably the latter number. Mediawiki in this instance became an enterprise wiki but only after considerable work.

Although this case study exemplifies how companies can fulfill the promise of open source, this is not fulfilling the promise of Enterprise 2.0 software which should be: lightweight software suitable for enterprises for dramatically less money.

This case study points out about as well as I can imagine the difference between the open source option for wikis and the commercially sold enterprise wiki such as Socialtext, Brainkeeper, or our Atlassian Confluence.