Trust is asymmetric
Here is a useful way to think about it. A good support interaction earns you a small amount of credibility. A bad one costs you a lot more than that in one shot. A customer who needed help, reached out, and hit a wall does not weigh that moment equally against the times you got it right. The bad moment carries more weight, because it answers the one question that actually matters to them: when this company has to come through for me, will it.
That asymmetry is worth naming because it explains why "we're usually pretty good" is not the same reassurance to a customer that it is to the business. A track record of mostly-fine does not undo the one moment that told them otherwise.
In that moment, the customer is deciding whether to stay
A customer reaches out to support because something went wrong for them. Underneath the specific question, they are also checking something else: is this company worth staying with when things get difficult. A wrong answer, a dead link, or being sent back to documentation they already read tells them something, even if it is not the answer they wanted. It suggests they might need to solve this themselves, or find somewhere else that will.
Once a customer starts thinking that way, the relationship has already shifted. Fixing the underlying problem later does not automatically undo it. They are now paying closer attention to whatever goes wrong next, and giving you less benefit of the doubt each time.
Waiting to address it looks cheap, but rarely is
The easy move is to treat one bad interaction as a rounding error. Fix the underlying issue whenever there is time for it. The problem with that math is that the customer is not waiting on your timeline. By the time you get around to a fix, they may have already decided they cannot rely on you, and started comparing you to what else is available.
Addressing the moment while the customer is still there and still talking to you is a meaningfully different situation than trying to win someone back after they have already made up their mind. The second one is a much harder conversation to have, and you often do not get the chance to have it at all.
You: My team uses the API and we're seeing errors fetching recent tickets. Is there documentation on the rate limits?
Chatbot: Rate limits are documented in the advanced configuration guide.
You: I checked that guide and it doesn't mention rate limits at all. Am I looking at the wrong article?
Chatbot: I don't have a specific article confirming the exact rate limit numbers, so I don't want to send you chasing another guide that might not have it either. Email our team at [email protected] and they can confirm the real limits for your account.
Notice the fork in that exchange. The first answer guessed at a location instead of admitting it did not actually know. The second answer, faced with the same gap, said so directly and pointed them to someone who could actually resolve it. Only one of those responses gives the customer a reason to stay.
What this looks like in the product
Our agent only answers from documentation you have actually given it. When it names the source, it is a real page we retrieved, not a guess dressed up to look like one. When the docs do not cover something, it says so plainly and hands off to a real person instead of guessing or pointing you back to an article you have already read. One honest exception: the chat box on our own homepage runs on this site's own pages, a two-page corpus rather than a real help center, so it does not link citations there, since a two-page corpus would mostly just point you back to pages you can already see.
Pricing is $0 setup and $49 a month, month-to-month, with no contract. If we let you down, canceling is a one-step decision, not a negotiation. That is a deliberate choice: it means we do not get to coast on a signed agreement if the actual experience stops holding up.
Related reading
- See all 20 guides in the Actually Helpful library, grouped by what you are actually trying to figure out.
- What should happen when a chatbot can't answer, on the difference between a dead end and a real handoff, the same fork this article's example turns on.
- Why "let me transfer you to a human" so often means starting over, on a specific version of a bad handoff: one that drops your conversation instead of ending it outright.
- What "deflection rate" numbers actually measure (and don't), on why a high resolution count does not tell you whether customers are actually satisfied.
- How many of your support tickets are actually repetitive, on checking your own ticket data instead of guessing at the scale of the problem.
Have a question you'd want answered honestly, not guessed at
Send us a real question from your own support queue and see whether the answer is a confirmed page or an honest "I don't know, here's a person who can help."