The top ten questions users actually ask AI assistants

We build an AI assistant that companies put inside their own software, so their users can get help without leaving the screen they are on. Part of building it well is understanding what people actually ask it, so it keeps getting better at the things they need. Last month, we analyzed the types of questions users are asking to see where they get stuck.

Some of those questions are bug reports, and there's also a handful of requests for something new. But most are people unsuccessfully trying to do something the product already supports.

The same short list of areas kept coming back, in products that otherwise have nothing in common, so we thought it could be helpful to highlight some of the themes.

Here they are, in rough order of how often they came up. It is not exhaustive, just the areas that drew the most questions.

The confusions that show up everywhere

Money. People ask about billing more than anything else. Payouts, fees, taxes, refunds, invoices, why a number came out the way it did. Otherwise unrelated products generate the exact same cluster of money questions, because money is where the stakes feel highest and the interface tends to explain the least.

Where things are. A lot of questions are pure orientation: what does this screen do, where is that setting, what is this icon, what is this record. The more a product can do, the more surface area it grows, and a user's mental map rarely keeps up. New releases only add to it, so people end up relearning a product they already use.

Who can do what. Permissions, roles, seats, and admin controls come up constantly. Every product has an access model, and almost none of them are legible to the people living inside them. The question is rarely "how do I set a permission," it is "wait, can this person do that, and why can't I."

Reading the dashboard. A striking number of questions are simply "what does this number mean." People ask the assistant to define the product's own metrics, because the product shows the metric but never taught it. You can ship a beautiful analytics view and still leave half your users unsure what any column measures.

Setup. Getting something live takes a long sequence of steps, and people lose the thread partway through, unsure which step comes next.

Integrations after day one. Connecting to an outside system is rarely where integrations go wrong. The trouble starts after, in the syncing: an order that never came through, a record that failed to connect, a feed that stopped updating and no one noticed. An integration is sold as a one-time setup, and then it runs as an ongoing relationship.

The things that send. People often report a bug when something meant to go out did not: a message that never sends, a file that never lands. Sending looks simple to build and turns out to be full of failure modes users never see coming, and they notice right away, because someone on the other end is waiting.

The things that save. Saving and loading is the other reliability cluster: laggy screens, saves that do not take, views that will not populate, data that looks stale. Each one makes people trust the product a little less.

Control over what already exists. When people do ask for something new, it is almost never a brand-new capability, just more control over what is already there: a more flexible pricing rule, one more field at checkout, a column they can reorder, a notification they can turn off. They want to make the product fit how they already work.

Leaving. Offboarding gets almost no design attention, and the questions keep coming right to the end: cancelling, deleting, pausing, downgrading, getting a refund. The end of the relationship is often the least explained part of the whole product.

What the support queue missed

None of these are exotic. The same confusions turn up in product after product, however well built, which points at the software, not the company: the more a product can do, the more there is to understand, and none of it teaches itself.

For a long time, the only way to see this pattern at all was the support queue: one ticket at a time, hours or days after someone got stuck, from the small share of people willing to file one. An assistant inside the product changes the dynamic. It answers in the moment, on the exact screen where someone is stuck, at any hour, which is help most users have never actually had. And because the help is instant and in context, people ask differently. They ask smaller questions, sooner, the ones nobody would open a ticket for. So you start to see new patterns emerge.

Why documentation can't keep up

This is not about bad software. Teaching people to use software has always been hard, and it keeps getting harder as products grow more capable and change more often. Help docs cannot keep up with every change, so helping users inside the product, in the moment, matters more than ever. That is the work we build Frigade for. The themes above are a good place to start auditing your own product flows.