When the agent doesn't know, it says so, and hands you off with the question already attached.
The worst thing a support chatbot can do is guess with a straight face. The second worst is dead-ending a customer into "please contact us" after they already explained the problem once. Helpforge's agent does neither: it refuses to invent an answer it cannot ground in your content, and offers a one-click handoff, in the same conversation, that carries the visitor's own question forward so they never have to type it twice.
The handoff button only ever appears when there is a real place for it to go, the destination is chosen by our server and never by the visitor's browser, and it never pretends to be someone it isn't.
Does the warranty cover a cracked case from a drop, or only manufacturing defects?
I don't have anything in what I've been given about drop damage specifically, and I don't want to guess on a warranty question. I can put this in front of the team with your question already attached, no need to repeat it. Want me to send it?
Yes, please.
Done. Your question is with the team now, and they'll reply by email.
What most AI chatbots actually do when they don't know.
"What happens when it can't answer?" is the question a bigger buyer asks before anything else, because the honest answer for most chatbots is one of two bad ones.
A bot under pressure to sound helpful will fill a gap with something plausible. A confident, wrong answer about a warranty, a shipping cutoff or a return window costs more trust than admitting it doesn't know. We cover the grounding side of this at length on our hallucinations page; this page is about what happens after it correctly declines to guess.
A wrong answer delivered confidently is worse than no answer at all."Sorry, I can't help with that, please contact us" is technically honest and still a bad outcome. The visitor has to leave the conversation, find a contact page or a separate form, and explain the whole thing again from scratch.
Losing the context a visitor already typed is losing the point of a chat interface.Even when a human is reachable, it's often a link to a generic contact page, a ticket form with its own fields, or a phone tree. Every extra step is a chance for an interested visitor to give up instead.
An escalation path nobody uses is not an escalation path.Refuse to guess, then make it one click to a real person.
The mechanism, not a promise: this is what the code actually does when the agent hits the edge of what it knows.
The agent only answers from what it was actually given, and says so when it wasn't given enough. That grounded-or-refuse behavior is the subject of our hallucinations page; the handoff below is what happens the moment it applies.
Admitting a limit is the feature, not a fallback."Talk to a human" opens an inline card in the chat itself, not a redirect to a new page or a generic contact form. The visitor never leaves the conversation they were already having.
No new tab, no separate form to hunt down.The message box is pre-filled with the visitor's own last question. They can edit it, add their email and send, without re-explaining what they already asked the bot two messages ago.
Nobody should have to type the same sentence twice.The button is only shown when the server has confirmed there is somewhere real to send the message. One shared rule decides both whether the widget shows the button and whether the endpoint will accept the write, so the button can never appear pointing at a door that isn't actually open.
A button that sometimes fails silently is worse than no button.The destination is decided by us, never by the visitor's browser.
Nothing in the request the widget sends says where the message should end up. The server looks up the client the visitor is talking to and decides from there, which is also what keeps the public endpoint from ever becoming a way to email an arbitrary address.
On a free demo
A demo always has somewhere to send a handoff: it routes to the Helpforge team. The card says so plainly before the visitor sends anything, "your message reaches the Helpforge team, not {the business}", because pretending the demo is staffed by the business itself would be a lie we're not willing to tell on a client's behalf.
Once you're a client
The button only appears once you've registered an inbox for us to send handoffs to. No inbox on file means no button, rather than a button that quietly fails. Once it's set, the card is direct: "leave your email and the team will get back to you," and the message goes straight to the address you gave us.
The parts that keep a good idea from becoming a liability.
A public endpoint that anyone's browser can call needs limits, or it becomes the attack surface. Here's what actually bounds it.
Each client's escalation path is capped at a fixed number of handoffs per day, tracked separately from the chat message quota so a busy day of ordinary questions can't use up the budget for people who need a person. Once the daily cap is hit, the widget's button reflects that instead of accepting a write the server would refuse.
A handoff costs someone's attention, so it gets its own limit, not the chat one.If an account is paused, the handoff endpoint refuses the write, same as the chat endpoint would. A lapsed account doesn't keep routing visitor messages to anyone.
Paused means paused, not "still quietly forwarding email".The visitor's own message is HTML-escaped before it's placed in the notification email. A visitor typing something that looks like markup or a header doesn't get to inject anything into what lands in your inbox.
Untrusted text stays text, all the way into the email body.The message is saved the moment the visitor sends it, and the notification email is a best-effort delivery on top of that. If the email hits a hiccup, the conversation isn't lost, it's already sitting in the lead record waiting to be read.
A failed notification is a missed ping, never a missed message.One flat build fee, one flat monthly.
The handoff path is part of the agent we build for you, not an add-on. No per-seat charges, no per-conversation meter. You see it running on your real site, question refused, handoff offered, message landing in your inbox, before you pay anything.
Free demo on your real site first. Ask it something it can't know, and watch what happens next.
Human handoff, answered honestly.
What happens when the AI chatbot doesn't know the answer?
It says so instead of guessing, then offers to hand the conversation to a real person right there in the chat. The handoff card opens inline, pre-filled with the visitor's own last question, so they can add their email and send without repeating themselves. That grounded-or-refuse behavior is covered in more depth on our page about avoiding hallucinations.
Does "Talk to a human" actually go to a real person?
Yes, and where it goes is decided by our server, never by the visitor's browser. On a free demo it reaches the Helpforge team, and the widget says so plainly before anything is sent. Once you're a paying client, it goes straight to an inbox you register with us.
Do I have to set anything up for the handoff to work?
As a paying client, yes: you register an email address for us to route handoffs to. Until you do, the "Talk to a human" button simply doesn't appear, rather than showing up and quietly failing. A free demo always has somewhere to go, since it routes to us, so you can see the whole flow before you set anything up.
Will the visitor have to explain their question twice?
No. The handoff card's message box is pre-filled with the visitor's own last question to the bot. They can edit it or add detail, but they never start from a blank box after already asking once.
Is there a limit on how many handoffs happen per day?
Yes, each client's escalation path is capped at 20 handoffs per day, tracked separately from the ordinary chat message quota so a busy day of routine questions can't crowd out the people who genuinely need a person.
Can a visitor abuse the handoff to send arbitrary content to my inbox?
No on both counts that matter. The destination is chosen by our server from the client the visitor is talking to, never from anything in the request itself, so the endpoint can't be turned into a general-purpose mail relay. And the visitor's message is HTML-escaped before it's placed in the notification email, so it can't inject anything into what you see.
See the handoff on your real site.
Give us your website URL and we build a working demo of your agent, usually within 2 business days. You get a private link to test it, and we invite you to ask it something it can't possibly know before any commitment. No call, no credit card.