FAQs: Zia-Generated Thread-Level Keywords for Tickets | Zoho Desk

FAQs: Zia-Generated Thread-Level Keywords for Tickets

Understanding thread-level keywords

What are Zia-generated thread-level keywords?
Thread-level keywords are AI-generated terms that summarize the main subject of each incoming customer response in a ticket. They help an agent understand how the conversation is evolving without having to infer the topic solely from a long thread history.

Unlike a single label applied to an entire ticket, these keywords are tied to individual customer replies. A ticket about a defective product might begin with the keyword “replacement” and later shift to “refund” after the customer declines the replacement. That change gives the next team context about the customer’s current request, not just the ticket’s original issue.
Why use thread-level keywords instead of relying on ticket tags alone?
Ticket tags categorize the ticket at a broader level and may be added manually or automatically. Thread-level keywords focus on the content of each customer response, which is useful when the subject changes during the ticket lifecycle.

For example, a ticket may initially concern “delivery delay,” then contain a follow-up about a “damaged product,” and finally request a “refund.” A ticket-level label alone may not make those transitions obvious. Thread-level keywords provide a response-by-response signal that can be used to monitor the conversation and automate follow-up actions.
Which messages receive keywords?
Zia generates thread-level keywords for responses sent by the customer. The feature applies to customer replies or threads received through:
  1. Email
  2. Help Center
  3. Web forms
  4. Social channels
  5. Manually created tickets
  6. Tickets created through the API
This means the feature is channel-inclusive for incoming customer content; it is not limited to email tickets.
Are keywords generated for agent replies as well?
No. The documented behavior is to generate keywords for each response sent by the customer. Use the keyword as an indicator of what the customer is discussing in that particular incoming thread, rather than as a summary of an agent’s reply or the entire ticket.
What must be enabled before keywords appear?
Zia must be enabled for the relevant department. Once it is enabled, thread-level keywords are activated automatically for that department; there is no separate keyword-specific activation described.
To enable the prerequisite:
  1. Navigate to Setup > Zia.
  2. Enable Zia for the appropriate department.
Tickets created after Zia is enabled will display thread-level keywords.
Will existing tickets receive keywords after Zia is turned on?
Do not assume that previously created tickets will be populated. The documented availability applies to tickets created after Zia is enabled for the department. Plan testing and workflow rollout around newly created tickets rather than depending on historical tickets to display keywords.
Can thread-level keywords be disabled separately while keeping Zia enabled?
No separate disable setting is documented. To disable thread-level keywords, disable Zia for the respective department. Because that action turns off Zia at the department level, assess other Zia-dependent processes before using it as a way to remove keywords.
Which languages are supported?
Currently, Zia thread-level keywords support English only. Organizations handling multilingual customer conversations should not treat keyword-based workflows as language-neutral until support for their required language is available.
A practical approach is to limit keyword-triggered automation to departments or channels where incoming customer content is reliably English, and route other cases through a review process.

Viewing and interpreting keywords

Where can agents see a response’s keyword?
  1. Open the ticket.
  2. Hover over the hashtag (#) beside the contact name.
  3. View the displayed thread-level keyword.
This placement lets agents inspect the response context while working in the ticket, rather than navigating to a separate analysis screen.
What should an agent do when a keyword changes during the same ticket?
Treat the change as a prompt to review the relevant customer reply and confirm whether the ticket’s current handling path still fits. The keyword reflects the core content of that response, so a new term can indicate a genuine change of request, ownership, urgency, or required team.

For instance, a product team may be handling a “replacement” request. If a later customer response yields “refund,” the agent can validate the new request, update the ticket stage if needed, and involve the payments team rather than continuing the replacement process by default.
Is a keyword itself a final decision or a substitute for reading the ticket?
No. The keyword is a concise contextual signal. It is designed to reduce the time needed to orient a new agent or team member, but it does not replace reviewing the customer’s actual reply and the ticket history when a decision affects money, entitlement, priority, ownership, or customer commitments.

Use it to surface likely intent quickly; use the conversation record to validate the action.

Using keywords in workflows

Can thread-level keywords trigger automation?
Yes. Thread-level keywords can be used in workflow rules to trigger actions such as:
  1. Sending alerts to the appropriate team
  2. Updating ticket fields
  3. Sending email notifications to customers
This turns the keyword from a visual aid into an operational routing and response signal.
What are effective workflow use cases?
Useful use cases connect a clearly identified customer topic to a specific, controlled action. Examples include:
  1. When the keyword is “replacement,” send an acknowledgment that an agent will call within two business days and update the ticket stage to Action Needed.
  2. When the keyword is “debit card,” notify the banking team responsible for debit-card requests.
  3. When the keyword is “medical insurance,” mark the ticket as high priority when medical-insurance inquiries require accelerated handling.
  4. When a conversation moves from “replacement” to “refund,” notify the payments team so the ticket is reviewed by the right function.
How should a keyword-based workflow be designed safely?
  1. Identify the keyword and the operational meaning your team assigns to it. Define whether it represents routing, prioritization, customer communication, or field updating.
  2. Choose the narrowest action that is safe to automate. A notification or ticket-stage update is often safer than making an irreversible customer commitment.
  3. Define who reviews exceptions. Assign a team or agent responsible for checking tickets where the workflow action needs confirmation.
  4. Test with newly created tickets after Zia is enabled. Confirm that the keyword appears and that the workflow performs the intended action.
  5. Monitor changes in customer intent. A later keyword may indicate that the ticket needs a different owner or next step than the one selected earlier.
Can workflows route a ticket to different teams as the customer’s topic changes?
Yes. The documented examples describe organizations with different product teams—such as loans, credit cards, and insurance—using reply keywords to move tickets to the relevant team without agent intervention. The same pattern can be used when the customer’s latest reply reveals a different area of responsibility.

For example, an insurance firm can use a “medical insurance” keyword to prioritize the ticket, while a “credit card” or “loan” keyword can direct attention to the corresponding specialized team.
Should a workflow send a customer email for every detected keyword?
Not necessarily. Customer email actions should be deliberate and appropriate for the keyword’s meaning. Acknowledgment emails work well when they set a clear expectation, such as confirming a call within two business days for a replacement-related request. Avoid designing multiple keyword rules that could send overlapping or confusing messages as the conversation evolves.
What happens if the ticket’s current topic differs from its original topic?
Thread-level keywords are especially valuable in this situation because they reflect incoming responses over time. Use the latest relevant customer response to reassess the workflow path. A team should not assume that the initial issue remains the requested outcome when the customer has changed from, for example, replacement to refund.
Is this feature suitable for priority management?
Yes, when the keyword has a clear, policy-backed relationship to urgency. The documented example marks tickets containing “medical insurance” as high priority when that product line is prioritized by the organization.
Do not use a keyword alone to redefine priority unless your internal operating policy supports that treatment. The keyword identifies the topic; the organization’s workflow determines the business action.
How can teams prevent automation from misdirecting a ticket?
Use keyword automation as targeted operational assistance, not as an unchecked replacement for ticket review. Keep actions proportionate to the risk:
  1. Use notifications when a specialist needs to assess the case.
  2. Use field updates when the workflow outcome is well defined.
  3. Reserve customer-facing promises for approved, repeatable scenarios.
Review tickets whenever the customer’s latest reply signals a new request or outcome.
This matters most for tickets that cross teams, such as product, logistics, and payments, where an early routing decision may no longer match the customer’s latest request.
How should a team introduce the feature?
Start with a small set of high-confidence, English-language use cases. Select topics with unambiguous ownership and measurable outcomes, such as notifying the debit-card team or flagging medical-insurance inquiries for priority review. Then expand based on whether the routed tickets are reaching the correct teams and whether agents can act on the alerts without additional clarification.
Info