What Support Requests Can Reveal About Your Next Product

Your support queue may contain requests for work your product was never designed to do. Some are edge cases. Others point to a recurring adjacent job, such as approval routing, reporting, migration, or compliance evidence. An agent can group those requests, but frequency does not prove a second product should exist. The task is to turn support evidence into testable hypotheses without confusing repeated requests with willingness to pay.

This workflow helps teams find patterns, trace source conversations, and decide what to validate.

The business problem

Support systems are organized to resolve tickets, not to expose markets. Similar requests arrive with different wording, get tagged inconsistently, and disappear after closure. Product managers hear the loudest examples, while quieter patterns across customer segments remain hidden.

A classification workflow can identify requests that describe an adjacent job rather than a defect or missing core feature. It can summarize the job, count distinct accounts, compare segments, and prepare a review set. The output is a research backlog, not a product roadmap.

Required inputs

You need:

• Support tickets or conversations with stable IDs and timestamps
• Existing issue categories, product areas, and resolution codes
• Account metadata limited to useful fields such as plan, industry, or tenure
• Product scope and current roadmap definitions
• Links to source tickets so every cluster can be audited
• Customer consent and internal rules for research use
• A list of known bugs, documentation gaps, integrations, and feature requests
• A product reviewer and a support reviewer

Named tools are illustrative only. Zendesk, Intercom, Help Scout, or Freshdesk could be ticket sources. A warehouse such as BigQuery or Snowflake could hold minimized analysis data. A language model could classify redacted text. These names are examples, not native Agentic Workers integration claims.

Step-by-step setup

1. Define an “adjacent job”

Write a definition before analyzing tickets. An adjacent job is an outcome customers repeatedly try to achieve near your product’s workflow but outside its intended scope. It is not merely a request for a missing button.

For example, “export this report as CSV” may be a feature request. “Collect evidence from several systems and package it for an auditor” may represent a broader compliance workflow.

2. Create a safe analysis dataset

Select a bounded period and remove signatures, credentials, payment data, health information, and unrelated personal details. Replace names and direct identifiers with controlled account keys. Retain ticket links in a protected system rather than copying full conversations into every downstream tool.

Exclude spam, test tickets, employee conversations, and unsupported languages unless you have a reliable review process for them.

3. Separate core categories first

Classify each request into a high-level category: bug, how-to question, documentation gap, core feature request, integration request, service request, adjacent job, or unclear. Allow multiple labels when needed, but require evidence spans from the source text.

Start with a manually labeled sample. Compare the agent’s labels with decisions from support and product reviewers. Adjust definitions when disagreement exposes ambiguity.

4. Describe the job, not the proposed feature

Customers often ask for a familiar solution. Translate “Build a dashboard” into the underlying need, such as “give executives a weekly view of exceptions without manual spreadsheet work.” Preserve the original request beside the normalized job so reviewers can detect overinterpretation.

Distinguish direct statements from inference. A request for approval history is evidence. A governance product is a hypothesis.

5. Cluster requests and preserve traceability

Group requests by shared job, trigger, desired outcome, and current workaround. Require every cluster summary to include ticket IDs, distinct account count, date range, and representative redacted excerpts. Do not let a polished summary hide weak or heterogeneous evidence.

Merge clusters only after human review. Similar words may describe different jobs, while different words may describe the same one.

6. Rank signals with more than frequency

Count distinct accounts, not just tickets, so one persistent customer does not dominate. Add segment spread, recency, severity, workaround burden, strategic fit, and whether the job appears before or after successful use of the core product.

Keep request frequency separate from willingness to pay. A frequently requested convenience may have little budget. A less frequent regulatory problem may carry urgent budget. Ticket text usually shows frustration or importance, not a purchasing commitment.

Create separate fields for evidence of need and willingness to pay. Payment evidence remains unknown unless customers discuss budget, paid alternatives, procurement, economic impact, or accept a price test.

7. Review with support and product together

Support can identify context and temporary incidents. Product can assess scope and strategic fit. Together they should reject misleading clusters and choose a few hypotheses for research.

8. Validate outside the support queue

Interview customers from several clusters and a comparison group that did not make the request. Ask about the last time the job occurred, current workaround, consequences, decision process, existing spend, and what would justify switching. Do not pitch too early.

Then test commitment with a paid pilot, letter of intent, suitable preorder, or clearly priced service. Stated enthusiasm is not payment evidence.

Permissions and privacy

Use a read-only support credential and export only the fields needed. Check whether customer terms, notices, and contracts allow product research and model processing. If a third-party model is used, review data retention, training, residency, and subprocessors. Redact secrets and sensitive personal data before transmission.

Restrict source tickets to people who already have support access. The product research output should use de-identified excerpts whenever possible. Define retention for both the analysis copy and generated embeddings, and make deletion propagation possible.

Human review

Every high-priority cluster needs source review. The reviewer should confirm that the quoted evidence supports the normalized job, counts represent distinct accounts, and no sensitive information leaks into the summary. They should also look for selection bias: customers who contact support may differ from the broader market.

No agent-generated score should automatically create a roadmap commitment. A named product leader remains responsible for deciding which hypotheses deserve discovery.

What to measure

Measure the quality of learning:

• Agreement between reviewers and classifier labels
• Percentage of clusters with valid, traceable evidence
• Distinct accounts and segments represented
• Duplicate, spam, and misclassification rates
• Hypotheses advanced, rejected, or revised after interviews
• Workarounds, economic consequences, and existing spend discovered
• Concrete commitments obtained in validation
• Time saved preparing research sets, without reducing review quality

Keep need evidence and payment evidence in separate reporting columns.

Failure modes

Common failures include treating every feature request as a new product, ranking raw ticket volume, allowing one account to dominate, leaking PII, losing links to sources, and using vague model summaries as evidence. Clusters can also reflect a temporary outage, confusing documentation, or a gap your core product should fix.

Another risk is confirmation bias. Once a cluster has an attractive name, teams may search only for supporting examples. Require disconfirming evidence and interviews with customers outside the cluster.

A small first experiment

Take 200 closed tickets from one product area and one recent quarter. Manually label 40 to establish definitions, then let the workflow classify and cluster the remainder. Have one support lead and one product manager review the top five clusters and inspect every cited ticket. Choose one adjacent-job hypothesis for five exploratory interviews. Do not build anything yet. Record need evidence, payment evidence, and reasons the hypothesis might be wrong.

Related practical guides

• How to automate support triage and routing
• What a proactive AI assistant should actually do
• How recurring AI work becomes easier to manage

Source inspiration: This original research workflow was inspired by a support-pattern idea shared by @startupideaspod, then expanded to separate demand signals from payment evidence.

Agentic Workers can help you build a traceable support-research workflow that turns recurring requests into hypotheses worth validating.