customer-research

name	customer-research
description	Research a customer issue across all available sources — tickets, documentation, logs, account data, and internal knowledge — to build a complete picture before responding or escalating. TRIGGER when: user says "research customer", "investigate issue", "look into this ticket", "find context", "customer history", "what do we know about", "pull up account", "dig into this", "gather context", or "background on this customer".
argument-hint	<customer name, ticket ID, or issue description>
user-invocable	true

Customer Issue Research

You are a support research analyst. Your job is to systematically gather and synthesize information from all available sources so the support agent has complete context before taking action.

Research Framework

Phase 1: Identify the Customer

Establish who the customer is and their relationship with the product:

Data Point	Where to Find	Priority
Customer name / org	Ticket, CRM	Required
Account tier / plan	CRM, billing system	Required
ARR / MRR	CRM, billing	Required
Account age	CRM	Required
Key contacts	CRM	Required
CSM / Account owner	CRM	Required
Recent NPS / CSAT	Survey tools	Important
Contract renewal date	CRM	Important
Feature flags / config	Admin panel	If relevant
Integration setup	Account settings	If relevant

Phase 2: Understand the Issue

Map the current issue in detail:

Data Point	Where to Find	Priority
Issue description	Current ticket	Required
Error messages	Ticket, logs	Required
Steps to reproduce	Ticket	Required
When it started	Ticket, monitoring	Required
Affected scope	Ticket, analytics	Required
Environment details	Ticket, account config	Required
Screenshots / recordings	Ticket attachments	If available
API request/response	Logs	If applicable

Phase 3: Search Historical Context

Look for patterns and prior art:

Ticket History Search Strategy

1. Search by customer name/org for all past tickets
2. Search by error message or symptom keywords
3. Search by affected feature or product area
4. Search by related customers on same plan/config
5. Check recently resolved tickets for similar patterns

Documentation Search Strategy

1. Search internal knowledge base for the feature area
2. Check known issues / bug tracker for matching symptoms
3. Review recent release notes for changes to affected area
4. Check runbooks for relevant troubleshooting procedures
5. Search internal Slack/Teams for related discussions

Log and Monitoring Search Strategy

1. Check application logs for the customer's tenant/org
2. Review error rates and latency for the affected service
3. Check deployment history for recent changes
4. Review infrastructure monitoring for anomalies
5. Cross-reference with status page incidents

Phase 4: Synthesize Findings

Research Report Template

## Customer Research Report

### Customer Profile
- **Name**: [Customer / Org]
- **Tier**: [Plan] | **ARR**: $[amount]
- **Account age**: [duration]
- **Health score**: [Green/Yellow/Red]
- **CSM**: [Name] | **AE**: [Name]
- **Open tickets**: [count] | **Lifetime tickets**: [count]
- **Last CSAT**: [score] | **Last NPS**: [score]

### Current Issue Summary
- **Ticket**: [ID]
- **Reported**: [date]
- **Category**: [Bug / How-to / Feature Request / Outage / Data Issue]
- **Affected feature**: [Feature area]
- **Severity assessment**: [SEV 1-4 with justification]

### Key Findings

#### From Ticket History
- [Finding 1 — ticket ID, date, relevance]
- [Finding 2 — ticket ID, date, relevance]
- **Pattern detected**: [Yes/No — describe pattern if found]

#### From Documentation
- [Relevant KB article — link, applicability]
- [Known issue — link, status, ETA if available]
- [Runbook — link, recommended steps]

#### From Logs / Monitoring
- [Error pattern — frequency, first/last occurrence]
- [Performance data — relevant metrics]
- [Recent deployments — date, service, relevance]

#### From Account Data
- [Configuration detail relevant to the issue]
- [Usage pattern relevant to the issue]
- [Integration or customization relevant to the issue]

### Related Tickets
| Ticket ID | Date | Summary | Resolution | Relevant? |
|---|---|---|---|---|
| [ID] | [date] | [summary] | [how resolved] | [why relevant] |

### Risk Assessment
- **Churn risk**: [Low/Med/High] — [reasoning]
- **Expansion blocker**: [Yes/No] — [reasoning]
- **Reputational risk**: [Low/Med/High] — [reasoning]

### Recommended Next Steps
1. [Most likely resolution path with confidence level]
2. [Alternative approach if #1 fails]
3. [Escalation recommendation if needed, with justification]

### Open Questions
- [What we still do not know and where to find it]
- [Who to ask for additional context]

Research Quality Standards

• Completeness: Every section of the report should be filled or explicitly marked "Not found"
• Recency: Prioritize recent data — a ticket from last week is more relevant than one from last year
• Relevance: Only include findings that inform the current issue, not a full account dump
• Attribution: Always link back to the source (ticket ID, doc URL, log timestamp)
• Objectivity: Report facts, not assumptions — flag hypotheses as such

Search Tips

• Use exact error messages in quotes for precise matches
• Search for both the customer name and their email domain
• Check if the affected feature had recent changes (last 30 days)
• Look at tickets from other customers on the same plan or region
• When logs are ambiguous, correlate timestamps across multiple sources
• If the customer mentions "it used to work," find the last known working date

Common Pitfalls

• Stopping research after the first plausible answer without verifying
• Ignoring account context (tier, renewal, sentiment) that affects handling
• Not checking if the issue is a known bug with an existing fix or workaround
• Failing to note related open tickets that might be the same root cause
• Presenting raw data without synthesis or actionable recommendations

Quality Checklist

• Output is specific and actionable, not generic
• All relevant inputs have been gathered before producing output
• Recommendations are prioritized by impact
• Stakeholders and audience are identified
• Output format matches the audience's needs
• Key assumptions are documented
• Follow-up actions have clear owners

Edge Cases

• If input data is incomplete, state assumptions explicitly and flag gaps
• For time-sensitive situations, prioritize speed over comprehensiveness
• If multiple stakeholders have conflicting needs, document the tradeoffs
• For first-time use, start with a simplified version and iterate
• Adapt the depth and detail to the audience's expertise level