Beyond Chat: Escalating to Voice, Video and Co-Browsing

Escalate beyond text when the problem is visual, spatial, or when describing it costs more than showing it. Three signals reliably justify it:

• The customer cannot describe what they are seeing. "It says an error" after three exchanges means text has failed.
• The task has steps the customer must perform. Configuration, form completion, settings changes - guided is faster than instructed.
• The value at stake justifies the agent minutes. A high-value order or a churn-risk account earns a call; a delivery-status question does not.

What matters as much as when is where. If escalation means "here is a Zoom link", you have introduced a scheduling problem into a live conversation, and a meaningful share of customers will not follow.

Think of support modes as rungs, each with a higher cost and a higher resolution power:

The mistake is jumping rungs. Offering a video call for a question the knowledge base answers wastes an agent; forcing a customer through six chat turns for something co-browsing would solve in ninety seconds wastes both.

The technical decision that determines whether escalation actually gets used is whether the customer has to leave the conversation.

Modern browsers support real-time voice and video natively through WebRTC, which means a call can start inside the same chat widget the customer is already using. No install, no meeting link, no dial-in, no account. The customer clicks accept and is talking to the agent.

The alternative - pasting a third-party meeting link - introduces four failure points: the customer must click out, possibly install something, possibly sign in, and find their way back if it fails. Each one loses people.

On Conferbot, voice and video calls run peer-to-peer over WebRTC with the signalling handled by the platform itself rather than a third-party calling vendor, and both are off by default per chatbot so you enable them deliberately rather than discovering them enabled. Call start, end, duration and outcome are written into the conversation record, so a call appears in the transcript instead of vanishing from the history.

Co-browsing is the highest-resolution rung and the one most teams avoid, usually for a good reason: watching a customer's screen while they type a card number is a data-protection incident waiting to happen.

The fix is field masking, applied before anything is transmitted. Sensitive inputs are matched by selector and blanked on the way out, so the agent sees the page layout and the customer's progress but not the protected values. Typical masked selectors cover payment fields ([autocomplete*=cc-], [name*=card]), passwords, and anything else you designate.

Three controls make co-browsing safe to offer:

1. Visitor approval. The session starts only when the customer explicitly accepts, every time.
2. Field masking by policy. Defined centrally at workspace level with sensible presets - an e-commerce preset masks payment fields by default - and overridable per bot.
3. Remote control as a separate permission. Viewing is one thing; letting an agent click on the customer's behalf is another, and it should be a distinct decision.

Set the masking policy before you enable the feature, not after the first incident.

The offer itself decides whether escalation converts:

• Offer it, do not force it. A button the customer can ignore beats an automatic call invitation.
• Say what it will do. "Share your screen so I can see the error" converts better than "Start co-browse session", which sounds like software.
• Preserve the transcript. The agent should join already knowing what the bot covered - starting a call with "so, what's the problem?" wastes the entire automated conversation.
• Give an exit. Ending the call should return to chat, not close the conversation.
• Log the outcome. If calls do not appear in your analytics you cannot tell whether they resolve anything.

Also decide in advance who can escalate. Every agent offering video calls for routine questions will destroy your cost-per-contact.

Voice, video and co-browsing consume agent time serially, so they need to earn it. The metrics that answer the question:

• Resolution rate by mode. If co-browsed sessions resolve at a materially higher rate than chat for the same issue category, the cost is justified.
• Time to resolution, not handle time. A twelve-minute co-browse that ends the issue beats four chat sessions across two days.
• Repeat contact rate. The clearest signal that a mode actually solved the problem.
• Satisfaction by mode. Track CSAT split by escalation type; some audiences dislike video regardless of effectiveness.
• Escalation rate per issue category. Categories that escalate constantly are telling you where the product or the documentation is broken.

That last one is the most valuable output. High escalation on one category is a roadmap item, not a staffing problem.

Start narrow. Enable one escalation mode for one issue category where you already know text is failing, measure resolution and repeat contact for a month, and expand only where the numbers support it.

If you are running Conferbot, voice and video are per-chatbot settings that default to off, and co-browsing masking policy is configured at workspace level with per-bot overrides - so you can pilot on a single bot without changing anything else. Escalation sessions are recorded as first-class objects with their own lifecycle, so the analytics exist from day one.