Philippines staffing blog ·
Choose search terms for help desk articles
Connect customer wording, product terms, symptoms, and safe answer paths so specialists can find the right guidance under pressure.
Direct answer
The operating answer
Support-article search terms should connect the words customers and frontline specialists actually use with the article's precise supported outcome. Build them from privacy-reviewed search queries, ticket language, visible interface labels, error text, product synonyms, and common misspellings. Then map each term to an article only when its prerequisites and result genuinely match; keyword overlap is not enough.
For an outsourced help desk, maintain client-specific vocabulary without exposing one client's internal names to another. Give every term an intent, source, scope, destination article, exclusion, and review date. Test search success by whether users select the right article and complete the next step, not merely by whether an article appears in results.
Field definitions
Terms to define in the workflow
- Observed query
- A minimized phrase entered by a customer or specialist, normalized without retaining names, account identifiers, secrets, or unnecessary free text.
- Search intent
- The goal behind the words, such as download invoice, restore sign-in, change notification recipient, or understand a visible error.
- Preferred term
- The current product or service wording used in titles, headings, metadata, and approved support replies.
- Variant
- A safe synonym, legacy label, abbreviation, misspelling, symptom phrase, or customer-language alternative that should retrieve the same intent.
- Exclusion
- A near-match that must route elsewhere because product, role, version, authority, risk, or desired outcome differs.
- Search outcome
- Correct article opened, alternate route selected, query refined, no result, abandoned session, or article opened but ticket still created.
Decision table
Term-to-intent mapping examples
| Observed language | Likely intent | Article treatment | Important exclusion |
|---|---|---|---|
| receipt, bill copy, invoice PDF | Download an existing invoice | Use variants in title metadata and first heading | Correcting invoice identity or amount needs a separate route |
| locked out, cannot log in, sign-in blocked | Recover ordinary sign-in | Map to approved recovery overview | Suspected takeover or ownership mismatch uses protected guidance |
| empty download, blank CSV, export has no rows | Troubleshoot an empty export | Include symptom and interface term | Missing records in a non-empty file is a different outcome |
| alerts, emails, notifications | Change routine notification settings | Use synonym cluster with role prerequisite | Billing or security notices may not be user-configurable |
| E52 when saving | Understand a visible save error | Index exact safe error text and affected action | Same code on export or another version may require another article |
| admin change, new owner | Change account authority | Return a protected route overview | Do not surface procedural bypass terms or verification details |
Swipe or scroll sideways to read every column.
Collect language without collecting customer secrets
Use aggregate no-result queries, reformulations, ticket subject patterns, approved chat labels, specialist search notes, and interface terminology. Before analysis, remove names, email addresses, workspace IDs, order references, pasted tokens, and message fragments that are unnecessary to understand intent. Restrict raw-query access and publish only normalized term clusters. Public search boxes often receive sensitive material; the fact that a customer typed it does not make it suitable article metadata.
Label the source and confidence of each variant. A phrase appearing in twenty no-result searches is stronger findability evidence than one reviewer's preferred synonym, but frequency still does not prove intent. Read a sample of surrounding, minimized context to distinguish reset password from change another user's password. Include vocabulary used by new customers, screen-reader users, regional spelling variants, and specialists supporting the client, while keeping technical jargon as a bridge rather than the only language.
Create separate dictionaries for client-specific branded features and a controlled shared dictionary for truly generic support concepts. An outsourced provider may serve several products with a page called Workspace or Console; terms must resolve within the authenticated client's knowledge boundary. Avoid adding confidential project names, security-control labels, unpublished incident codes, or internal queue names merely because specialists search for them.
Design and test a term map around outcomes
For each article, state one primary intent, eligible audience, product or version scope, prerequisites, and exclusions. Add variants to the title, summary, headings, metadata, and cross-links in natural language rather than repeating a keyword block. Put the customer word beside the official label: email alerts, called Notifications in the portal. Exact visible error text can be useful when it is safe and specific, but a generic word such as failed should not make every troubleshooting article compete.
Run scenario tests with top queries, no-result queries, misspellings, and deceptive near-matches. Review the first results and ask whether a user can distinguish them without opening several articles. A query for change invoice address should not rank downloading an invoice above updating billing identity merely because both repeat invoice. Use article summaries to state the outcome and stop condition clearly, then add an alternate route for exclusions.
Measure no-result rate, successful refinement, correct-result selection, short-return behavior, ticket creation after article view, and sampled outcome completion. A high click rate can be misleading when the title attracts users but the prerequisites do not fit. Review term clusters after product label changes, article revisions, launches, and recurring ticket themes. Retire legacy terms gradually when customers still use them, but label old wording so it does not imply support for an obsolete workflow.
Worked example
Worked example: customers searching for a blank report
A client article is titled Troubleshoot CSV export generation, yet customers search blank report, empty spreadsheet, download has headers only, and export no rows. Search analytics show frequent no-result sessions for blank report, while ticket review confirms that most customers want an order export for a specific date range. A smaller group uses the same words for a dashboard that displays no data, which has different prerequisites and ownership.
The term map assigns empty CSV, blank export, headers only, and spreadsheet no rows to the export article. Its summary says that it covers a downloaded CSV containing no expected rows and asks users to confirm product, date range, and export type. Blank dashboard becomes an exclusion with a visible link to dashboard-data guidance. The article does not index customer file names or copied row content found in raw searches.
Testing uses six phrases, including the misspelling exprot blank and the near-match report missing one day. The export article ranks first for empty-file intent, while the missing-records article ranks first for a partial range. Four weeks later, reviewers compare correct selections, immediate query reformulations, and tickets opened after reading. They find that headers only users complete the article more often, while blank report remains ambiguous, so the search interface asks whether the problem is in a downloaded file or an on-screen dashboard instead of forcing one result.
Implementation checklist
Review before the workflow goes live
- Collect minimized query and ticket language from several approved sources.
- Remove identifiers, secrets, personal data, and unnecessary raw context before clustering.
- Assign each term to a customer outcome, supported scope, and source confidence.
- Include interface labels, synonyms, legacy wording, regional variants, and common misspellings.
- Document near-match exclusions for role, version, authority, product, and risk.
- Test top results with routine, no-result, and deceptive near-match scenarios.
- Measure correct outcome and follow-on contact, not search impressions or clicks alone.
- Review mappings after label changes and keep client vocabularies appropriately separated.
Cautions
Boundaries to keep visible
Do not publish raw customer queries as keywords. Search text may contain account identifiers, health or payment details, credentials, or allegations unrelated to article findability.
Do not make sensitive recovery or security procedures easier to enumerate through detailed public terms. Index a safe route and customer outcome, while keeping control logic in restricted guidance.