Topic definition guidance and best practices

Topic definitions drive rule generation and audit for Smart Topic Builder

Important: This feature is restricted to limited instances for early access and is not currently available for most users.
Restriction: This feature is part of a generative AI feature set available to customers with the requisite subscription agreement. Once the agreement is signed, feature entitlement is automatic after 5-7 business days. Activation may require additional configuration work. For more information, contact Medallia Support.

Topic definitions are components of Text Analytics topics; they were introduced alongside Smart Topic Builder and drive its rule generation and audit capabilities. Topic definitions are generated during discovery, and can be added manually for new and existing topics.

Topic definition components include editable description, example comments, and example keyword fields. Only the description field is required. Definition components guide the language model's rule generation and can be tailored to varying levels of specificity. The following image shows the Generate Rules with AI dialog displayed by Smart Topic Builder during Topic rule generation.

the Generate Rules with AI dialog

Smart Topic Builder uses topic definition components to identify common terms, synonyms, and semantically similar phrases that are highly indicative of the topic, then generates rules structured for both accuracy and performance, considering typical complexity of human-authored rules for similar topics.

Topic definition components can be inherited from topics generated with Topic Discovery, and edited or overridden manually by the admin, and they can be entered manually by the admin on new topics not generated by AI.

Generally, more context is better. Include what the AI should focus on (for example, actionable topics for mobile banking) and, importantly, what it should ignore to ensure cleaner results. The topic definition is the foundational context you provide to Smart Topic Builder, and if your definition is vague, the AI's suggestions will be vague. Well-crafted definitions can significantly reduce time spent manually editing rules and striving toward accuracy targets.

Getting started

When editing or adding topic definitions, prioritize the required Topic Description component, which should describe the topic's purpose or goal. Examples and keyword elements provide additional context for Smart Topic Builder, but examples and keywords do not have as much of an impact as the description. This prevents rigidity in the output.

Clearly define the boundaries of the topic. Broad descriptions can lead to noisy, overly general rules. For example, for a topic about Staff, include related attributes like Staff Helpfulness, Staff Knowledge, or Staff Attitude. Specificity helps ensure actionable insights. If a topic is specific to a certain department, location, or process, state it clearly.

By default, Smart Topic Builder does not understand context specific to your business like your competitors, hours of operation, or internal acronyms. If your topic needs this context, include it in the description.

Use this template to plan and define your topics before adding them to Experience Cloud:

Smart Topic Builder might generate rules that miss the mark. If so, revise the topic description and regenerate rules with the additional context, and use the Topic precision audit to test and refine your rules.

Core elements

A high-performing topic definition typically contains at least three of these core elements:

  1. Core intent — A clear, simple statement of what the topic should capture

  2. Business context — Specific nouns the AI doesn't inherently know, like your internal jargon, brand and product names, or competitors

  3. Inclusions — Examples of specific phrases or concepts that should match

  4. Exclusions — Clear instructions of what should not match; this can help Smart Topic Builder avoid topics that overlap with others

Example Topic Definitions

Descriptions like "Feedback about mobile deposits" are too broad. Be specific: "Feedback from retail banking customers regarding the process, ease of use, or failures when using the mobile app check-deposit feature."

A topic definition for a topic about food quality — but not food temperature — might have the inclusion examples "food tasted bad," "food was stale," or "food was undercooked," and the exclusion example "food was cold."

Descriptions should clearly define relevant acronyms. For example: "Customers discussing the 'BOPIS' (Buy Online Pick Up In Store) process. Include mentions of 'curbside' and 'drive-up'."

Context is key. For example, the definition "Customers talking about long lines or waiting too long" is suboptimal because it lacks context. Are the customers waiting on the phone? Are they waiting for a website to load? Is the line at the register or the service desk? The generated rule will be far too broad.

This is a stronger version of the previous example: "In-store customers expressing frustration about the wait time at the physical checkout counter or self-checkout kiosks. Include complaints about 'not enough registers open', 'slow cashiers', and 'long lines'. Exclude complaints about waiting in line at the pharmacy or waiting on hold for customer support." This definition succeeds because it specifies the customers are in-store, it gives specific examples of intent, and it provides explicit exclusions to prevent overlap with Pharmacy and Contact Center topics.