Customer Research

Conduct multi-source research to answer a customer question or investigate an issue. Search past tickets, documentation, known issues, and account history. Attribute every finding to its source.

Workflow

Step 1: Parse the Research Question

Break down what needs to be answered:

• Core question: What is the customer actually asking or what needs to be determined?
• Scope: Is this account-specific, product-wide, or a general knowledge question?
• Urgency: Is the customer waiting for a real-time response or is this background research?
• Known unknowns: What specific gaps need to be filled to answer confidently?

Step 2: Search Past Tickets

Query the ticketing system for related history:

• Exact match: Search for the specific error message, feature name, or symptom.
• Account history: Pull recent tickets from the same customer for context.
• Similar issues: Search for related reports from other customers to gauge breadth.
• Resolution patterns: Look at how similar tickets were resolved previously.
• Record ticket IDs, dates, and resolution status for each relevant finding.

Step 3: Search Documentation

Check internal and external knowledge sources:

• Knowledge base: Public-facing help articles and FAQs.
• Internal docs: Runbooks, playbooks, engineering notes, postmortems.
• Product docs: API references, changelog entries, release notes.
• Slack/chat archives: Relevant conversations in support or engineering channels.
• Note the last-updated date of each doc to assess freshness.

Step 4: Check Known Issues

Search for active bugs and incidents:

• Bug tracker: Open issues matching the symptoms described.
• Incident dashboard: Active or recent incidents that could explain the behavior.
• Release notes: Recent changes that might have introduced regressions.
• Feature flags: Whether relevant features are enabled or disabled for this account.

Step 5: Compile Account Context

If account-specific, gather profile information:

• Account tier and entitlements: What features and support levels they have.
• Recent activity: Login patterns, feature usage, API call volume.
• Previous commitments: Promises made by support, sales, or CSMs.
• Relationship health: NPS scores, CSAT trends, open escalations.

Step 6: Synthesize Findings

Consolidate research into an attributed summary.

Output Format

## Research Report: <Topic>

**Account**: <name or "N/A">
**Researched**: <date>
**Confidence**: High / Medium / Low

### Summary
<2-3 sentence answer to the research question>

### Findings

#### Source 1: <source type and ID>
- **Found**: <relevant information>
- **Date**: <when this was recorded>
- **Status**: <current / outdated / resolved>

#### Source 2: <source type and ID>
- **Found**: <relevant information>
- **Date**: <when this was recorded>
- **Status**: <current / outdated / resolved>

<repeat for each source>

### Account Context
- <relevant account details if applicable>

### Gaps
- <information that could not be found or verified>

### Recommended Response
<suggested approach for answering the customer based on findings>

Examples

User: "Customer says SSO stopped working after our update -- check if this is known" Action: Search bug tracker for SSO issues, check release notes for auth changes, look for similar tickets from other customers, compile findings.

User: "What have we told Acme Corp about the API rate limit increase?" Action: Pull all Acme Corp tickets mentioning rate limits, search Slack for internal discussions about their request, check CSM notes, compile timeline of communications.

User: "Research whether our webhook retry logic handles 429 responses correctly" Action: Search product docs for webhook retry behavior, check engineering docs for implementation details, look for related bug reports, summarize current behavior.

Best Practices

• Attribute every finding to a specific source with a link or ID. Unattributed claims erode trust.
• Note the date of each source. A ticket from two years ago may describe behavior that has since changed.
• Flag contradictions between sources explicitly rather than choosing one silently.
• Mark your confidence level honestly. "I found partial information" is more useful than presenting speculation as fact.
• When research is inconclusive, recommend the next step (ask engineering, reproduce the issue, check logs) rather than guessing.
• For account-specific research, always check what the customer has already been told to avoid contradictions.
• Separate facts from interpretation. Present what the sources say, then offer your analysis.
• Keep the research concise. Link to full sources rather than quoting them at length.