How to Use Website Chat Tags to Separate Product Confusion From Real Feature Requests

A visitor opens chat and asks: “Can I export this report?”

That sounds like a feature request. It may be one. But it may also mean the export option is already present, buried behind an unfamiliar label, available only after a report is generated, or explained poorly in onboarding.

Those are very different problems. Put all four into a roadmap bucket called export request, and the product team may spend weeks building a second path to a capability that already exists. Meanwhile, the real issue — people cannot find or understand the first path — stays in place.

Website chat is unusually good at exposing this distinction because it catches people at the moment their mental model breaks. The useful signal is not the first sentence alone. It is the conversation that follows.

Treat “feature request” as a hypothesis, not a tag

The first mistake is using a single tag called feature request. It turns a messy set of signals into a deceptively tidy list.

Instead, start with a top-level split:

• product confusion: the visitor’s intended outcome is already possible, but they cannot discover, understand, configure, or trust the existing route.
• capability gap: the visitor’s intended outcome is not currently possible without a workaround that does not meet their need.
• unclear: there is not enough evidence in the conversation to decide yet.

The unclear tag matters. Teams often force classification too early because ambiguity feels inefficient. In practice, a forced label produces cleaner reports and worse decisions.

A message such as “Can this notify my team?” is not enough to classify. Ask what event should trigger the notification, who should receive it, and what they do today. The answer may reveal that browser and email notifications solve the immediate need, that they need a different workflow, or that they are simply asking before trying the available setting.

The same wording can point to opposite actions:

“I need a way to ask visitors for their phone number.”

This could be a feature gap. Or it could be confusion if a chat flow can already collect phone numbers through a lead-capture form. The tag should follow the evidence, not the visitor’s phrasing.

Add a reason tag under each category

A two-level taxonomy stays readable while giving the product team something actionable.

For product confusion, use reasons such as:

• discoverability: the feature exists but the visitor did not find it.
• terminology: the visitor looked for one concept while the interface used another word.
• setup: they found the feature but could not configure it.
• expectation: they expected it to behave differently.
• documentation: the answer existed somewhere, but was not available at the point of need.

For capability gaps, distinguish between:

• missing outcome: there is no supported way to achieve the desired result.
• missing variation: the basic outcome exists, but an important version of it does not.
• scale constraint: the workflow works for a small case but becomes impractical for the visitor’s volume or team structure.
• workflow mismatch: the product can perform a step, but not in the sequence the visitor needs.

This prevents a common roadmap error: treating a request for a variation as a request for an entirely new product area.

For example, “I need the chat to ask one question before another” may be a workflow-design problem rather than a need for a new capture mechanism. “I need different questions for visitors on different pages” is more specific. The second statement gives you something to test against the current product behavior; the first mostly tells you the person is stuck.

Tag the evidence, not just the topic

Topic tags are helpful but weak on their own. pricing, reporting, install, and lead capture tell you where the discussion happened. They do not tell you whether to build, rename, document, or fix something.

Add one small evidence tag to each conversation:

• confirmed existing: the visitor successfully used the current capability after guidance.
• workaround accepted: they reached the outcome through an imperfect but workable route.
• workaround rejected: the available route failed a stated requirement.
• repeated ask: the visitor returned to the same unmet need after explanation.
• abandoned: the conversation ended before the need was clarified.

That extra field changes the quality of a monthly review. Ten chats tagged reporting mean little. Ten chats tagged capability gap + missing outcome + workaround rejected deserve attention.

Avoid over-tagging. Three tags per conversation is usually enough: topic, diagnosis, and evidence. If a reviewer needs seven labels to describe one exchange, the taxonomy is doing the thinking instead of helping it.

Read the turn after the answer

The most revealing moment is often not the initial request. It is what happens after support explains the current option.

If the visitor says, “Ah, I missed that,” you have a discoverability or documentation problem.

If they say, “That only works if I do this manually every time,” you may have a capability gap — but now you know the missing requirement is repetition or automation, not the broad feature they named.

If they say, “I need that before the visitor starts chatting,” you have learned that timing is the issue. A page-triggered flow, widget-open trigger, or quick-start button may address it where a generic chat answer does not.

This is why closed conversations are more useful than a pile of isolated request snippets. The resolution attempt is part of the evidence.

If you use Owni, paid-plan AI answers are logged for review and link back to the exact knowledge-base page used in the response. That gives reviewers a useful diagnostic question: did the assistant point to a relevant source and the visitor still remain blocked? If yes, the issue may be interface design or a real capability gap. If no, improve the source material before escalating the request to the roadmap.

Review patterns by conversation, not by loudness

A single determined visitor can produce five messages about the same issue. That is valuable qualitative evidence, but it should not be counted as five independent requests.

During review, keep one row or record per conversation and capture:

1. The visitor’s desired outcome in their own words.
2. The tag set: topic, diagnosis, evidence.
3. The existing path offered, if any.
4. The requirement that made that path succeed or fail.
5. A short quote that preserves the constraint.

The constraint is the important part. “Need export” is a feature-shaped label. “Need to hand a weekly summary to a client who cannot access the dashboard” is a decision-ready problem statement.

Look for repeated constraints across different topics. Several seemingly unrelated requests may all point to the same friction: visitors cannot locate settings, teammates lack access to a specific project, or an existing flow does not appear at the moment people need it.

Make roadmap review a two-bucket meeting

Bring two lists to product review:

Fix the understanding path

These are confirmed-existing conversations. The response may be clearer labels, better help content, a revised flow message, or a more direct answer in chat. Their success measure is simple: fewer conversations where people ask for something they can already do.

Test the missing outcome

These are capability-gap conversations with a repeated, specific constraint and no accepted workaround. Do not prioritize them because the tag count is high alone. Check whether the affected visitors describe the same job, whether the gap blocks completion, and whether a narrower change could satisfy the requirement.

A useful rule: do not promote a request to roadmap priority until you can write the sentence, “People are trying to achieve ___, but the current product fails because ___.” If the second blank is “they did not know where to click,” it belongs in the understanding bucket first.