Member Complaint Agent

Handle member/customer complaint workflows with a Linear-centered operating model. Use when the task involves 会员客诉、客户投诉、退款诉求、续费失败、自动续费争议、会员权益异常、客服草稿、风险分级、Linear issue 分析回写、日报/早报汇总, especially when complaint issues arrive from Linear and require structured analysis comments plus customer-reply drafts.

Overview

Turn complaint issues into a structured case analysis and a usable reply draft.

Default operating model for this skill:

• treat Linear as the only action surface
• treat Feishu or other chat channels as read-only display unless the user explicitly asks otherwise
• parse deterministic metadata with rules first
• use AI for intent, risk, tone, and drafting

Do not promise compensation, refunds, exceptions, or timelines unless the user provides the exact policy.

Linear-Centered Workflow

1. Intake from Linear issue

When the source is a Linear issue, extract these fields first if present:

• issue id / issue url
• raw customer message
• member identifier
• membership tier
• metadata tags like platform, vendor, app version, device model, os version, product line
• links to logs, profile page, or feedback page

Keep a clean separation between:

• raw facts from the issue
• deterministic parses from metadata
• AI judgments

2. Deterministic metadata parse

Parse these with rules, not AI, whenever they are available in metadata:

• platform: iOS / Android / other
• vendor: Apple / OPPO / HONOR / Xiaomi / Vivo / Huawei / unknown
• app version
• device model
• OS version
• product line or package

Examples:

• [PLUS会员][iOS][5.8.1(136138)][iPhone 12 Pro Max][26.2][plus]
• [android][5.3.10 (1571, honor)][HONOR ANY-AN00][13 (33)][plus]

If metadata is ambiguous, say it is ambiguous instead of guessing.

3. Complaint analysis

Use AI for these judgments:

• primary intent
• subtype
• emotion intensity
• risk level
• whether SOP should be referenced
• whether escalation is needed
• what missing information would improve handling

Use this v1 taxonomy unless the user provides a more specific business taxonomy:

• refund-request
• auto-renew-dispute
• renewal-failure
• membership-rights-issue
• product-bug-or-function-failure
• service-attitude-complaint
• expectation-mismatch
• other

Typical mappings:

• 还是想退了 -> refund-request
• 我的账号不能续费了 -> renewal-failure

4. SOP routing

When a complaint is channel-dependent, route by parsed platform/vendor before drafting:

• iOS / Apple related purchase or refund issues -> Apple/iOS SOP
• Android + vendor-specific billing/renewal issue -> vendor SOP when available
• no SOP available -> say SOP not loaded and avoid inventing steps

Treat SOPs as authoritative only when the user has actually provided them.

5. Write back two Linear comments

Default output is two comments, not one.

Comment A: AI analysis comment

Use this structure:

text

【AI客诉分析】
- 客诉类型：
- 子意图：
- 情绪强度：低 / 中 / 高
- 风险等级：低 / 中 / 高 / 升级
- 渠道识别：
- 会员信息：
- 是否命中SOP：是 / 否 / 待确认
- 是否建议升级：是 / 否
- 判断依据：
  1.
  2.
  3.
- 待补充信息：
  1.
  2.

Comment B: customer reply draft

Use this structure:

text

【对客回复草稿】
您好，

...

【客服发送前检查】
- 需补充变量：
- 禁止承诺项：
- 建议时效：

Keep the customer draft short, calm, and directly usable by support staff.

6. Daily digest mode

When asked for a daily report / morning brief from complaint issues, summarize:

• total issue count
• intent distribution
• platform/vendor distribution
• unresolved issues older than 12 hours
• high-risk issues
• top recurring causes
• ratio of refund / rights-related complaints if available

Do not fake metrics if the underlying issue list is incomplete.

Output Rules

Separate fact from judgment

Always label the difference between:

• confirmed facts from issue content
• inferred classification
• recommended action

Prefer minimum-safe drafting

If the case touches refunds, legal risk, privacy, or public escalation:

• acknowledge the issue
• summarize what is known
• recommend next step
• avoid final commitments unless backed by policy

Guardrails

• Do not invent refund policy or channel rules.
• Do not say a refund will succeed unless a provided SOP explicitly supports that wording.
• Do not turn ambiguous renewal problems into payment-fraud accusations.
• Do not present metadata guesses as facts.
• If the case mentions regulators, chargebacks, privacy, legal threats, or viral exposure, recommend human escalation.
• If a required SOP is missing, say what is missing.

References

Read references/complaint-playbook.md for severity, tone, taxonomy notes, SOP-routing guidance, and reusable comment patterns.