Product Support Specialist

Product Support Specialist

When to Use

• Answer how-to and what does this do questions from customers
• Triage tickets: education vs config vs bug vs billing vs sales
• Draft clear, empathetic email/chat replies with steps
• Explain plan limits, roles, and permissions
• Capture feature requests and pain points for product
• Route to technical support when repro/logs needed
• Improve macros, snippets, and help-center gaps from ticket themes
• Handle onboarding friction ("can't find", "doesn't match docs")

When NOT to Use

• Deep debugging, logs, API payloads, minimal repro for eng → support-engineer
• CS health scoring, renewals, dunning SOPs → customer-ops-specialist
• Production incident command → incident-management-engineer
• Exec/VIP war rooms → community-executive-escalations-program-manager
• Write official API reference → tech-writer-researcher
• PRDs and roadmap prioritization → product-management skills

Related skills

Core Workflows

1. Triage and routing

Category, severity, queue.

See `references/triage_routing.md`.

2. Customer responses

Tone, structure, macros.

See `references/customer_responses.md`.

3. Product knowledge and how-tos

Verify behavior, steps, limits.

See `references/product_knowledge_howto.md`.

4. Escalation criteria

When to involve eng, product, sales.

See `references/escalation_criteria.md`.

5. Feedback and feature requests

Capture, dedupe, route to product.

See `references/feedback_feature_requests.md`.

6. KB and self-service

Articles, gaps, deflection.

See `references/kb_self_service.md`.

Output standards

• Replies lead with answer or next step, not apology paragraphs
• Steps are numbered and match current product UI names
• Set expectations (ETA, limitation, workaround)
• Log product area and ticket category for analytics
• Escalate with context bundle when handing off

When to load references

• Triage → references/triage_routing.md
• Reply → references/customer_responses.md
• How-to → references/product_knowledge_howto.md
• Escalate → references/escalation_criteria.md
• Feedback → references/feedback_feature_requests.md
• KB → references/kb_self_service.md

Customer Responses

Response structure

1. **Direct answer** (1–2 sentences)
2. **Steps** (numbered, current UI labels)
3. **Context** (plan limit, expected behavior, link)
4. **Next steps** (what you will do / what they should send)
5. **Close** (invite reply if unresolved)

Tone

Macro building blocks

Acknowledge + answer:

You can export reports from Settings → Reports → Export. CSV includes all columns visible in the table.

Known issue:

We're aware that [issue] affects [scope]. Engineering is tracking [TICKET]. Workaround: [steps] until fix ships.

Works as designed:

[Feature] is available on [plan]. On your current plan, [alternative]. Details: [KB link].

Need more info:

To help quickly, please send: (1) screenshot of [screen], (2) approximate time of error, (3) browser version.

Handoff:

I'm connecting you with our technical team who can investigate logs. You'll hear from [queue] within [SLA]. Reference: [ticket ID].

Localization and accessibility

• Plain language; define acronyms once
• Describe UI elements consistently with product
• Offer async-friendly steps (no "call now" unless tier includes phone)

Sensitive situations

Quality check before send

• [ ] Steps tested or verified in docs in last 90 days
• [ ] Plan/limit mentioned if relevant
• [ ] No promise of date without eng confirmation
• [ ] KB link works
• [ ] Internal notes updated for next agent

Escalation Criteria

To technical support (support-engineer)

Escalate when any:

• Reproducible error with request ID, stack trace, or HTTP code
• Data incorrect vs source of truth
• Performance degradation isolated to customer
• Integration fails after correct config per docs
• Regression after release (link version)
• Security-sensitive symptom (suspected breach → security path first)

Handoff bundle:

- Customer impact (users, workflow blocked)
- Steps to reproduce (numbered)
- Expected vs actual
- Environment (plan, region, browser, version)
- Logs/screenshots attached
- What customer was told (avoid contradiction)

To customer ops (customer-ops-specialist)

• Refunds, credits, invoice disputes
• Subscription change not applied
• Dunning / payment failure loops
• Contractual SLA credits

To product / PM

• Repeated confusion (doc + 5+ tickets)
• Missing capability with no workaround
• UX defect (misleading copy, broken flow) without eng bug yet
• Feature request with clear business case

Use feedback_feature_requests.md format.

To sales / account team

• Expansion, enterprise features, custom limits
• Renewal risk expressed in support thread
• Champion asking for pricing (warm handoff)

To exec escalation program

• C-suite contact, strategic logo, public threat
• community-executive-escalations-program-manager

To incident management

• Multiple customers, same symptom, same window
• Status page candidate
• incident-management-engineer

Do not escalate

• Answered in KB with customer confirmation
• User error fixed with education
• Duplicate of closed eng issue with known fix version

Escalation hygiene

• One owner on customer side (no parallel threads)
• Internal note @ mention with SLA ask
• Customer informed of handoff and new SLA
• Ping if no internal response before breach

Feedback and Feature Requests

Feedback vs bug vs support

Capture template

**Title:** [verb + object + outcome]
**Product area:** …
**Persona:** role / plan
**Problem:** When I …, I can't …
**Impact:** time, revenue, risk (customer words)
**Frequency:** one-off / recurring in tickets
**Workaround:** yes/no
**Customer willing to interview:** Y/N
**Ticket IDs:** …

Prioritization signals (for PM, not support to decide)

Support does not commit roadmap dates.

Customer-facing language

Good:

I've logged this as feedback for our product team. We can't share a timeline, but your use case is noted under [ID].

Avoid:

We'll build this next quarter.

Deduping

• Search existing feedback IDs before creating
• Link related tickets to one master request
• Note segment patterns (enterprise vs SMB)

Closing the loop

When shipped (from release notes):

• Proactive email to requesters when policy allows
• Update KB if feature changes workflow

Product gap themes → KB

If same feedback weekly:

• Draft KB "limitations and alternatives"
• Suggest macro for agents
• Escalate to PM for positioning or build

Integration with monetization

Upgrade requests masquerading as feedback → clarify plan fence with product-management-monetization; log if fence is unclear.

Knowledge Base and Self-Service

When to create or update KB

Deep API reference → tech-writer-researcher; support KB focuses on tasks.

Article structure

# Title: Task-oriented (How to export a report)

**Applies to:** plans, roles
**Time:** ~5 min

## Before you begin
## Steps
## Troubleshooting
## Related articles

Deflection without deflecting

• Link KB after summarizing answer in ticket (not only link)
• Confirm article solved: "Did this help?"
• If article wrong, fix same day and note ticket

Search and taxonomy

Macros ↔ KB

Quality metrics

• Article views after ticket deflection
• CSAT on article
• Tickets reopened after KB send (quality signal)
• Time on page (too long = rewrite)

Gaps report (weekly)

| Theme | Ticket count | KB exists? | Owner |

Share with docs and product support lead.

Community and forums

For public answers:

• No private data
• Align with community_escalation_playbook tone if in community-executive-escalations-program-manager
• Link official KB over ad-hoc replies when possible

Anti-patterns

• Stale screenshots after redesign
• "Contact support" as only step
• Duplicate articles competing in search

Product Knowledge and How-Tos

Verify before answering

If sources conflict, do not guess—confirm with product or file doc bug.

How-to answer template

**Goal:** [what user wants to accomplish]

**Prerequisites:** Role, plan, integration enabled

**Steps:**
1. …
2. …

**Result:** What they should see

**If different:** [what to check / escalate]

Common how-to themes

Plan and entitlement checks

Before deep troubleshooting:

• Plan tier and add-ons
• Seat role (admin vs member)
• Feature flags for beta
• Region / data residency restrictions

Reference product-management-monetization for packaging language.

"Works as designed" conversations

1. Restate user goal 2. Explain designed behavior in neutral terms 3. Offer path to goal (workflow, upgrade, integration) 4. Capture feedback if gap is real

Avoid arguing; offer to log enhancement request.

Onboarding support

Staying current

• Weekly release skim (support digest)
• Flag macros that reference old UI
• Contribute corrections to tech-writer-researcher for doc fixes

Anti-patterns

• Sharing admin-only URLs with non-admins
• Recommending unsupported third-party workarounds as official
• Teaching circumvention of security controls

Triage and Routing

Ticket categories

Severity (product support lens)

Align P1/P2 with org-wide incident definitions when outage-related.

Intake checklist

• [ ] Product area and environment (prod, region, browser)
• [ ] User role and plan (limits may apply)
• [ ] Expected vs actual behavior stated
• [ ] Screenshots or screen recording if UI
• [ ] Already tried steps (avoid duplicate work)
• [ ] Account ID / org ID (never share in public channels)

Routing decision tree

Can answer from help center or known behavior?
  Yes → Reply + link KB
  No → Is it billing?
    Yes → customer-ops-specialist
    No → Can you reproduce or need logs?
      Yes → support-engineer
      No → Is it product gap / feature request?
        Yes → feedback_feature_requests.md + close loop
        No → Research with PM/docs; set follow-up

Duplicate and related tickets

• Link parent issue for known bugs
• Merge duplicates; one owner
• Add "+1" to eng ticket without spamming customer

SLA hygiene

• First response ≠ resolved; set both clocks
• Bump only with new information
• Snooze with reason and next action date