Case Study | Support Portal: Ruckus Wireless
Driving Efficiency in Global Support Background Ruckus Wireless is a pioneer in the wireless infrastructure market. They enable carriers and enterprises to stay ahead of the exploding demand for high-bandwidth applications and services. Based in Sunnyvale, CA, they have over 1,000 full-time employees and 300 contractors - all of whom they want to connect by single corporate intranet with federated search access to documents across the organization. Ruckus elected for a phased deployment, starting with their Global Support division. Led by Giri Iyer, the Global Support team includes over 100 Support Engineers with major concentrations in Sunnyvale and Bangalore, as well as a distributed team of Subject Matter Experts based around the world.
SUMMARY BUSINESS NEED Due to the multiple content repositories being used, Ruckus’ engineers were not focusing on new problems that arose because they were wasting time searching or creating redundant content.
WHAT WE DID
RESULT As with any large enterprise, Ruckus has numerous tools that generate content (Salesforce, SAP, Jira, Confluence, Sharepoint, etc.), so it is challenging to find information across all the various data sources. This is especially true for Support Engineers tasked with resolving customer support cases that are often times similar, if not totally identical, to one another. Since Support Engineers typically have to recreate customer issues in their local environment before they can be resolved, the reuse of existing knowledge is strongly encouraged whenever possible. Unfortunately, too often times the information either couldn’t be found or wasn’t presented in a way that could be easily understood, so there was a constant “recreating of the wheel”.
We implemented the Google Search Appliance with connectors out to Salesforce , Office 365, Jira, and Confluence.
Ruckus’ vision was that Search would be the primary backbone of their Knowledge Center Support (KCS) portal, where known problems would be solved either through customer self-service or by Support Engineers doing their own triage quickly and efficiently – versus the same Engineer spending 3-4 hours in the lab trying to recreate a problem that has already been solved.
ACCOMPLISHMENT
At the time, however, the existing keyword search was very frustrating, as relevant documents simply did not get returned. There was also no federated search function, so Support Engineers would often have to sift through multiple content repositories to properly answer a single incoming support ticket.
+ Increased customer satisfaction + A more productive and efficient team of engineers