It happens more often than teams assume
If your product has competitors, some of them read your website. A few of them will open your chat window, and a smaller number will ask questions specifically to find out how you answer. This is not sinister and it is not rare; it is ordinary competitive research, and your own team almost certainly does some version of it.
The reason it deserves a written position is that agents handle it badly by instinct. The two natural reactions are to become guarded with everyone, which makes real buyers feel interrogated, or to prove how much they know, which is how the interesting details leak. Neither is a policy. A short, agreed answer to what happens when we think this is a competitor prevents both.
You cannot actually verify who is typing
Start from the honest constraint. A chat widget on a public page carries no proof of identity: the name in the pre-chat form is whatever the visitor typed, and an email address in a free domain proves nothing at all. Anything that depends on knowing who someone is has to happen on a channel that can establish it, which is the same boundary that applies to account changes and sensitive requests.
So the practical question is never am I sure this is a competitor. It is what would I be comfortable saying to anyone, given that I cannot rule it out. Teams that answer the second question stop needing the first one, and they stop making awkward accusations at visitors who turn out to be customers.
Signals do exist, and they are worth reading without over-reading. Repeated visits that only ever touch pricing and comparison pages, questions phrased in your competitor’s vocabulary rather than a customer’s problem, and an unusual interest in your limits rather than your fit are all suggestive. The live visitor list shows the referring source and the path through the site, which is usually enough context to notice the pattern without guessing at motives.
Most of what they want is already public
Here is the part that calms everyone down: the large majority of competitor questions are about material you publish deliberately. Pricing that sits on your pricing page, features documented in your help centre, integrations listed on your site, the free tier and what it includes. Refusing to repeat published facts in chat does not protect anything. It just makes you look nervous and gives them a story to tell.
Answer public material the way you would answer it for a customer, at the same speed and with the same courtesy. If a fact is genuinely competitive, the correct fix is upstream: stop publishing it, or accept that it is public. A chat window is a poor place to run an information policy that your own website contradicts.
The short list nobody should volunteer
What matters is the material that is not published, and it is a shorter list than people expect. Unreleased plans and dates, because a roadmap mentioned casually in chat becomes a commitment you did not make. Named customers who have not agreed to be named, which is a confidentiality problem regardless of who is asking. Deal-specific pricing, discounts and contract terms, since an exception granted to one account is not a rate card. And the internal detail of your own defences, which is the point made in our guide to answering security questions: describing exactly how something is protected is a different act from confirming that it is.
Also on the list: anything about a competitor that you have not verified. Speculation about a rival’s outage, funding, staffing or practices is the fastest way to turn a research chat into a screenshot with your company’s name on it. Say what is true about your own product and leave their side of it to them.
Write these five items down and put them where agents can see them. A list that lives in a manager’s head is not a policy, and new starters cannot follow it.
Stay courteous, because the transcript travels
Every chat is a written record that the other party keeps, and a rude one is far more useful to a competitor than any fact they were fishing for. A screenshot of your team being evasive or sharp does more damage in a sales cycle than your pricing ever could, and it will be shown to people you never get to answer.
So the tone stays exactly the same. Helpful, unhurried, and specific about what you can and cannot cover. It is entirely possible to say that something is not published without sounding like you have been caught: that is not something we publish, but here is what I can tell you is a complete, professional answer that leaves nothing to screenshot.
There is also a real chance the person is not a competitor at all. Analysts, journalists, students, prospective employees and consultants all ask the same shaped questions. Treating suspicion as certainty is how a team ends up being cold to a future customer.
When the questions get specific
Occasionally a conversation stops looking like research and starts looking like an attempt to extract something particular: repeated pushes for a customer name, for a discount structure, or for detail about how a security control works. The move is not to argue about it. It is to stop expanding, answer only what is published, and offer the documented route for anything further.
That route is worth having ready. A published pricing page, a documentation link, a contact form for formal requests. Pointing at a documented channel is not a brush-off; it is how every organisation handles requests that need a record.
Then tell someone. A pattern of similar questions across several conversations is information your sales and product people should have, and it is invisible if each agent handles it alone and moves on.
How MyLiveChat fits
The live visitor list gives an agent the context to read the situation calmly — referring source, current page and the path taken to get there — before deciding anything about the conversation.
Transcript history is the part that matters afterwards. Because every conversation is stored and searchable, a manager can review what was actually said rather than reconstructing it from memory, and a recurring pattern of the same questions from different visitors is findable rather than anecdotal.
The boundary is a product fact, not a policy choice: a public chat widget cannot authenticate anyone, so identity-dependent decisions belong on a channel that can verify them. Building your team’s rules on that assumption is safer than building them on a hunch about who is typing.
What to measure
This is not a metrics-heavy topic, and inventing a competitor-detection rate would be worse than useless. Two things are worth watching. First, whether the same unusual question keeps appearing across conversations, which is a signal about what the market is being told rather than about any one visitor. Second, whether any agent is having to improvise the boundary, which shows up in transcript review as inconsistent answers to the same request.
If the second one is happening, the fix is the written list rather than more training. People follow a rule they can read in three seconds while a conversation is live; they cannot follow one they half-remember from an onboarding session.