Help with feature adoption when customers ask what your product can do.

Why do customers miss features they could use?

Customers often learn the part of a product they needed on day one and stop there. A feature they’d use if they knew about it can sit behind a menu or a plan they’ve never opened. Feature discovery happens when they can ask at the moment a task is in front of them:

• “Can it send the weekly report to people who don’t have an account?”
• “Is there a way to edit these in bulk instead of one at a time?”
• “Your email mentioned approvals. How do I turn them on?”
• “Which plan has the audit log?”

How does the agent answer “Can it do this?”

The agent works from what the customer is trying to do:

• The customer describes the task, often without knowing the feature’s name. The agent finds sources by matching words, so describe each feature in task words as well as by its name.
• It answers from the approved source that matches: whether the feature exists, which plan includes it and how to switch it on.
• If no source describes a feature that does the job, it’s told to say it doesn’t know, and never to invent capabilities.
• If the customer asks, it can record a feature request on the conversation, and it’s told not to promise it will be done.

How do you keep new features in the agent’s knowledge?

The agent can describe a feature only once an approved source covers it. Make that source part of each release:

• Write one source per feature: what it does, the task words customers use for it, which plans include it and how to switch it on.
• Approve it on release day, so the agent doesn’t describe a feature customers can’t use yet.
• Remove or replace sources that describe the old way of doing something, or that say the feature doesn’t exist. Otherwise the agent may find the outdated answer.
• If you keep release notes in GitHub as Markdown, import one short file per feature or release rather than a running changelog, which soon grows too long for the agent to read in full. Every re-sync needs approval again.
• For a beta, say exactly who has access and how to ask for it.

How do you see which features customers ask for?

A conversation with feedback shows “Feedback captured” in the Conversations tab, whether the agent recorded a request or the caller pressed That was helpful, and the note appears above the transcript when you open it. A coding agent with a workspace token can also list up to 100 recent conversations with their feedback over MCP, or read the insights report with the conversation_insights tool, so you can gather requests into your own tracker.

The Insights tab groups recurring questions and product themes from up to your latest 30 support calls in the last 30 days, with quotes, so several customers asking for the same thing can show up together.

Read the conversations where the agent said it didn’t know as well. Some are features you have but haven’t described. Others are features customers expect and you don’t have yet.

What can’t the agent do for feature adoption?

It answers when asked. Everything else stays with your product and your team:

• It can’t switch a feature on, change a plan or see which features a customer already uses.
• It doesn’t send announcements, tours or tooltips. It speaks only when a customer starts a conversation.
• It can’t point at the screen, so describe where things are in words: the menu, the tab and the label.
• Handover to your team is an early release: verify a UK or US phone number for the support agent and turn handover on, and whoever answers hears a private briefing first. It rings the number verified for support, and customer routing is still being tested, so for upgrade conversations name your sales route in the agent’s instructions too.

Common questions