Your FAQ is probably incomplete. Here's how to know.

Ask any website owner if their FAQ covers the real customer questions. Everyone says yes. It's almost always wrong.

Not because teams are careless. Because FAQs get written from internal logic, which doesn't match the logic of a hesitant visitor on their couch at 11 PM.

How most FAQs get written

The typical scenario. A small business launches their website. Someone on the team (often the founder or marketing lead) takes an hour to write the FAQ. The method: think about the questions the team answers most often.

The result is almost always the same kind of questions:

• "What are your delivery times?"
• "How do I place an order?"
• "What payment methods do you accept?"
• "What's your return policy?"
• "How can I contact you?"

These aren't bad questions. But they're structural, predictable, the questions an experienced online buyer expects you to answer in some standard way.

The real questions are contextual

The visitor mid-hesitation isn't asking "what payment methods do you take". They're asking, roughly in this order:

• "Will this specific product solve my specific problem?"
• "Am I sure this is the right size / version / quantity for me?"
• "Is there a catch I'm not seeing (hidden fees, recurring charge, etc.)?"
• "What happens if it doesn't work out?"

Notice the difference. Their first question is personal and specific to the product they're looking at. Not generically "how does your store work". Specifically "this product, in my situation, is this the right pick".

No static FAQ can cover these questions, because they're too numerous and too nuanced. You have 200 products? You have a potential 1000 personalized questions combining specs and customer context.

The gap between theory and reality

To measure this gap on your own website, here's a 20-minute exercise.

Step 1: pull your last 30 incoming support emails. Not closed tickets. The actual emails as they came in. The tone, the wording, the context.

Step 2: for each email, ask: "was the answer somewhere on my site, in a place the visitor could have found within 30 seconds?"

You will find:

• A portion (often 30 to 50%) are questions where the answer existed somewhere, but buried.
• Another portion are questions where the answer didn't exist on the site at all.
• A final portion are highly contextual questions ("in my specific case, would this...").

The first two groups are gaps in your FAQ. The third group is the inherent limit of any static document: no FAQ can cover every individual case.

Why your existing customers won't tell you

If you ask current customers "what was missing from our FAQ", they'll say "nothing, it was fine". For two reasons:

First, current customers are the survivors. They got past the hesitation phase and bought. The actually-missing questions are the ones from visitors who never became customers.

Second, asking a human "what question did you have six weeks ago" doesn't work. People don't remember. They remember the outcome (I bought, I didn't), not the path.

To get the real signal, you need to capture it in real time, when the question is fresh.

Three ways to capture the signal

The open contact form. A single field "your question" with no pre-filled subject and no required fields. A surprising number of visitors will leave short questions there. Read them weekly, you'll find gaps.

Your internal site search. If you have a search bar, export the queries from the last 30 days. You'll find the keywords your visitors are typing. Most of those words aren't in your page titles (otherwise the visitor would have landed there directly). That mismatch is information.

A conversational agent on the site. The most effective option, because friction is lowest. The visitor types their question into a chat bubble like they'd type a text. You get not just the question but the context (which page it was asked on, at what time, followed by which other questions). On the sites I've seen this deployed, the volume of questions captured is 5 to 10 times higher than support emails for the same number of visitors.

The actual benefit isn't the automation

Most articles about chatbots sell the idea of automation: "free up your support team". That's true, but it's not the most important benefit in my experience.

The real benefit is signal. For the first time you know, word for word, what your visitors are trying to figure out before they buy. These questions become the input to improve your product pages, your FAQ, your descriptions, your visuals. A store that learns 40% of questions are about shipping times now knows exactly what to put above the fold on the product page.

It's this learning loop that changes the website over time. The bot answering for you is just the immediate win.

What to do this week

List the five questions you see most often in your support emails from the last month. For each, check where the answer lives on your site (how many clicks, is it obvious). If any of these answers is more than two clicks from the homepage or the main product page, you've already found your first improvement.

The rest is a question of capturing the questions that never reach your inbox.