What to do when nobody is free to answer the chat

An unattended chat widget is a chat widget that stays visible and accepting messages during hours when no teammate is there to answer. It is a promise that someone is available now. When nobody is, the visitor does not experience a queue, they experience being ignored, which is a worse outcome than a contact form that never claimed otherwise. The fix is not more staffing. It is making the widget tell the truth about the hour it is in.

This is the part of a live chat rollout that gets designed last, usually after the first week of unanswered messages. It deserves to be designed first, because it determines what most visitors see. A small B2B team covers a working day in one timezone, and the website is open all of them.

Is an unattended chat widget worse than no chat?

The cost is the gap between what the widget implies and what happens. A contact form sets an expectation of a reply later and meets it. A widget labelled "Chat with us" sets an expectation of a reply now and, outside your hours, breaks it. The same message, sent through the same team, produces a worse impression through the wrong container.

Attention is the mechanism. Jakob Nielsen's three response-time limits put roughly 10 seconds as the limit for keeping a user's attention focused on a dialogue. A chat window is a dialogue, and it is the only thing on your site that opens one.

There is a second cost that is easier to measure: the message often goes nowhere. A conversation started at nine in the evening lands in a tool nobody opens until morning, by which time the visitor has either solved it or chosen someone else. The transcript survives, the opportunity does not.

Neither cost is about speed. Both are about a promise that the interface made on your behalf.

Decide what each state looks like

A widget has at least three states, and each needs its own design: someone is free, everyone is busy, and nobody is working. Most tools ship the first and leave the other two as a toggle. Treat them as three products and the problem becomes tractable.

Someone is free. This is the only state in which an immediate-response affordance is honest. If you offer a call, offer it only here.

Everyone is busy. Someone is working but cannot answer yet. The useful signal is position and expectation, not an apology. The visitor can decide to wait if waiting is bounded.

Nobody is working. The honest version names the next time a person will be there, and offers something that works in the meantime.

The common failure is collapsing states two and three into one "we will get back to you". They want different things from the visitor: in state two they may wait, in state three they will not.

What should you offer when no agent is available?

Offer the visitor a way to finish the task on their own schedule. The three that work are a callback at a named time, a booked slot in your real calendar, and a written answer sent to an address they give you. Each asks for something small and returns something specific.

Ranked by how much they respect the visitor's time:

• A booked time. They pick from your actual availability and get a confirmation. Nothing is left to chance on either side.
• A callback request. They give a number and a window. This is lighter than booking, and it works well when the question is short.
• An offline message. The fallback. It is only honest if you state when a reply will arrive and then meet that.

In GreetDock's design the call option appears only while a teammate is taking calls with the inbox open, so the affordance is not shown in a state where it cannot be honoured. Callbacks and booking in the widget are planned for the beta rather than available today, which is worth stating plainly rather than implying.

Write the offline message like a person

The default text in most tools is a placeholder, and it reads like one. Replace it with three facts: that nobody is there now, when somebody will be, and what happens to the message. That is more reassuring than any apology, because it is checkable.

A usable version: "Nobody is at the desk right now. We are here weekdays, nine to six, Vilnius time. Leave your question and an email and you will have an answer on the next working morning." It names the hours, names the timezone, and commits to a specific moment.

Two things to avoid. Do not promise a response time you have not measured, because the first missed one is more damaging than a longer honest estimate. And do not ask for a phone number if nobody is going to call, which happens more often than it should.

Say the timezone

A B2B site is read from other countries. "We reply within a few hours" means nothing without the hours it is counted from. Naming the timezone costs four words and removes most of the ambiguity.

Make the state visible before someone types

The decision a visitor makes is whether to start, and they make it before typing. Showing availability on the launcher itself, rather than inside the panel after a message is sent, saves them from investing in a conversation that will not happen now.

That means the state has to be real, derived from whether a teammate is actually there, not from a schedule someone set once and forgot. A schedule is a reasonable approximation for nights and weekends. It is a poor one for an afternoon when the whole team is on a call.

In GreetDock's inbox a conversation carries the page the visitor is on and what they asked, so a message left outside hours arrives with enough context for the first reply to be an answer rather than a clarifying question. That is the other half of the problem: not only when you reply, but whether the reply needs a second round.

Give the overnight queue an owner

A message left outside hours needs a named person who opens it first thing, not a shared inbox everyone assumes someone else is watching. Without an owner the queue is checked when somebody remembers, which is the same as not being checked. One name and one time is enough process.

The first action each morning should be deciding, not replying. Most overnight messages fall into three piles, and they want different handling:

• Answerable in a sentence. Reply immediately, before the rest of the day starts. These are the ones where a fast morning answer still feels fast to the person who asked the night before.
• Needs a person on a call. Do not try to resolve it in writing across a timezone gap. Offer two concrete times in their working day and let them pick one.
• Already solved itself. The visitor found the answer or moved on. Worth logging anyway, because a question that solves itself is usually a page that could have said so.

The third pile is the one teams discard, and it is the most useful. It is a free list of the places your site is unclear, gathered by the people who were actually blocked.

Reply to the question, not to the delay

An overnight reply that opens with a paragraph of apology spends the visitor's attention on your scheduling. Lead with the answer, then, if the delay genuinely cost them something, acknowledge it in one line at the end. "Here is the answer" is a better opening than "Sorry for the late response".

If the message arrived with the page the visitor was on and what they had already tried, the morning reply can be a real answer rather than a request for more detail. That is the difference between one round and three, and across a timezone gap each round costs a day.

Catch the question on the page instead

Some of what arrives outside hours is not a conversation at all. It is a fact the page did not state clearly, asked by someone with no other way to check. Those questions are cheaper to answer on the page than in any channel, and they do not respect your working hours.

Watch which questions repeat. If the same one arrives twenty times, the answer belongs in the product copy or the FAQ, not in a thread. A conversation tool that slowly becomes your documentation is telling you something about the documentation.

The remaining questions, the ones that genuinely need a person, are the ones worth designing the callback flow around.

A short checklist

Before you launch chat on a site that is not staffed around the clock:

Availability is the part of live chat that is a process decision rather than a software one. The software can only show the state honestly; it cannot create the person.

For how this fits with calls and shared pages, see the guide to live chat, calls and co-browsing. If you are planning to offer a shared page or record a call, co-browsing and GDPR covers what the visitor has to be asked first.

GreetDock is in private beta, built by a team in Vilnius. You can apply for early access or see how it compares.