Genesys Co-browse Sessions
A session is initiated when a customer requests to co-browse. The session stays idle until the agent joins. Then the session is considered to be active. The session ends when one of the parties (the customer or the agent) exits. It is not possible to re-join a co-browse session. If one party exits accidentally, a new session must be initiated.
Each live session has two identifiers that can be used to track the session:
- Session access token (Session ID) — A sequence of nine digits that is applicable only to live sessions.
- History session identifier (UUID) — A session identifier in the database.
Starting and Stopping a Session
A co-browse session can only be initiated by a customer. An agent does not have the option or ability to send a co-browse request to a customer. This provides greater security to the customer. In order to initiate a co-browse session, the customer must already be engaged in an interaction with an agent, be it a voice call or a chat.
When the session is established, the agent's browser displays a view of the customer's browser. The view the agent sees is loaded from Genesys Co-browse Server, so only certain images might be loaded from the original website. The agent is not a client of the website. All actions taken by the agent are passed onto and "replayed" on the customer's (also referred to as the "Master") side.
Initiating a co-browse session from a voice call or external chat without integration
If a customer and agent are engaged in a voice call or external chat without integration, a co-browse session can be initiated by the customer if the need arises. For example, the agent might be trying to walk the customer through how to submit a specific form, but the customer is having issues understanding where the agent is directing him or her to go on the page. In this scenario, the agent might suggest they engage in a co-browse session. While the agent can verbally suggest a co-browse session, the customer is the one who must initiate the session.
By default, there is a "Co-browsing" button on the left side of every web page that supports co-browsing. Note that the location on the page can vary, depending on configuration. When the customer clicks this button, they are presented with a message window asking them to confirm that they are engaged in a voice call with a representative.
If the customer selects "No", a new message advises them to either initiate a voice call or a chat in order to co-browse.
If the customer selects "Yes", an alpha-numeric session identifier appears on the customer's screen.
This identifier can then be read to the agent over the phone or the customer might have to send the session ID through their external chat window. The agent enters the session identifier in the appropriate field in Interaction Workspace, and then the customer's browser is displayed in the agent's view. There is no need to navigate to the web page the customer is viewing; the session identifier ensures the exact page is embedded in Interaction Workspace for the agent. The customer is notified on his or her screen that the session has been established.
Initiating a co-browse session from an integrated chat
A co-browse session can also be initiated by the customer if the customer and agent are engaged in a chat. Genesys Co-browse has a pre-built html chat client that is embedded directly into the website, so that the chat window is integrated into the browser window the customer is viewing. The customer can use this chat client by clicking the default "Live Chat" button on the left side of every web page that supports co-browsing. Note that the location on the page can vary, depending on configuration. When the customer clicks this button, they initiate a chat session with a representative.
The chat window might include a "Co-browse" button or the customer might click the default "Co-browsing" button (name and location can vary, depending on configuration). As in the previous example, a session identifier will be assigned and displayed. Depending on the configuration, the customer might have to send the session ID to the agent through their chat window, or the session ID might be sent to the agent's desktop automatically. Once the session ID has been entered in the agent's desktop (either manually by the agent or programmatically by the application), the session is established.
Stopping a co-browse session
Once a co-browse session has been established, both parties have the ability to terminate the session. At any time, either party may click the "Exit Co-browse session" button (again, the name and location of this button can vary).
The other party will be notified that the session has ended, and the agent's browser will no longer display a view of the customer's browser. Also, if the primary interaction (chat or voice call) is terminated, the co-browse session will be terminated automatically. Sessions can also terminate due to inactivity, after a preconfigured timeout expires. Likewise, if the agent closes their browser, or navigates to a third-party website, the session will terminate if agent does not return back to the session page within the preconfigured timeout.
Once a session has been terminated, it cannot be reactivated. If the session was deactivated accidentally, a new session has to be initiated, with a new session identifier.
Participating in a Co-browse Session
When a co-browse session is active, both the agent and the customer have the right to perform conventional user actions at the same time. Both the agent and the customer are in "write mode" during the session. This means that both the agent and the customer can enter text, click buttons, and so on.
All actions (mouse clicks, key presses, and so on) are actually performed on the master (customer) side. Any actions taken by the agent are sent to the customer's browser. This ensures a secure approach, as all browsing is done on one side—the customer's side. This approach also provides for greater performance and a more seamless customer experience. Each participant can see the other participant's mouse movements as well. This enables an agent to point to specific sections on the web page to help direct the customer through their task.
Administrators can limit which fields are visible to and editable by the agent. Some fields might be grayed out entirely, and some might have the data masked. For example, administrators might choose to hide the customer's password, Social Security Information, and so on from the agent. The customer can easily identify which information is hidden from the agent. By default, all
Submit buttons are deactivated for the agent. If he or she clicks on a
Submit button, nothing happens. The customer always has permission to submit any web forms, just as they would while browsing normally.