Linux on the Desktop—Lessons Learned

Enova has always been a pro open-source company. While we have had great success using open source projects to deliver our web-based platform, we always look for innovative ways to push it even further. In 2010, we achieved a long-time dream of running Linux on the desktop for the systems used by our customer service representatives (CSR’s). We even gained recognition from this project from the prestigious CIO magazine.

There recently have been a couple of articles on the challenges of a Linux Desktop. We have been running Linux on the desktop since 2010, and after a couple of years of experience, we wanted to share some of our lessons learned along the way. Overall the experience has been very positive, but like with most projects, there have been some bumps along the road. Our intention is to share these bumps with you, so that like-minded companies can take that leap into Linux on the desktop, while trying to avoid some of the pitfalls that could arise.

Lesson Learned #1 – Just because you can go smaller, doesn’t mean you should.
Our Linux distribution has been customized and tweaked to fit our CSR’s limited needs, so much so that initially we determined that we could greatly drive down the cost of the workstations by skimping on luxury items such as RAM and CPU. For over a year, this strategy worked well. But, as our company grew, so did the demands on our CSR’s, which in turn grew the compute demand needed for the CSR’s to complete their tasks in a timely manner. Because of this increased demand, we changed out the CSR workstations twice, while upgrading various components. We also made various upgrades to the servers on the back end, which handle and distribute the desktop image to the workstations. The key take away here is that just because you can run a workstation within 1GB of RAM doesn’t mean you necessarily should. If you can afford workstations that have, for example, 4GB of RAM, you should consider doing so from the beginning.

Lesson Learned #2 – Be wary of which manufacturer you partner with to provide low-cost workstations.
The first two workstations we used weren’t made by brand name manufacturers. We were attracted to their low cost, form factor, and ability to be customized. This worked until we started having supply problems. Getting replacement parts and new workstations have recently become challenging, so now we’re investigating alternate solutions from larger manufacturers who won’t be as susceptible to supply issues. This is a similar pain point that we have experienced on the server side of our environment, which was also corrected. The key take away here is that it’s okay to not use a brand name manufacturer, but I would suggest doing a little more homework on their supply chain beforehand. It’s not a fun day when you’re scrambling to find workstations to keep up with the demand of a growing company.

Lesson Learned #3 – There are limited options for softphone clients.
We’ve had various issues getting softphones to work well within the environment. We actually have a bit of flexibility with the options available because a large part of our phone system is based off of Asterisk, which is also an open-source solution. We have also done various A/B testing with the headsets the CSR’s use and continue to tweak the options available there as well. The key take away here is to evaluate all of the different softphone and headset options beforehand, while thinking about how you’re going to integrate your workstations to your telephony environment.

Lesson Learned #4 – Different CSR’s work differently.
Within our call center environment, there are different types of CSR groups who interface with different systems to provide excellent customer service. Some of the CSR’s handle outbound requests, some handle inbound requests, some are application support based, etc. What we found is that based on the CSR’s role, they tend to work differently and have slightly different needs. One CSR might have 30 tabs open in a web browser, while another CSR might have 15 different web browser windows open. Some users might need to interface with cloud-based solutions, while others might need something like Java to perform their task. The key take away here is that in our case, a one-sized workstation might not fit all. While it would be ideal to deploy a single type of workstation for everyone, it might not be practical for your environment.

Lesson Learned #5 – Keep the experience as close to what CSR’s were previously used to.
A large portion of our CSR’s need a web browser and a soft phone to complete their tasks. This makes a transition to a Linux desktop rather easy. However, there are various window managers out there, and you’ll want to do some testing with your CSR’s to find one that feels familiar to them. The worst thing you can do with a Linux on the desktop deployment is decrease CSR productivity by having them look for the ‘Start’ button in the bottom left. It’s also very important to seek feedback from the CSR’s while you’re developing the solution. The other key take away here is that user training before deployment is a must. We initially provided training, which we believe helped enable a successful transition. We also offer various training videos and frequently update documentation as we make changes to the system.

If working on projects like this peaks your interest, we’re always hiring fantastic people.