MyDot Consultancy

Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.

Support conversations contain useful product research, but they are not a representative survey of customers. People contact support because something happened, because they need help or because another channel failed. An agent that clusters those conversations can reveal recurring friction. It cannot legitimately turn ticket volume into a precise measure of market demand.

The safest and most useful deliverable is an aggregate issue brief. It describes a pattern, shows appropriately deidentified examples, explains the dataset's limitations and identifies a product question worth investigating. It does not assign hidden psychological profiles to individual customers.

Decide which question the corpus can answer

Begin with an operational question such as “Which setup steps generated repeated requests this month?” or “What confusion appeared after the new navigation launched?” These questions are narrower and more testable than “What do customers want?”

Specify the product, period, languages, channels and ticket states included. Record why that slice was chosen. If only closed tickets are analyzed, unresolved difficult cases may disappear. If only English tickets are included, the results should not be presented as a global customer picture.

Define the unit of analysis. Tickets, conversations, accounts and incidents are not interchangeable. One outage can generate hundreds of tickets from fewer accounts; one account can raise multiple unrelated issues. Retain the distinctions necessary for the question without retaining unnecessary personal data.

Establish lawful and appropriate access before analysis

Use a corpus the organization is authorized to process for the intended purpose. Technical access alone is not the complete governance decision. Confirm internal privacy, retention and customer-data rules with the relevant owner rather than treating an available export button as blanket permission.

Zendesk's current incremental-export guidance distinguishes direct customer access from restricted third-party integration access. Verify the integration category before choosing that ingestion path. Record pagination state and avoid repeatedly exporting the entire account when a bounded, incremental collection is sufficient.

Remove direct identifiers before model processing where feasible. Names, email addresses and full addresses usually add little to a theme analysis. Free text can still identify someone through a distinctive story, so deidentification requires more than deleting obvious fields.

Use a codebook rather than an improvised word cloud

A codebook defines what each theme means, what it excludes and how overlapping cases are handled. Start with a small human-reviewed sample. Include an “unclear” category and allow multiple themes when the request genuinely contains more than one issue.

Ask the agent to cite the passage supporting each assigned theme. A label such as “onboarding confusion” should connect to an observed difficulty, not merely the presence of the word “setup.” Separate expressed requests, observed obstacles and the analyst's interpretation.

Review a sample across both frequent and rare themes. If only the largest clusters receive attention, a serious but uncommon usability barrier may be lost. Minority themes deserve inspection without automatically being described as widespread.

Control duplicate incidents and denominator errors

Deduplicate repeated messages and link related tickets when authorized identifiers establish the relationship. Do not merge records merely because they contain similar language. Similar wording can reflect a shared template rather than the same underlying incident.

Report the denominator next to each count. “Twenty tickets in the analyzed sample” is a different statement from “twenty customers” or “twenty percent of users.” If the full customer population is unknown, do not invent a prevalence estimate.

Break out known incident spikes. A temporary service problem may dominate a month's tickets while saying little about ordinary product usability. Conversely, excluding all incident-related tickets can hide the burden of confusing incident communication. Make that analytical choice explicit.

Preserve the customer's meaning without exposing the customer

Examples make themes understandable, but they also create privacy and attribution risks. Prefer concise paraphrases that retain the relevant friction. Where a direct quotation is necessary, use only the amount needed and ensure its use is permitted.

Avoid adding demographic, health, financial or personality inferences. The product team generally needs to know that a workflow was confusing, not an invented explanation of what kind of person found it confusing.

Have a reviewer inspect distinctive examples before sharing the brief outside the support group. A story can remain identifiable even after a name is removed. If the audience does not need the anecdote, replace it with a less specific description or omit it.

Turn patterns into questions and tests

A useful issue card contains the theme definition, count and denominator, representative evidence, confidence limitations and a suggested next investigation. The proposed action might be a usability session, a documentation experiment or a closer look at error telemetry.

Do not leap from repeated requests to a product roadmap commitment. A requested feature may be one possible solution to an underlying need. The agent should preserve the need and the stated request separately so product staff can explore alternatives.

For example, repeated requests for an export button might reflect reporting needs, integration gaps or difficulty sharing an existing view. Ticket text can suggest these possibilities. It cannot establish which solution will work without further evidence.

Evaluate the analysis process

Measure agreement between reviewers on theme assignments, the rate of unsupported labels and how often sampled cases are misrepresented. Inspect changes in the codebook over time; an apparent increase in a theme may result from a broader definition rather than a product change.

Track analyst and reviewer time alongside model costs. Large corpora can make elaborate clustering expensive while producing little incremental insight. A carefully sampled, well-defined analysis may be more useful than processing every message.

Stop or redesign the workflow when data access is inappropriate, source coverage cannot support the question or reviewers cannot explain the categories consistently. The value comes from a transparent route from customer evidence to a useful product question. It does not come from making a dashboard look authoritative through a larger number of AI-generated labels.

Sources and research notes

developer.zendesk.com — primary documentation: Incremental exports omit the most recent minute and support saved cursors. Third-party integration access is restricted; direct customer accounts retain access.

developer.zendesk.com — primary documentation: The official ticket resource reference documents reading and updating ticket records.

Documentation checked October 26, 2026. Workflow recommendations are design guidance, not reported customer outcomes. Verify current permissions, product behavior and pricing before implementation.