The Web inbox is where conversations started on your website arrive.
It is the department inbox
Not a separate thing that resembles one. It is exactly the surface documented in The department inbox, scoped to Web.
That means everything true there is true here: the same buckets, the same assigning, the same snoozing and muting, the same saved views, the same rule that a thread is attached to whoever it is with.
So read that article for how to work it. This one covers what is different about visitors.
What is different about a visitor
They are anonymous until they are not. Most conversations start with somebody you cannot identify, which is unlike almost everything else that arrives in an inbox.
They are on your site right now. An email answered in an hour is prompt. A web chat answered in an hour is somebody who left forty minutes ago.
They came from a page, and that page tells you why they are there. Somebody on your pricing page asking how something works is asking a commercial question. The same words from a support article are asking something else.
All three are covered in depth in Web chat, which is the article about the conversation itself.
Why it is here and not only in Communications
Because the people who look after the website are often not the people who work the support queue, and a conversation started on a marketing page is frequently a sales or marketing conversation rather than a support one.
Having it in Web means whoever owns the site can see what visitors are actually asking, which is the most direct feedback available about whether the site is working.
The same threads appear in Communications, because there is one inbox with different scopes rather than two copies. Answering here answers there.
Speed is the feature
Under a minute, or do not offer chat. This is the single number that decides whether the widget earns its place, and no amount of good answers compensates for a slow first one.
What visitors ask, and what it tells you
Worth reading as a body rather than one at a time.
The same question three times in a week is a website problem, not a chat problem. If people keep asking where pricing is, the answer is a page change. The chat is telling you something about the page it sits on, and fixing the page removes the question permanently.
Questions from the pricing page are commercial. They deserve a fast, direct answer and usually a follow-up.
Questions that are really support should become tickets rather than being resolved and forgotten, because a resolved chat leaves no trace anybody will find later.
The visitor is anonymous until they are not
Most conversations start with somebody you cannot identify, which changes how the first minute should go.
Ask for a name and a way to reach them early, and naturally rather than as a form. A conversation ending with no way to follow up was worth very little however well it went, and asking at the end feels like a toll gate.
Once they identify themselves the thread attaches to the person like any other, and their history is there. Worth checking before explaining something they already own.
Answer, then qualify
The instinct is to establish who somebody is before helping. It loses people. Answer the question first; the qualifying comes naturally once they have a reason to keep talking.
Turning a conversation into something
A chat that goes somewhere becomes a lead, a ticket or a booking.
It does not become a deal on its own. Nothing inbound does, anywhere in NearSync. A visitor asking about pricing is a lead until a person decides otherwise, and that restraint is what keeps a pipeline worth forecasting from.
It is one inbox, not two
Answering here answers in Communications, because it is the same thread viewed through a different scope.
That matters when web and support are different teams: both can see the conversation, and the assignment says who owns it. What it means practically is that nobody should be copying anything between them, and if somebody is, the scope is set wrong rather than the process.
Staffing it honestly
The one decision that determines whether any of this is worth having.
Answer within a minute or do not offer chat. An unanswered widget converts a visitor who might have emailed into one who feels ignored, and they were on your pricing page when it happened.
Set the hours to when somebody is actually watching. A widget available at midnight makes a promise on your behalf that your organisation does not keep.
Give it to a named person per shift. A queue everybody can see is a queue nobody owns.
Two habits
Look at the page before the message. Two seconds of context changes the first reply, and the first reply decides how the whole conversation goes.
Move channel when chat stops suiting it. Anything needing a document, a long explanation or a third person is better as an email or a call. Say so and move, rather than conducting something complicated in a small box while the visitor loses patience.
Turning a chat into a record
Most conversations should leave something behind, and by default they do not.
A question that will recur is a knowledge base article. See The public knowledge base.
A problem is a ticket, so it is tracked rather than resolved and forgotten.
Interest is a lead, with a way to reach them.
Nothing at all is a legitimate outcome for a one-line question, and forcing every chat into a record is how a CRM fills with noise.
Where the setup lives
Not here. The widget itself, where it appears, its hours, its greeting and its intents are all configured in Operations. See Web chat and chat intents.
That split is deliberate and consistent across the product: setup lives in Operations, the daily work lives in the HQ that owns it.
Did this answer your question?
No, ask a person