Co-browsing, short for collaborative browsing, lets a customer and a support agent work together in a shared web browsing session. Depending on the product and permissions, the agent may point to elements, navigate, or enter information. The scope of that interaction is different from simply watching a screen share and from controlling an entire remote computer.
Those distinctions matter when evaluating a tool. A customer’s browser session may include forms, account information, third-party content, and actions that should remain under the customer’s control. This guide explains the technology, practical uses, privacy questions, and how to test a proposed implementation.
Co-browsing, screen sharing, and remote control are different
| Approach | What the agent works with | Control to verify |
|---|---|---|
| Co-browsing | A shared web session or supported application view | Whether the agent can point, navigate, or edit under the configured permissions |
| Screen sharing | An image of the selected screen, window, or tab | Observation does not itself grant mouse or keyboard control |
| Remote control | A device or application through an explicitly provided control feature | Which actions and device areas the authorized session allows |
| Video conversation | Camera and audio, with other capabilities only if provided | A video call does not itself establish browser or device control |
These categories can appear together in one product, but do not infer one feature from another. A screen-sharing tool may have a separate remote-control option, while a co-browsing tool may restrict particular fields or actions. Check the exact feature and configuration.
For Screendesk specifically, its live-call comparison documentation states that agents can see a customer’s shared screen but cannot control their mouse or keyboard. The customer executes the actions and can stop sharing. Screendesk’s guided screen-sharing workflow should therefore not be described as agent control of the customer’s browser.
Installation requirements also vary. Browser-based screen sharing can work without an extension, and co-browsing can require website integration even when the customer installs nothing. “No customer download” and “no implementation work” are separate claims.
How a collaborative web session works
At a high level, the product establishes a session, provides participants with the relevant shared view, and coordinates permitted interactions. Its implementation determines where the application is loaded, what information is transmitted, and which pages or controls are supported.
The Document Object Model, or DOM, is the browser’s structured representation of a document. Scripts can use it to work with page elements and their content. That helps explain terminology such as element masking or page restrictions, but does not mean every co-browsing product uses the same synchronization architecture.
For one current vendor example, Surfly’s technical documentation describes JavaScript combined with a content-rewriting proxy. The proxy modifies returned content so it can load in an iframe for participants to interact with. Its session overview documents highlighting, scrolling, clicking, typing, and control handover. These are Surfly-specific descriptions, rather than universal properties of collaborative browsing.
Ask the implementation owner to explain the actual data flow in your proposed setup. Website changes, authenticated sessions, external domains, embedded frames, and dynamic controls can affect whether the workflow behaves as expected. A demonstration on a simple public page does not establish compatibility with your application.
Where co-browsing may fit a support task
Consider it when the task is in a supported web session and shared interaction would help the customer complete the task. Keep the requested action, the customer’s authority, and the product’s permissions distinct.
| Illustrative task | Potential use of shared browsing | Boundary to check |
|---|---|---|
| An online application form | Explain the field and identify missing information | Who enters personal information and who submits |
| An account portal | Guide navigation to a relevant option | Account permissions and changes the agent may make |
| A shopping task | Compare available product information | Payment entry and purchase confirmation remain in the approved process |
| A scheduling portal | Explain the visible options | The agent does not infer eligibility or override an unavailable slot |
These are hypothetical uses, not case studies or predicted business results. In a financial or healthcare setting, the organization also needs its own approved process for sensitive information and consequential decisions; a feature label does not establish that process.
If the issue concerns a desktop application, a camera view of a physical object, or an asynchronous explanation, another visual support mode may fit better. See remote visual support for workflow selection across these different needs.
Text or chat remains useful for exact instructions and simple questions. A chatbot, if used, needs a route to an agent for unsupported requests. It does not need to be the starting point for every collaborative session.
Check what is visible, editable, and recorded
Visibility and action permissions are separate requirements. Ask which data the agent can see and which actions the agent can perform. Test both from the participant’s actual role.
Surfly’s masking documentation distinguishes hiding HTML elements from concealing form fields for following participants. It also documents a limit: masked values placed in GET forms or URLs may still appear in audit logs or browser network activity. Visual masking therefore does not establish that a value is absent from every data channel.
Before using a tool with real requests, define the information that should remain outside the session. Use controlled example values to test the configured page, dynamic states, recordings if enabled, and relevant logs. When the application changes, recheck the affected rules rather than assuming a selector still matches the same field.
Evaluate the complete configuration with the people responsible for security and data handling. Ask for the actual transport protection, authentication, access controls, storage locations, retention settings, and any session recording or audit behavior. Do not substitute a generic “high security” rating for those answers.
Describe the experience accurately to the customer: what is shared, what the agent can do, how to stop, and whether anything is recorded. Avoid promising that an entire session is private or compliant based only on a vendor’s category or a masking option.
Test the complete task before choosing an implementation
Use a representative task with an intended customer device and an agent role. Include the steps that matter in your application, rather than only checking that a session can start.
Co-browsing evaluation task Customer task and intended audience: Supported application and required access: Entry point and agent handoff: Browser/device combinations to test: Pages, frames and external destinations involved: Expected agent visibility: Expected agent actions and restricted actions: Sensitive example fields and masking expectations: Recording/logging behavior to inspect: Customer stop/revoke/end controls: Fallback if the task is unsupported: Pass evidence and unresolved gaps:
For a fictional test, use a training form with a public field, a confidential field, a validation error, and a final confirmation. Check whether both participants see the expected page state, whether the confidential example behaves as configured, and whether the agent can perform only permitted actions. Stop or revoke access using the customer controls and verify what happens.
Test reconnecting and ending the session. An interruption should have a defined support route; the customer should not have to guess whether the agent is still present. Check relevant device and browser combinations without claiming that one successful desktop test establishes all mobile support.
Verify the helpdesk integration separately. Establish how the session is associated with the case, which notes or links appear automatically, and which information the agent must record manually. Do not infer that a CRM history or complete transcript is synchronized simply because a launch button appears in the helpdesk.
Introduce the workflow and evaluate actual results
Train agents on the decision to offer a session as well as its controls. Practice explaining the scope, respecting the customer’s choices, recognizing an unsupported action, and closing with a written next step.
Begin with a defined task and review its evidence. Track whether customers can join, whether the application works within the session, whether the needed action is completed correctly, and whether any handoff remains. Record failure reasons separately: access, compatibility, unclear procedure, or product defect.
First-contact resolution, handling time, satisfaction, and task completion may provide operational context. Define the population and compare suitable cases. A change after introducing co-browsing does not by itself show that the tool caused it, and a shorter interaction does not establish a correct result.
Include implementation, training, maintenance, and session work in a cost assessment. Use your own measured evidence rather than a universal handling-time reduction or promised conversion increase. Review agent feedback too: repeated difficulty may call for a process correction instead of another tool feature.
Frequently asked questions
Can an agent control the whole computer through co-browsing?
Do not assume that. Check the product’s exact scope. Shared browsing interaction and remote device control are separate capabilities, and the permissions should be explained explicitly.
Does co-browsing always work without installation?
Customer downloads, website integration, browser requirements, and agent setup vary by product. Verify each requirement for the proposed workflow.
Does masking make the session automatically compliant?
No. Check the configured visibility, data flow, access, logging, storage, and your organization’s requirements. Masking is one capability within that wider assessment.
