This blog was co-authored by Dan Shipper and Justin Meltzer
From Traditional Plugins to Next Generation HTML5 Solutions
As the digital revolution continues to spread and customers become increasingly demanding of the companies they purchase products from, large enterprises are transitioning more of their business lines to the Web.
Many enterprises that prioritize customer experience have found that as this trend accelerates, traditional call center technologies like live chat and advanced IVR solutions are not enough to keep up and differentiate in the marketplace. Over the past ten years, many of these enterprises have adopted an additional piece of technology to enhance the customer experience: co-browsing.
When a customer has a problem with a website and calls into a contact center for support, a CSR can use co-browsing to look over their shoulder, see exactly what they’re doing on the website and guide them through the site in real time, all without any downloads or installations for the customer or CSR.
By being able to see exactly what the customer is seeing, CSRs can make an instant diagnosis of the problem the customer is having, and they can help the customer to resolve the issue more quickly by visually guiding them through the site or even driving their browser for them.
When co-browsing first entered the enterprise scene 5-10 years ago, the technology of choice was Java applets. Java allowed for a co-browsing experience that, as a result of its ubiquitous distribution, did not require downloads or installations and worked on most Web sites.
However over time Java applets have been phased out of many computers, and as a result, co-browsing products that rely on Java to enable some or all of their features are no longer adequate to meet the requirements of large enterprises. Here, I explore why Java-based solutions are no longer suitable for customer-facing environments, the differences between older generation Java-based solutions and next generation HTML5-based solutions, and best practices when selecting an HTML co-browse vendor.
Java-based solutions require a download or installation
If the customer doesn’t already have Java installed on their computer they will need to download it, install it and then restart their computer before the agent can co-browse with them. This creates a high-friction experience that eliminates many of the benefits that co-browsing can provide to a CSR.
To make matters worse, over time the percentage of customers that have Java installed will only decrease - meaning more and more customers are going to have to download it during a support call. For example, new Apple computers currently ship without Java for security reasons. Many PC manufacturers are beginning to follow suit as well.
Java-based solutions are insecure.
A solution that uses Java to enable some or all of its features is less secure than next-generation HTML5-based co-browsing solutions. Because Java is not sandboxed to the browser a hacker who compromises an applet can gain access to a customer’s entire computer. This makes applets an appealing target for hackers looking to compromise customer information. In fact, a 2014 study by Cisco found that a shocking 91% of web attacks were caused by Java exploits.
By contrast, HTML5-based co-browsing solutions are sandboxed to the browser and the web page they are run on. This reduces the likelihood of an attack and limits the impact should an attack happen.
Java-based solutions are incompatible with mobile devices
Any product that uses Java to enable some or all of its features will be unable to run on a mobile device. This means that any CSR who is supporting a customer on a mobile website will not be able to assist them with co-browse.
By contrast, all features of HTML5-based solutions are compatible with mobile devices including iPhone, iPad and Android.
What’s wrong with the hybrid approach?
Many older generation Java-based co-browsing providers have responded to the changing marketplace by building “hybrid” products that incorporate Java and HTML5 into a single solution. These companies tout the hybrid approach as superior because it allows the CSR to see outside the browser of the customer and help them with problems that arise on their desktop.
What you may not hear from hybrid vendors is that their Java-based solution is not deployed just when the CSR wants to see the desktop - it is also used to replace the HTML5-based solution on complex websites in older browsers. This is a problem because, while you may get all of the benefits of an HTML5-based solution during a demo, when your product is in a live production environment you will see many of the same issues that traditional Java solutions have.
In order to ensure that a vendor’s solution is truly instant-start and cross-platform compatible you need to ask the following questions:
- Does this solution work without Java on every browser and on every Web site including older versions of Internet Explorer?
- Does this solution incorporate any other type of plugin aside from Java, such as Flash or .NET?
Selecting an HTML Co-Browse Vendor
When selecting an HTML co-browsing vendor, it’s important to understand that companies that once specialized in Java co-browsing technologies do not necessarily fully understand the next-generation HTML5 co-browsing paradigm. The two technologies are so different that they require two different products with different implementation methods and support models.
Finally, unification of software functionality is important as it streamlines deployments and simplifies integration and maintenance. Co-browsing is a product that works extremely well bundled into another application, such as a CRM product or a live chat solution. Make sure that your vendor supports these options - it will make your life easier.
Pega Co-Browse empowers your CSRs to deliver real-time guidance and convert site visitors into profitable, long-term customers.