Skip to content

How a conversation is handled

Every new conversation starts in bot mode. The bot answers from the Docs section of your workspace — only docs with status published; drafts are ignored. It’s given the list of your published doc titles up front, and is instructed to search your docs and read the best matches in full before answering any product-specific question.

That’s why many small, focused docs work better than one long page, and why the question your customers actually ask makes a good title.

Your own system prompt (Settings → Bot system prompt) is layered on top of your docs, and the model is whichever you pick on the Settings page. If no working model is configured, the visitor gets a canned “one of our operators will reply shortly” message instead — a human reply from your Chats page still reaches them live.

A conversation is in one of two handling modes:

  • bot — the bot answers each visitor turn.
  • human — the bot stands down entirely and your team answers.

Replying is taking over. The moment you send a reply from the workspace Chats page (or the mobile app), the conversation flips to human mode and the bot stops answering. That’s deliberate: two voices answering the same visitor is worse than a slow reply. The visitor’s widget shows a line saying “Name from the team has joined the chat”, live, with no refresh.

If a different operator replies to a conversation another one already took over, the baton simply passes to them — the visitor isn’t told again.

“Hand back to bot” returns the conversation to the bot for subsequent turns. The visitor sees “You’re back with the assistant.”

Your reply can be up to 4,000 characters and carry up to 5 attachments. You can also ask the visitor for a screenshot of their page — they get a consent prompt and nothing is captured unless they agree.

The bot has a tool for this. It calls it when the visitor asks to talk to a person, says the bot isn’t helping, or raises something the bot shouldn’t decide on your behalf — billing disputes, account access, anything that would amount to a promise made for you. Along with the flag it passes a one-sentence reason describing what the visitor needs, so an operator has context before opening the chat.

What happens then:

  • The conversation joins your workspace’s queue. It shows a “wants a person” marker on the Chats page (the reason is the marker’s tooltip), and there’s a Waiting filter on that page.
  • Your operators are notified, including a push to the mobile app.
  • What the bot says next depends on whether anyone is actually around. If at least one person who can answer chats has been active in the last five minutes, the bot tells the visitor someone is coming and stays with them. If nobody is online, it says the team will follow up and asks for an email address to reach them on — promising a person who isn’t there is worse than saying so plainly.

Asking twice in the same conversation doesn’t reset the request, so a repeated ask can’t jump the queue. Taking the conversation over answers the request and removes it from the queue.

Either side can end it:

  • The visitor ends it with /end, with the AFK countdown, or by closing the panel after they’ve sent at least one message.
  • You close it with Close chat on the transcript page.
  • Vroxy auto-closes it after your configured inactivity window (below).

Whoever closes it, the visitor’s widget updates live: the composer disappears and the transcript shows “This conversation has ended.” with a Start a new chat button. If they participated in the conversation and haven’t rated it yet, they get the 0–5 star rating prompt first.

An ended conversation is read-only. A message posted to it is refused with “This chat has ended. Start a new one.” The transcript stays in your workspace, and the visitor can always start a fresh conversation.

Settings → Chat auto-close → “Close inactive chats after”. The options are:

  • Never
  • 8 hours
  • 24 hours
  • 3 days — the default
  • 1 week

Vroxy checks hourly and closes any open conversation whose last message is older than your window, recording the close as a system close. Up to 500 conversations per workspace are closed per pass, so a large backlog drains over successive runs rather than all at once. Visitors can always start a new conversation afterwards.

This is separate from the widget’s own idle handling, which offers a “Still there?” countdown after three minutes of inactivity while the panel is open.

Baked in, no configuration:

  • 60 messages per visitor per hour.
  • 500 messages per workspace per hour, across all visitors.

When a limit trips, the message isn’t posted and the widget shows “⚠️ Rate limit exceeded — try again shortly.” in the conversation. The composer stays usable, so the visitor can retry once the window rolls over.