They arrive with an answer already in hand
A growing share of visitors have asked an AI assistant about your product before they
reach your site. By the time they open a chat they are not starting from zero: they have been told
something, they half believe it, and they have come to confirm it or act on it. That is a
different conversation from the one you have with a search visitor who is still looking.
The practical consequence is that opening questions arrive strangely specific and oddly
confident. Someone asks whether the limit is fifty rather than what the limits are. Someone asks
you to enable a plan that does not exist under that name. They are not confused; they are working
from a summary that was assembled somewhere else, and it may be accurate, stale, or a blend of you
and a competitor.
Why the referrer often tells you nothing
You cannot reliably identify this traffic the way you identify a search visitor. Some
assistants pass no referrer at all, some pass one that identifies the assistant, and some send
people via a link the person copied into a new tab, which arrives looking like direct traffic. Any
attempt to build a precise channel report on this will overstate its own accuracy.
What you can do is look at the visitor context you already have.
Visitor monitoring shows the referring URL, the landing
page, and the path taken through the site, which is enough to notice the pattern: an unusual
landing page, no prior browsing, and an opening question phrased as verification rather than
enquiry. Treat that as a soft signal to read the question carefully, not as a channel to
report on.
The three things this traffic actually wants
Nearly all of these conversations reduce to three needs, and naming them makes the chat
much shorter:
- Confirm this is true. They have a claim and want a human to verify it. Answer
the claim directly before adding anything else.
- Do the thing the assistant described. They were told a task is possible and
have come to complete it. If the description was wrong, they need the real route, not an
explanation of the error.
- Fill the gap the summary left. A summary is lossy by nature, and the missing
part is often the part that decides the purchase.
All three reward a direct first sentence. A greeting that asks how you can help restarts a
conversation the visitor believes is already halfway through.
Correcting a wrong answer without calling anyone wrong
Sooner or later someone arrives with a confident statement about your product that is
simply not true — a feature you never built, a price you never charged, an integration that
was retired. Handling this badly is easy, because the two obvious replies both fail. Flatly
contradicting them makes the visitor feel foolish for trusting the tool, and going along with it
sells something you cannot deliver.
Correct the fact, not the person, and move immediately to what is true and useful. That is
not quite how it works now — there is no per-seat minimum, so you can start with one agent
and add more whenever you like. Notice there is no mention of where their information came
from and no implied criticism. The visitor's goal was never to defend the assistant; it was to
find out where they stand.
Your chat log is an early warning system
This is the part most teams miss. When several unconnected people arrive in the same week
believing the same untrue thing about your product, that is not a coincidence and it is not a
customer misunderstanding. Something being said about you at scale has drifted, and chat is where
you find out first — long before it appears in any report.
Give agents a way to flag it. A tag for chats that open with an incorrect premise costs nothing
and turns scattered irritations into a list you can act on. Review it monthly and look for repeats
rather than one-offs. The single most valuable output is a short list of claims about your product
that are circulating and are wrong.
Keep the public page authoritative
You cannot edit what an assistant says, so the lever you do have is the source. Assistants
summarise what they can read, and pages that state facts plainly are easier to summarise correctly
than pages that imply them through marketing language. If your pricing page expresses its limits
in a graphic and your FAQ hedges, a summariser will do its best and may do it badly.
Where a claim keeps coming back wrong, find the page that should settle it and make the answer
explicit, in text, in a sentence that would survive being quoted on its own. Put the current
position where it can be found rather than only in a changelog entry. This is ordinary content
hygiene, but the audience now includes machines that will repeat whatever they find.
What to measure
Do not build a channel report you cannot trust. Measure the things that are real instead:
the count of chats opening with a factually wrong premise, tracked over time, and which claims
recur. Watch whether these conversations resolve faster or slower than your average — they
often resolve faster, because the visitor arrives further along, and that is worth knowing before
you assume the traffic is low quality. And track how often a flagged wrong claim leads to an edit
on a public page, because that is the loop actually paying off.