Every support team eventually needs to find something that happened weeks ago. A customer refers to a conversation you half remember, a colleague asks whether an article on a topic already exists, or a refund needs checking against what was actually promised.
The dashboard has a Search screen for exactly this. It is a plain box, which makes it easy to assume it works like a web search engine. It does not, and the differences are worth knowing, because they change how you should type into it.
One box, two indexes, and one notable absence
The screen searches two things: your tickets and your knowledge base articles. Results come back in two separate sections on one page, each with its own heading and its own count.
What it does not search is chat transcripts. This is the single most useful thing to know about the screen, because it is the assumption most people arrive with. If you are trying to find a conversation that was never turned into a ticket, this box will not find it, no matter how well you phrase the query. Transcripts have their own screen, and that is where that search belongs.
The practical consequence is a workflow one, not a technical one. A chat that mattered should become a ticket, or carry a tag, if you ever expect to find it again. Conversations that stay only in the transcript log are findable only by browsing to them.
What a ticket search actually looks at
For tickets, the query is compared against the subject, the requester name, the requester email address, the requester phone number, the tags, and the channel the ticket arrived on. If the comment table is present, the text of the comments is searched too, so a phrase used in the middle of a long thread will surface the ticket that contains it.
There is one special case that is genuinely convenient. If what you typed parses as a number, it is also matched against the ticket number directly. A leading hash is stripped first, so both forms of a ticket reference work, and pasting a number straight out of an email finds the ticket rather than every ticket that happens to contain those digits in its text.
Because the requester fields are searched, an email address is usually the strongest query available to you. It is unique, people paste it accurately, and it pulls up every ticket that person has ever raised in one go.
What an article search looks at
For knowledge base articles the query is compared against the title, the body, the excerpt and the category. The body being included matters: an article whose title says nothing about the term you need will still be found if the term appears in the text.
That is a genuine help when you are trying to answer the question have we already written about this? before writing it again. It is also why a search for a common word returns more than you expected.
It matches substrings, not ideas
The comparison is a substring match. Your query is looked for anywhere inside those fields, including in the middle of a word. There is no stemming, no synonym expansion and no fuzzy matching.
Three things follow. Short fragments work well, and are often better than complete words: typing invoic finds both invoice and invoicing. Misspellings find nothing, because there is no tolerance for near misses. And a natural language question is close to the worst possible query, because the whole phrase has to appear literally somewhere in a single field.
The instinct to type a sentence is exactly wrong here. Type the most distinctive fragment you can remember instead. An order number, a surname, an unusual product word.
The order is recency, not relevance
Results are sorted by when the record was last updated, newest first. They are not ranked by how well they match.
This is the behaviour most likely to mislead you. A search that matches four hundred tickets shows you the four hundred that were touched most recently, not the four hundred that best fit your words. The ticket you want may be an excellent match and still sit far outside the visible results because nobody has touched it since March.
So a broad query is not merely noisy, it is actively unhelpful. Narrowing the query is the only lever you have, because you cannot page deeper into relevance that is not being computed. When a search returns a wall of recent-looking results that all seem unrelated, that is the signal to add a more distinctive term rather than to scroll.
Ten results, but an honest count
Each section shows up to ten results. The total is counted separately and displayed, so you are told the truth about how many matched even though you are only shown the first ten.
Treat that number as the quality signal for your query. A count in the low tens means you have described the thing well and the answer is probably on screen. A count in the hundreds means the ten rows in front of you are close to arbitrary, and the number is telling you to try again with something more specific.
Drafts and hidden articles show up too
Article results carry a status badge, and the search does not filter by it. Published, draft and hidden articles all appear, each labelled.
That is the right behaviour for an internal tool and it is easy to misread when you are moving quickly. An article you find here is not necessarily an article your customers can see. Before sending a link to a visitor, check the badge. Tickets are labelled the same way with their own status, which makes it easy to spot that the thing you found was closed months ago.
When a section says it is unavailable
If the underlying tables for tickets or for articles have not been set up on your account, that section reports itself as unavailable and explains that the schema needs deploying. It does not throw an error, and the other section keeps working normally.
If something genuinely goes wrong during a search, you get a short generic banner rather than a technical message. The detail is written to the server log deliberately, so that internals are not surfaced in the admin interface. That means a support request about a failing search needs the time it happened, not a screenshot of an error code, because the useful detail is on the server.
What to measure
There is no report attached to this screen, so what you are measuring is your own team rather than the tool. Two habits are worth watching.
The first is whether people can find previous answers at all. If the same question is being researched from scratch by different agents, the gap is usually that the earlier answer never became a ticket or an article, so there was nothing to find. That is a process fix.
The second is the shape of the queries themselves. Agents who type sentences will conclude the search is broken, and they will be reporting a real experience even though the tool is doing what it was built to do. Ten minutes explaining fragments, email addresses and ticket numbers pays for itself quickly.
If you find yourself repeatedly hunting for the same category of conversation, the durable fix is upstream: tag it when it happens, so that next time the tag is the query.