Live chat, calls and co-browsing: a guide for B2B websites
A visitor with a buying question does not care which channel you offer. This guide works through what chat, a call and a shared page each require, and when each is the right answer.
A website conversation tool is software that lets a visitor reach a person on the team that runs the site, in the page, while they are still on it. On a B2B website it has one job: let a visitor who is deciding reach a person who can answer, without making them leave the page. Everything else, the channel, the widget, the routing, is a means to that. The useful question is not "should we add live chat?" but "what does this particular question need?"
Most comparisons start from the channel and work backwards. That gets the order wrong. A visitor on a pricing page with a question about seat counts needs an answer, and typing may be the fastest way to give it. A visitor who cannot find a setting needs someone to see the same screen. Those are different problems, and the second one is not solved by replying faster.
This guide separates the three things a website conversation can be, what each asks of the visitor, and what you have to decide before offering any of them.
What does a website conversation tool have to do?
A website conversation has to do four things. It has to reach someone who can answer, give that person the visitor's context without asking for it again, let the conversation change shape when the question changes, and leave a record that survives the session. A tool that does three of these pushes the fourth onto your team.
Context is the one most often missed. If a teammate has to ask "which page are you on?" and "what plan are you looking at?", the visitor is doing work the website already knows the answer to. In GreetDock's shared inbox, the page the visitor is on, their visit history and what they asked sit in the same view the reply is written from.
The ability to change shape matters because buying questions rarely stay one size. A question about pricing becomes a question about migration, which becomes a question that is easier to answer by pointing at the screen. If each of those requires a new tool and a new link, most visitors stop at the first handover.
Start with the question, not the channel
Sort the question before you sort the channel. Ask what the visitor is actually missing: a fact, a judgement, or a view of something. A fact is fastest in writing. A judgement usually wants a voice. A view of something needs a shared screen. Choosing the channel first means guessing.
Three rough categories cover most of what arrives on a B2B site:
- A fact. "Does this work with our helpdesk?" Someone types the answer, links the page, and the visitor moves on. A call would be slower for both sides.
- A judgement. "Would you put this on a checkout page or not?" This is a conversation, with trade-offs and follow-up questions. Typing it out takes four messages and loses the nuance.
- A view. "I cannot find the option you mean." Describing a path through a UI in prose is slow and error-prone. Showing it is immediate.
The categories are not fixed, and one conversation can move through all three. That movement is the point: the thing worth building is a path between them, not three separate products.
Live chat: the default, and its real constraints
Live chat is the right default because it is the lowest-effort option for the visitor: no permission prompt, no device check, no scheduling. Its real constraint is not speed but presence. A chat widget is a visible claim that somebody is there, and the claim is either true or it is not.
That claim is worth taking seriously. A contact form promises a reply later. A widget labelled "Chat with us" promises a reply now. If the two are backed by the same staffing, the widget is the one that disappoints, because it set a different expectation. We wrote about what to offer when nobody is free separately, because it is the part most often left until after launch.
Two practical decisions follow:
Where the widget appears. Pages with buying intent, pricing, comparison, product detail, are where a question is worth catching. A blog post or a careers page is usually not. Loading a conversation widget on every page of a large site also means loading it for visitors who will never use it.
What it says before anyone types. "We usually reply in a few minutes" is useful if true and corrosive if not. Hours, and an honest statement of them, do more for trust than an always-on button.
What chat cannot fix
Chat does not make a complicated product simple, and it does not substitute for documentation. If the same question arrives twenty times, the answer belongs on the page. A conversation tool that quietly becomes your FAQ is a signal about the page, not about the tool.
Browser calls: when typing is slower than talking
A browser call is useful when the question needs back-and-forth rather than a sentence. The modern version does not involve a phone number or an install: the visitor accepts a call inside the widget and talks in the tab they already have open. That removes the two things that used to kill escalation, scheduling and software.
The important design question is who starts it and what the visitor is agreeing to. In GreetDock's calls, a teammate offers the call from the thread and the visitor accepts in the widget, with nothing to install. The offer is an offer: declining has to be as easy as accepting, and the conversation has to keep working in text if the answer is no.
Browsers also impose their own rules, and they are not yours to override. A call needs microphone access, and the browser, not your website, asks for it. The MDN documentation on media capture permissions is the reference for how that prompt behaves. Two consequences are worth planning for: a visitor can refuse the prompt, and a visitor on a locked-down work machine may never see it succeed. Both are normal, and both need a path that is not a dead end.
Keep the call short and keep the answer
A call that ends with "I will send that over" has moved the work, not finished it. The useful pattern is to resolve one decision on the call and leave the answer in writing in the same thread, so the visitor can forward it to whoever else has to agree. In B2B that second reader is usually the one who matters.
Co-browsing: showing instead of describing
Co-browsing lets a teammate see the page the visitor is on, so guidance can point at a real screen instead of describing one. It is the right tool when the gap is navigational rather than factual. It is also the option with the most variation between products, so the category name tells you very little on its own.
The variation is in capability and in scope. Some products let the agent click, type and navigate on the visitor's behalf. Others deliberately restrict the agent to viewing and pointing. Some mask sensitive fields by default, some require you to configure which fields to mask, and the masking may happen before transmission or merely on the agent's display. These are not details, they are the whole risk profile, and they differ per vendor.
GreetDock's co-browsing sits at the restrictive end, and states its boundaries: the visitor accepts a request before the page is shared, the team can use a pointer, spotlight and pen, and it cannot click, type or navigate for the visitor. Sensitive input values, other tabs and desktop applications are not shared, and the visitor keeps a visible stop control for the whole session.
Those are GreetDock's documented limits, not a definition of the category. Ask any vendor what their product does on your pages, and test it before you offer it to visitors.
What can a website visitor refuse?
Three things in a website conversation need an explicit yes from the visitor, and they are not one decision: accepting a call, accepting a shared view of the page, and agreeing to be recorded. Bundling them into a single tap makes the agreement less specific and less informed, and it removes choices the visitor should keep.
The reason to keep them separate is practical before it is legal. A visitor who agreed to a call has not agreed to share their screen. A visitor who agreed to share a page has not agreed to a recording that outlives the conversation. Treating these as one consent means the visitor cannot accept the part they want.
In the EU this also interacts with real obligations, and the detail matters enough to deserve its own article: see co-browsing and GDPR for the lawful basis, the scope question and retention. For GreetDock's own boundaries, the security page and the data processing agreement are the documents to read, not the marketing copy.
Declining has to cost one tap
If the only way to refuse is to close the widget, the choice is not real. A request that offers "Accept" and "Not now" with equal weight, and keeps the conversation running either way, gets a more honest answer and loses fewer conversations.
What should the widget do when nobody is free?
Availability is a product decision, not a staffing accident. A small team cannot cover every hour, so the question is what the visitor sees in the hours you do not cover. The options are a queue, a callback, a booked time, or an honest offline form, and they are not interchangeable.
The failure mode is a widget that behaves identically whether or not anyone is there. The visitor types, waits, and concludes they were ignored, which is worse than having been told to email. GreetDock's design shows a call option only while a teammate can answer it, and callbacks and booking in the widget are planned for the beta rather than available today.
This is covered in depth in what to do when nobody is free to answer the chat, including what to put in the widget when the answer is "not right now".
What happens to the conversation afterwards
A conversation that leaves no record costs you twice: the visitor repeats themselves next time, and your team cannot answer questions about what was agreed. The record is the part that turns a conversation tool into something the rest of the business can use, and it is usually evaluated last.
What is worth keeping is narrower than what is possible to keep. The thread, the pages visited, what was asked and what was agreed are useful for months. A recording of every call is a larger obligation than most teams realise, because it has to be stored, found, and deleted on request.
GreetDock's Cloud keeps conversations, calls, transcripts and files as one record per visitor so the history is searchable rather than scattered. The retention question, how long each record type lives and what triggers deletion, is one to settle before you switch recording on, not after.
Where AI helps, and where it must not
The useful line is between drafting and answering. An assistant that drafts a reply from your own knowledge base for a person to review is a speed improvement with a human still accountable for what is sent. A system that answers visitors on its own is a different product with a different failure mode, and it should be bought deliberately, not by default.
GreetDock sits on the drafting side: the AI drafts replies from the customer's knowledge base for a person to review and send, and creates transcripts and summaries of calls the team records. AI processing runs on an EU-hosted model. Teams can connect their own AI tools to their records over read-only MCP tokens, which keeps the access auditable and one-directional.
Three questions separate the two models when you are evaluating any vendor: does a person review before the visitor sees it, where does the model run, and is your conversation data used to train it. The answers should be in writing.
Ten questions to ask any vendor
Most of the risk in a website conversation tool is in behaviour you cannot see from the marketing page. These ten questions surface it, and every one of them should be answerable in writing. If a vendor cannot answer the scope question, the masking question and the retention question, the rest of the evaluation does not matter much.
- What exactly does the agent see during a shared session? The page, the tab, or the whole screen. Ask for the boundary, not the feature name.
- Can the agent click, type or navigate for the visitor? If yes, that is remote control, and it needs a different conversation with your security team.
- Which fields are masked by default, and does masking happen before the data is sent or only on the agent's display? Before transmission is the only version that protects the value itself.
- How does the visitor stop a session? A visible control that is present for the whole session, or a menu item they have to find.
- What does the visitor see before they accept? The request text is the promise. Anything the product can do that the request does not mention is a gap.
- Does a call require an install, a plugin or a phone number? Each one is a point where the visitor leaves.
- What happens when no teammate is available? Ask to see the widget in that state, not a description of it.
- Is anything recorded by default? Defaults matter more than settings, because defaults are what ships.
- How long is each record kept, and what triggers deletion? A per-record-type answer, not "as long as necessary".
- Where does any AI processing run, and is our data used to train the model? Region and training policy, both in writing.
Ask the same ten of every vendor and the comparison writes itself. Answers that arrive as a capability list rather than a boundary are usually a sign the boundary has not been decided.
Choosing: a short decision guide
Start from what the visitor is missing and let that pick the channel. Most B2B sites need chat first, a call path second, and a shared page third, in that order. Each step adds effort for the visitor, so each one earns its place only when the previous one is genuinely too slow.
| The visitor needs | Offer | What it asks of them |
|---|---|---|
| A fact, or a link | Chat | Nothing beyond typing |
| A judgement, or trade-offs | A browser call | A microphone prompt, and their time |
| To be shown where something is | A shared page | An explicit accept, and trust |
| An answer outside your hours | A callback or a booked time | Contact details, and patience |
Two rules make the table work. Never offer a step the visitor cannot refuse without losing the conversation. And never offer a step your team cannot actually staff, because an unanswered offer is more damaging than an absent one.
If you are comparing tools rather than designing a process, GreetDock next to Intercom, Zendesk and tawk.to sets out the pricing models and capabilities side by side, with each competitor claim linked to its source.
GreetDock is built by a team in Vilnius, Lithuania. If this is the shape of conversation you want on your site, you can apply for the private beta.
