Ecommerce and Entrepreneurship Blog | About | Contact | Store

Challenges of an Internet Retailer’s VOIP Implementation

Posted on March 20, 2008 by josh’s humble beginnings had us perched around a kitchen table, waiting for the two-line cordless Uniden to ring through our telephone’s Vonage connection.  Yes, we adopted VOIP very early.  As we grew, we found that Vonage was unreliable as a hosted solution and was not scalable. We had grown well beyond our two line capacity.  Consequently, we added several standard Plain Old Telephone System (POTS) lines with basic hunting capabilities to our arsenal and dropped Vonage.  We grew quickly and added a few new POTS lines and customer service personnel as they were needed.  But, we kept growing.

We were faced with a number of issues for a rapidly growing call center.  We had too few lines available for the customers who wanted to call us and our voicemail filled too rapidly.  Also, customers demanded a more sophisticated phone system solution.  The line used to ring in and the first person to pick up the call was your guy or gal; or if all lines were busy, the call went to voicemail, likely resulting in lost revenues and upset customers.  We had an increasing need for more robust routing of calls to qualified reps.  We also needed to allow customers who were willing to hold for a rep, the option to stay in queue, or to leave a message.  We also needed something inexpensive.  So the hunt began.

We requested quotes for several different PBX system solutions (VOIP and nonVOIP), but came up with quotes well beyond our price range.  One quote resulted in a per user deployment cost of $2100 per user!  So, we examined hosted VOIP solutions.  Although the price was better for many services, we could not find a service that satisfied our need for queuing, easily customizable and highly extensible Interactive Voice Response (IVR)/Automated Attendant (AA), and inexpensive scalability.

Finally, we landed on open source VOIP.  We examined two options, Asterisk and SIPX.  Both satisfied our need for queuing, IVR/AA, and both were extremely inexpensive.  What we found as we examined both solutions was that the initial set up was going to be a challenge, since only one person at had limited experience building, deploying, or supporting a VOIP telephone system.  In the end we decided on an Asterisk-based deployment using Trixbox, mainly due to wide open source community support.

What was the cost of the system?  The Trixbox software, which is open source under the GPL, cost $0.  The host computer on which we run the system, a Dell workstation, was $1200.  The VOIP phones, Grandstream GXP-2000, were $90 each (Note: we have since implemented several softphones, $0, with USB headsets, $40: Note, LivePerson gave us several USB headsets for free).  The analog to IP gateway for the phone lines, $676.  The final cost came from dozens of hours of implementation research on Asterisk and Trixbox forums.

Once we had an operational test environment, deployment was relatively easy.  The system worked exactly as expected, with one major exception: Quality was terrible.  During our research, we learned that analog to IP implementations would experience some call quality issues.  In our testing of the system, we had great results; the call quality was approximately equivalent to a cell phone connection.  However, once we went live, we experienced a host of issues.

The biggest issues were echo and static.  Users complained incessantly about “the phones that talk back at them.”  Our particular type of implementation was not widely discussed among the open source community and this made optimization a nightmare.  The quandary was that we were already live with the new solution and did not have a great way to test system changes during optimization for fear that we may cause intolerable system disturbances or, at worst, take the system down completely.  After months of tweaking, we have finally found a reasonable plateau of quality.

The next issue was our VOIP phone selection.  We opted to go with inexpensive VOIP phones to keep costs down.  In hindsight, it may have been better to spend the extra money to get better phones.  The speakerphone did not work well, phones would randomly reboot, and, worst of all, the phones would intermittently drop calls.  Manufacturer support for the phones was positive in that firmware updates are frequent and they appear to attempt to address issues discussed in the community.  However, many of the firmware updates we used created new issues.  We have, however, found a stable version that works well for us.  Also, two of the phones we used locked up and died.  Our supplier,, was great in getting them replaced quickly.

That brings us to today.  Again, we’re faced with an increasing number of users with telephone needs and we still need better call quality.  We’re likely going to transition our digital-to-analog-to-digital lines over to full digital and vastly expand the number of lines available.  That will be Part 2 of “Challenges of an Internet Retailer’s VOIP Implementation”.  In the end, I feel like we did well with our implementation, relative to our goals.  We kept costs to a bare minimum and implemented a system that is fully customizable and scalable.  If we could do it over, I would have probably paid someone to do the initial setup and optimization, then customized our own preferences.  Also, I would not have opted for the cheapest IP Phones possible.

One to grow on…


blog comments powered by Disqus