Why the guessed list is always wrong
The guessed list has a consistent bias: it over represents things that are interesting to explain and under represents things that are boring and constant. Nobody enjoys writing the page about where the car park entrance is, so it does not get written, and it is asked every single day.
It also over represents recency. The team remembers the difficult ticket from last Tuesday far more vividly than the fifty identical ones about delivery timing, because the difficult one took an hour and the others took ninety seconds each. Memory weights by effort. Your queue weights by volume. They are not the same ranking and the volume one is the one that costs you money.
Take a week, and take all of it
Pick a recent week that was not unusual: no outage, no sale, no product launch, no public holiday distorting the pattern. Export every inbound message from it. Every ticket, every chat transcript, every message that came through a contact form, and if you can get them, the notes from phone calls.
Take the whole week rather than a sample. The temptation is to take a hundred random tickets, and the reason to resist it is that the distribution matters more than the content. You are trying to find out that one question is asked four times as often as the next, and a sample large enough to establish that reliably is usually most of the week anyway.
If your volume is genuinely high, take a full day rather than a sampled week. A complete unit of time preserves the ratios. A scattered sample does not.
Group by what the person wanted, not by how it was tagged
This is the step that makes the exercise worth doing, and it is the step people skip because tags already exist. Existing tags were designed for routing and reporting. They tell you which team handled a ticket, not what the customer was trying to find out.
Read each message and write down, in your own words, the thing the person wanted. Not the words they used. A message that says my order still has not arrived and a message that says what is your delivery time to Scotland are tagged differently in most systems and are frequently the same want: I need to know when this will get here, and whether that is normal.
Do this in a spreadsheet with one row per message and one free text column for the want. Do not build the category list first. Let it emerge, and merge as you go. You will end up with somewhere between twenty and sixty distinct wants for a typical small business inbox, and the merging is where the insight is.
Count, and look at the shape
Sort by count. Two things will be true almost every time. The top handful of wants will account for a large share of the total, and there will be a long tail of things asked once.
The top of that list is your automation target. It is also, uncomfortably often, a list of things you believed were already answered on your site. The tail is not a target: writing a page for a question asked once is the classic way to spend a month producing help content nobody reads.
One thing worth checking before you act: is any top item there because of a defect rather than a documentation gap? A question asked constantly may be a symptom. If half your inbox asks how to reset a password, the problem might be the reset flow, and no amount of documentation about it is the right fix.
The top questions are usually already documented
Now take your top ten wants and go looking for the answer on your own site, as a visitor would. Use the site search. Use a search engine restricted to your domain. Give yourself a couple of minutes per question, which is about as long as somebody with a real question will persist.
The common result is that seven or eight of them are documented somewhere, and none of them are findable. The answer is in the third paragraph of a page whose title does not contain any word the customer would use. It is in a downloadable file. It is on a page that exists but is not linked from anywhere in the navigation. It is in the terms and conditions.
This changes what you do next. If the material exists but cannot be found, writing more material is the wrong move. The fix is restructuring what you have so that one question maps to one findable answer, which also happens to be the shape any retrieval system needs.
What to do with the list
Turn the top ten into ten pages or ten headed sections, each titled with the question in the customer's words. Put the answer in the first two sentences. Delete or redirect anything that answers the same question in a second place, because two answers eventually become two different answers.
Then keep the spreadsheet. Repeat the exercise in three months with a fresh week and compare the rankings. Items that fall have been fixed. Items that appear are new, and usually correspond to something you changed. This is a far more useful signal about your own support load than any dashboard, because you built the categories and you know what they mean.