What is Co-Browse?

Velaro Co-Browse lets an agent see what a visitor sees on the visitor's own screen, live, from inside an active conversation. It is built into the chat widget the visitor already has loaded. There is no download, no browser extension and no separate app for either side, and the customer adds nothing to their site beyond the Velaro snippet they already have.

The visitor must agree first, every session. They can pause, resume or stop at any time. Nothing is recorded or stored: the agent watches a live relay that is gone when the session ends. Under the hood the visitor's browser records page changes with rrweb and streams them over SignalR, and the agent's browser replays them.

Co-Browse is never remote control. An agent cannot click, type, scroll, navigate or run anything on the visitor's page, on any plan, and no such feature is planned. Plus adds two things on top of viewing, and both are safe by design: a drawing layer the visitor cannot interact with, and one visitor-approved value written into one eligible field.

Precision note: the widget does not include the rrweb library up front. It loads automatically from Velaro's own CDN when a session starts. Don't tell a customer "nothing new ever loads". The accurate claim is that there is nothing for them to install, configure or deploy.

Page to page: when the visitor moves to another page on the customer's site, the session resumes silently on the new page and the agent's viewer follows. The visitor is not asked again.

Screen share is a different feature. Video chat screen share is visitor-initiated video (the browser's own screen-share prompt). It is not Co-Browse. See video-chat-guide.md.

Plans, priced per agent seat

Co-Browse is a per-agent-seat add-on on Starter and above. Enterprise includes base Co-Browse for every agent at no charge (the Plus features still come from the Plus add-on). Don't tell an Enterprise customer they need to buy base seats.

Plus flags: EnableCobrowseCues (package cobrowse-cues) and EnableCobrowseFormFill (package cobrowse-form-fill) and EnableEnhancedPiiRedaction. All three are bundled only under cobrowse-plus. Don't pitch Plus as a healthcare or compliance feature: enhanced redaction covers email and phone only, not names, addresses or health data.

Seats, not sites

• An account buys N seats of a tier, then assigns specific named agents, or turns on auto-assign for the whole roster.
• An agent without a seat gets a clear refusal. This is enforced on Velaro's servers, not just hidden in the UI.
• Removing a seat unassigns the agent immediately. Unassigned seats are still billed.
• If a customer switches tiers, confirm the old tier's bundle is disabled. The system does not assume it.
• Enhanced redaction, cues and form fill are site-wide flags, not per-seat. Once the site has Plus, every session on the site gets them.

What agents can and cannot do

How to tag sensitive content

Every input is masked and card and SSN patterns are redacted without any setup. For anything else on the customer's pages (account numbers, names, addresses, health details) the customer adds a CSS class to the element in their own page. Nothing to install.

<!-- agent sees the label but only stars for the number -->
<p>Account: <span class="sensitive">8841-22-9017</span></p>

<!-- the whole payment area is blank to the agent and can never be filled -->
<div class="no-record" id="payment-form"> ... </div>

<!-- also accepted -->
<section data-no-record> ... </section>

<!-- shown at the start, later changes not streamed -->
<div class="ignore-record">Live price ticker</div>

Fields inside sensitive and no-record areas are also refused by guided form fill. Customers in regulated industries are responsible for tagging regulated data shown as plain text. For a blanket approach, turn on strict mask mode (below).

Settings (Admin > Co-Browse)

Two things decide what a site can do, and both must agree. The entitlement is what the site's plan or add-on allows. The setting is what the site has switched on. Cues, for example, need Plus and cuesEnabled not Off.

Every on/off setting has three states: Platform default, On, Off. Only administrators and managers can change settings, and every change goes to the Activity Log.

The Session history tab lists who ran each session, when, how long and how it ended (Completed, Declined, Abandoned). It holds no screen content because none is stored.

What Moshky can do

Moshky can read and change every setting above, using the exact names in the table. cobrowse_settings_get returns the site's choices (null means platform default) and the effective values. cobrowse_settings_set replaces the settings: pass the fields to change, and fields left out return to the platform default, so always read first and send the full set. Invalid values are rejected with a reason, hard limits can't be exceeded and every change is audit-logged. cobrowse_sessions_list lists recent sessions (optional limit up to 50 and outcome).

Moshky cannot grant an entitlement. If a customer asks for cues or form fill and the site lacks Plus, tell them it needs Co-Browse Plus ($49/seat) rather than flipping a setting. Staff can also use velaro cobrowse show|set|reset <siteId>.

Troubleshooting

• Agent has no Co-Browse button, or gets "no seat": needs a seat, and if "who can start" is restricted they must be on a listed team or role.
• Cue or fill tools are greyed out: the site lacks Plus, or the setting is Off.
• Guided form fill refused a field: it is a payment, password or one-time-code field, hidden, read-only, or inside a tagged area. Intentional, cannot be overridden.
• Agent sees "Visitor is on a protected page": the URL matches a protected-page pattern. It resumes on its own.
• Session ended by itself: it hit the maximum length or sat idle. History shows which.
• Visitor never sees the consent prompt, or Allow fails: check the Activity Log for the site and escalate to engineering with the conversation id.

Security summary (for "is this safe?")

• No install for the visitor or the agent.
• Never remote control. No click, type, scroll, navigate or execute.
• Consent every session. Nothing is captured before Allow. Pause, Resume and Stop are always on.
• Masked and redacted in the visitor's browser before data leaves it.
• Only the assigned agent with a seat can open a session. Checked server-side.
• Every request, accept, decline, fill, block and stop is audited as a system message, with field labels and reasons but never values.

Public page

Customer-facing detail: https://v20.velaro.com/cobrowse (source: velaro-marketing/cobrowse.html). Help article: https://help.velaro.com/kb/article/1018/cobrowse. Engineering reference: velaro-messaging/docs/architecture/cobrowse-architecture.md.