# USER 评价业务闭环主流程与后续工作基线 v1.2

## 文件信息

- 文件名称：`20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md`
- 项目路径：`C:\XCODE\USER`
- 当前版本：`v1.2`
- 最近更新：`2026-05-17`
- 前一版本：`20260517_USER评价业务闭环主流程与后续工作基线_v1.1.md`
- 文件目的：在既有销售到评价闭环基线上，补入真实人识别、测评 / 免评额度、用户历史上下文、IM / EDM / TEL / 客服细化口径，作为新版第二步和后续数据流设计的统一依据。
- 适用范围：当前阶段的 Amazon 业务闭环设计；如后续扩展到独立站或非 Amazon 评价体系，需要在本文件基础上另行增补。
- 使用方式：下一次继续本项目时，先读取本文件，再读取 `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`，不要再从旧版页面链路重新推导业务主干。

---

## 版本记录

| 版本 | 日期 | 说明 |
| --- | --- | --- |
| v1 | 2026-05-17 | 首次固化销售到评价完成的 USER 业务闭环主流程 |
| v1.1 | 2026-05-17 | 将免评改为独立闭环；明确每次有效互动都要重新做身份与风险判断；明确当前版本不单列商家角色 |
| v1.2 | 2026-05-17 | 补入用户历史与设备上下文、真实人级 `测评4 / 免评4 / 累计真实提交评价12` 规则、IM / EDM / TEL / 客服新增细节，并把第二步入口改为“共用能力 + 渠道专属流程” |

---

## 1. 已确认目标

1. 系统要支持 USER 部门工作，而不是只做一个回评记录工具。
2. 业务流必须从“销售发生 / 需求形成”开始，而不是从“推送”开始。
3. Amazon 运营既可以人工提需求，系统也可以因 Listing 健康或评价缺口自动触发需求。
4. 用户运营是“需求评估 + 计划调度中心”，负责把需求转成可执行计划并跟踪结果。
5. 计划类型必须正式保留：
   - 推新计划
   - 回评计划
   - 免评计划
6. `免评计划` 不是边缘例外，而是需要正式保留的关键业务类型；其与 KOC / KOL、社媒带货、站外流量和 Amazon 权重有关。
7. 用户提交评价与系统确认评价完成必须拆成两个节点：
   - 用户已真实提交评价
   - Amazon 已展示 / 系统已确认计入计划完成
8. `真实人` 是后续额度、风险、历史和用户画像的核心对象，不应只围绕某个 JOYHUB ID、邮箱或 Amazon 账号看用户。
9. 已确认的额度规则为：
   - 同一真实人每月最多参与 `4 次测评`
   - 同一真实人每月最多参与 `4 次免评`
   - 同一真实人累计最多计入 `12 个真实提交的评价`
10. `12` 的计数时点是 `用户真实提交评价`，不是 `Amazon 展示评价`。
11. 每次有效互动都要重新做身份、历史、额度和风险判断；主动推送后的回复也不例外。
12. 客服接入时必须能快速看到用户历史、订单历史、设备上下文、既往风险和当前提醒，而不是只看到当前对话。
13. 后续系统设计顺序已经确定：
    1. 先定业务流
    2. 再做点击操作模拟
    3. 最后根据业务需求整合现有数据，形成新的数据流和中间表需求

---

## 2. 当前边界与资料依据

### 2.1 当前纳入范围

- Amazon 业务
- 销售到评价闭环
- 推新、回评、免评
- IM、EDM、APP、TEL、KOC / KOL
- 售后接入
- 客服执行与客服管理支撑
- 黑名单与诈骗风险
- ASIN 健康回流

### 2.2 当前不作为本版主流程展开的内容

- 独立站全链路
- 完整 BI / 财务 / ROI 系统
- 完整 KOC / KOL 结算系统
- 所有历史后台页面逐页重构
- 数据库最终物理设计

### 2.3 资料依据

本文件基于以下材料整理：

1. `C:\XCODE\USER\评价业务流闭环项目架构文档_v0.8.docx`
2. `C:\XCODE\USER\docs\evaluation-business-architecture.md`
3. `C:\XCODE\USER\docs\project-phase-one-plan.md`
4. `C:\XCODE\USER\output\docs\20260503_USER后台ERP一期功能与页面设计_v4.md`
5. `C:\XCODE\USER\output\docs\20260503_USER后台ERP自动推送与计划状态机_v4.md`
6. `C:\XCODE\USER\output\docs\20260503_USER后台ERP一期页面原型说明_v4.md`
7. `C:\XCODE\USER\output\docs\20260503_USER后台ERP_MVP角色首页UI规划_v1.md`
8. `C:\tcode\飞书\飞书聊天记录库\cloud_files` 中当前主原型 HTML 与 `客服执行.html`
9. `C:\Users\wu_zh\Downloads\20260407-法国诈骗问题（已扩散美国）.docx`
10. `C:\Users\wu_zh\Desktop\表头.xlsx`
11. `C:\Users\wu_zh\Downloads\IM 推送业务流.mm`
12. `C:\Users\wu_zh\Downloads\后台回评工作流对接事项.docx`
13. `C:\Users\wu_zh\Downloads\客服相关模块.docx`
14. `C:\Users\wu_zh\Downloads\电话业务流程知识库.docx`
15. 用户在当前对话中补充确认的业务规则

若历史资料与当前对话确认口径冲突，以当前对话中最新确认口径为准。

---

## 3. 角色与职责

| 角色 | 核心职责 |
| --- | --- |
| Amazon 运营 | 依据销售、ASIN、评价目标提出推新 / 回评 / 免评需求 |
| Amazon 运营总监 | 审批相关计划，确认优先级与业务必要性 |
| 品牌运营 | 负责品牌推广、站外节奏和与用户运营 / 内容运营协同 |
| 内容运营 | 承接社区广告、APP 广告位、内容流量等侧向支持 |
| 用户运营 | 评估需求、生成计划、分配资源、协调渠道、跟踪结果 |
| 用户运营负责人 / 组长 | 复核计划、分配组员、处理重点风险和异常 |
| 菲律宾客服负责人 | 关注工单压力、分配客服组、处理升级工单、查看绩效 |
| 菲律宾客服组长 | 分配组内工单、复核升级、控制逾期和重点工单 |
| 菲律宾客服组员 | 实际接待、电话沟通、记录、回复、回访、提交疑似诈骗 |
| 风险 / 黑名单相关人员 | 接收诈骗疑似、复核、同步黑名单、维护风险口径 |
| KOC / KOL 运营 | 承接站外带货、合作关系、内容和导购协同 |

当前版本不单列“商家 / 商家运营”角色。这里的“商家”如出现，均按 Amazon 卖家侧语义理解，由 Amazon 运营承接；品牌商当前也只纳入 Amazon 内评价相关协同。

---

## 4. 总体业务结构

### 4.1 主流程

```mermaid
flowchart LR
    A["销售发生 / ASIN销售数据形成"] --> B["需求触发"]
    B --> B1["Amazon运营人工提需求"]
    B --> B2["系统按评价缺口或Listing健康自动触发"]
    B1 --> C["用户运营评估需求"]
    B2 --> C
    C --> D["形成业务计划"]
    D --> D1["推新计划"]
    D --> D2["回评计划"]
    D --> D3["免评计划"]
    D1 --> E["规则 / 风险 / 额度复核"]
    D2 --> E
    D3 --> E
    E --> F["审批通过"]
    F --> G["执行拆解"]
    G --> H1["评价型执行闭环"]
    G --> H2["免评型执行闭环"]
    H1 --> I1["IM / EDM / APP / TEL / 客服协同"]
    I1 --> J1["用户被触达或主动进入"]
    J1 --> K1["每次有效互动均重做身份 / 历史 / 额度 / 风险核验"]
    K1 --> L1["服务 / 售后 / 跟进"]
    L1 --> M1["用户真实提交评价"]
    M1 --> N1["计入真实人累计评价额度"]
    N1 --> O1["Amazon是否展示 / 系统是否确认完成"]
    O1 --> P["结果回流"]
    H2 --> I2["KOC / KOL为核心，IM / EDM / APP等协同参与"]
    I2 --> J2["内容发布 / 站外引流 / 带货执行"]
    J2 --> K2["跟踪点击、Code、订单、转化与权重结果"]
    K2 --> P
    P --> Q["更新ASIN健康、计划完成度、用户画像、流量结果、风险记录"]
    Q --> C
```

### 4.2 五个业务层

| 业务层 | 说明 |
| --- | --- |
| 经营层 | 销售、ASIN、需求、品牌 / 内容 / KOC-KOL 侧影响 |
| 计划层 | 推新、回评、免评、审批、规则、额度、风险 |
| 执行层 | IM、EDM、APP、TEL、客服工单、KOC / KOL 协作 |
| 服务与身份层 | 用户接入、真实人归并、订单核验、用户上下文、售后处理 |
| 结果与风险层 | 用户真实提交评价、Amazon 展示确认、免评结果、黑名单、诈骗、结果回流 |

---

## 5. 主流程详细说明

| 阶段 | 业务说明 | 必须检查 | 主要输出 |
| --- | --- | --- | --- |
| 1. 销售与需求形成 | 销售发生后，Amazon 运营根据目标或系统根据健康度触发需求 | 销售、ASIN、评分、评价缺口、历史计划 | 新需求 |
| 2. 用户运营评估 | 判断需求是否成立、是否可做、优先级如何 | ASIN 健康、目标数量、历史完成、当前资源、风险 | 已确认需求 / 待补充 / 驳回 |
| 3. 计划生成 | 将需求转为推新、回评或免评计划 | 用户池、渠道容量、目标、周期 | 计划草案 |
| 4. 计划复核与审批 | 对计划做规则、额度和风险复核，再进入审批 | 黑名单、频控、渠道风险、真实人额度、审批权限 | 已批准计划 |
| 5. 执行拆解 | 把计划拆成渠道任务和人工任务 | 可触达用户、素材、客服负载、KOC / KOL协作 | 推送任务 / TEL任务 / 客服工单 / 协作任务 |
| 6A. 评价型执行 | 推新、回评进入用户触达、服务与评价链路 | 真实人、订单、历史、额度、风险、售后情况 | 当前处理路径 |
| 6B. 免评型执行 | 免评以 KOC / KOL 与站外流量为核心，同时可由 IM / EDM / APP 等协同参与 | 合作对象、内容、Code、渠道、素材、节奏、免评额度 | 内容任务 / 引流任务 / 带货任务 |
| 7A. 用户真实提交评价 | 记录用户是否已经实际提交评价 | 用户反馈、提交证据、对应计划、真实人累计额度 | 已提交评价事实 |
| 7B. 免评结果跟踪 | 记录免评计划的执行结果 | 内容发布、点击、Code、订单、转化、销量、权重变化 | 免评执行结果 |
| 8. 评价确认 | 区分用户提交与 Amazon 展示结果 | Amazon 是否展示、是否能核验、是否属本计划 | 计入完成 / 待确认 |
| 9. 结果回流 | 把评价结果与免评结果重新反馈给经营与计划层 | 计划完成、ASIN 健康、流量结果、风险变化、用户标签 | 新一轮决策输入 |

---

## 6. 关键业务支线

### 6.1 主动触达支线

```mermaid
flowchart LR
    A["计划通过"] --> B["筛选可触达用户池"]
    B --> C["真实人识别 + 人群画像 + 额度校验"]
    C --> D["渠道分配"]
    D --> D1["IM"]
    D --> D2["EDM"]
    D --> D3["APP"]
    D --> D4["TEL"]
    D1 --> E["用户回应"]
    D2 --> E
    D3 --> E
    D4 --> E
    E --> F["每次回应都重做身份 / 历史 / 额度 / 风险核验"]
    F --> G["订单核验"]
    G --> H["服务 / 跟进"]
    H --> I["用户真实提交评价"]
```

#### 关键规则

1. IM、EDM、APP 可自动化；TEL 属于人工执行渠道。
2. `IM` 需要识别用户分层、绑定玩具、设备、测评 / 免评额度和标签流转。
3. `EDM` 需要识别最近打开、最近回复、点击评论链接但未回复、月度收信次数、最近 3 / 5 次 0 打开、邮箱类型、退订和硬退信。
4. 计划生成前必须先检查：
   - 用户是否可触达
   - 是否命中风险
   - 是否超频
   - 是否符合站点 / 国家 / 产品目标
   - 是否接近或达到真实人额度上限
5. 用户回应后，不能沿用上一次判断结果，必须重新检查当前身份、订单、设备、地址、历史、额度与风险状态。

### 6.2 免评执行支线

```mermaid
flowchart LR
    A["免评计划通过"] --> B["拆解执行方案"]
    B --> C1["KOC / KOL协作"]
    B --> C2["IM / EDM / APP辅助触达"]
    B --> C3["内容 / 运营协同"]
    C1 --> D["内容发布 / Code使用 / 站外引流"]
    C2 --> D
    C3 --> D
    D --> E["跟踪点击、跳转、Code、订单、转化、销量与权重变化"]
    E --> F["结果回流到ASIN健康与后续计划"]
```

#### 关键规则1

1. 免评计划不是评价型计划的弱化版本，而是以站外流量、带货、销量和权重结果为终点的独立闭环。
2. KOC / KOL 是免评计划的核心执行通道，但 IM、EDM、APP 等也可以参与协同。
3. 同一真实人每月最多参与 `4 次免评`；免评额度也要做预警、预占和拦截。
4. 免评计划不以“用户提交评价”作为完成条件，必须另行跟踪内容发布、Code、点击、订单、转化、销量和权重变化。
5. 如果免评执行过程中发生用户互动、售后或返款等行为，仍须进入统一的身份与风险判断机制。

### 6.3 被动售后与 TEL 支线

```mermaid
flowchart LR
    A["用户主动联系 / 电话呼入"] --> B["接入即预查"]
    B --> C["识别来源、身份、订单、历史、风险"]
    C --> D{"是否有售后问题"}
    D -->|有| E["问题分类与解决方案"]
    E --> F["确认是否解决 / 是否满意"]
    F --> G["满意后进入回评 / 测评邀请"]
    D -->|无| H["确认无其他需求"]
    H --> I["可进入测评邀请"]
    G --> J["记录电话 / 工单 / 后续跟进"]
    I --> J
```

#### 关键规则2

1. TEL 当前至少包含两类入口：
   - 计划生成后的人工外呼任务
   - 用户从 Amazon 页面或说明书主动呼入
2. 有售后问题时，必须先解决售后，再谈评价或测评邀请。
3. 电话中需要尽量确认：
   - 购买平台
   - 订单号
   - 产品型号 / 款式 / 颜色
   - 购买时间
   - 问题类型
   - 是否有图片、视频或其他凭证
4. 每通电话结束后，至少要记录：
   - 来电时间
   - 来源
   - 联系方式
   - 订单号
   - 问题类型和描述
   - 处理方案
   - 是否已解决
   - 是否需要后续跟进
   - 是否邀请测评 / 回评
   - 用户是否接受
5. 当前电话业务的核心是：
   - 自然单回评转化
   - 充分利用电话用户的测评资源

### 6.4 风险 / 诈骗拦截支线

```mermaid
flowchart LR
    A["新订单同步 / 主动触达回应 / 用户接入 / 退款申请 / 再次跟进"] --> B["重新做风险识别"]
    B --> C{"是否命中强关联"}
    C -->|是| D["直接进入高风险或黑名单链路"]
    C -->|否| E{"是否命中弱关联"}
    E -->|是| F["进入高风险观察 + 人工复核"]
    E -->|否| G["继续正常流程"]
    D --> H["拦截自动退款、继续推送、自动放行"]
    F --> H
    H --> I["提醒客服 / 用户运营 / 审核人员"]
```

#### 已确认风险口径

| 风险类型 | 关联项 | 处理原则 |
| --- | --- | --- |
| 强关联 | 邮箱、设备号、电话、收件人姓名+地址、订单号、聊天记录、Profile ID、收款信息 | 一旦命中，可直接进入高风险或黑名单链路 |
| 弱关联 | IP 单独命中、姓名单独命中、同址异名 | 进入高风险观察，不直接认定诈骗 |

#### 已确认业务问题

1. 当前真实事故中存在“双重退款”风险：
   - APP / OA 已退款
   - 用户又向 Amazon 申请退款
2. 需要把 Amazon 退款与 OA 返款自动比对。
3. 高风险用户一旦标记，支付 / 返款需要人工复核。
4. 客服、审核、退款等环节必须都能看到风险提醒。
5. 非 APP 用户如果直接走邮件退款，因缺少设备、注册邮箱等维度，风险识别能力明显下降。
6. 风险判断不是一次性的接入动作，而是每次有效互动都要重新执行。

### 6.5 客服工单与客服管理支线

```mermaid
flowchart LR
    A["用户消息进入 / 推送转人工 / 售后触发 / 风险触发"] --> B["生成工单"]
    B --> C["按班次、在线状态、当前负载自动分配"]
    C --> D["客服处理"]
    D --> E{"处理结果"}
    E -->|等待用户| F["等待用户回复"]
    E -->|等待内部| G["等待内部协同"]
    E -->|答应配合| H["生成后续跟进"]
    E -->|疑似诈骗| I["转风险链路"]
    E -->|已解决| J["关闭工单"]
    D --> K["回复效率 / 转化 / 目标完成统计"]
```

#### 工单与管理事实

1. 客服相关模块不只包括工单，还包括：
   - 出勤管理
   - 排班管理
   - 回复效率统计
   - 转化统计
   - 目标管理
2. `排班` 与 `在线状态` 会直接影响自动分配。
3. `工单状态`、`答应配合状态`、`风险状态` 必须拆开存。
4. 客服转化要区分：
   - RSO 回评
   - RDO 测评
5. 回复效率至少要统计：
   - 回复用户数
   - 处理工单数
   - 发送消息数
   - 平均 / 中位数 / 最大 / 最小首次回复时长
6. 转化统计至少要看：
   - 登记订单数
   - 获取评价数
   - 评价完成率
7. 主管需要看到出勤、排班、绩效、目标完成和工单分配，而不是只看单个会话。

---

## 7. 真实人识别、用户上下文与额度规则

### 7.1 真实人识别原则

1. 当前系统不应只围绕 `JOYHUB ID` 看用户，而应同时围绕：
   - 账号
   - 订单
   - 实际收件人
   - 设备
   - 联系方式
   - 风险关系
2. 如果用户在 JOYHUB 内提交订单，则订单可直接关联到当前 JOYHUB ID。
3. 如果用户通过邮件联系：
   - 先问是否有 JOYHUB ID
   - 再用注册邮箱与 JOYHUB ID 做关系查询
4. 如果用户通过电话联系：
   - 先确认是否注册 APP
   - 结合电话、订单、收件人、地址、设备、邮箱继续识别
5. 非 APP 用户如需继续参与相关流程，应优先引导注册 APP，再继续后续动作。

### 7.2 实际收件人判定

| 情况 | 处理原则 |
| --- | --- |
| 标准化后姓名 + 地址完全一致 | 直接认为是同一实际收件人 |
| 地址一致但姓名不同 | 只认为存在家庭 / 关联风险，不直接判定同一人 |
| 邮箱不同、JOYHUB ID 不同 | 不能单独否定“同一实际人” |
| 订单号命中历史异常 | 应立即拉出历史上下文和风险记录 |

### 7.3 用户上下文卡

客服和用户运营在必要节点应能看到：

| 字段组 | 例子 |
| --- | --- |
| 当前身份 | JOYHUB ID、邮箱、电话、真实人 ID、当前订单 |
| 历史交易 | 历史订单、最近购买、退款 / 返款、目标 ASIN 购买情况 |
| 历史服务 | 历史工单、聊天、电话、承诺、提醒、关闭原因 |
| 历史风险 | 黑名单、关联账号、疑似诈骗、双重退款、异常订单 |
| 当前设备 | 设备号摘要、设备型号 / 类型、系统版本、APP 版本、最近设备变化 |
| 触达历史 | IM / EDM / APP / TEL 最近触达、回复、退订、投诉 |

### 7.4 额度规则

| 规则 | 统计对象 | 计数口径 |
| --- | --- | --- |
| 月度测评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 |
| 月度免评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 |
| 累计真实提交评价最多 12 个 | 真实人 | 用户真实提交评价后立即计数 |

### 7.5 额度控制原则

1. 额度判断必须放在 `真实人识别` 之后，而不是只看单一账号。
2. 系统不能等到真正超限才提示，必须在接近上限时提前预警。
3. 一旦 `已用 + 进行中 + 已预占 + 本次拟发送` 会导致超限，就不能进入自动推送。
4. `Amazon 未展示` 不影响 12 次累计额度，因为口径已经确认按 `真实提交` 计数。

---

## 8. 渠道专属补充事实

### 8.1 IM

- 用户需要分层：未参与过、参与过、长期测评人。
- 触发条件包括注册 App、绑定玩具、识别绑定产品。
- 需要校验设备 ID、黑名单、绑定产品、额度与标签。
- 用户提交订单号、返款账号、评论截图 / 链接后，要继续做订单核验和资格登记。

### 8.2 EDM

- EDM 不是简单“发邮件”，而是独立的筛选与节奏引擎。
- 需要支持：
  - 最近打开时间
  - 最近回复时间
  - 打开次数
  - 最近 3 / 5 次推送 0 打开
  - 点击评论链接但未回复时长
  - 单月收信次数
  - 各邮件类型发送次数
  - 邮箱后缀标签
  - 国家站点
  - 退订、硬退信、风险用户、黑名单、OA 无资格用户排除

### 8.3 APP

- APP 侧至少要纳入：
  - 注册邮箱
  - 设备号
  - 设备型号 / 类型
  - APP 版本
  - 系统版本
  - 用户行为数据
  - 绑定玩具
  - 活跃与点击行为
- APP 不只是触达渠道，也是身份识别、设备变化和行为画像的重要来源。

### 8.4 TEL

- TEL 同时承担主动外呼和被动来电。
- 其价值不只是“打电话”，而是：
  - 解决售后
  - 捕捉自然单回评机会
  - 充分利用电话用户的测评资源

---

## 9. 评价结果规则

### 9.1 必须拆开的两个节点

```mermaid
flowchart LR
    A["用户已真实提交评价"] --> B["计入真实人累计评价额度"]
    B --> C{"Amazon是否展示 / 是否可核验"}
    C -->|展示或可核验| D["计入计划完成"]
    C -->|未展示 / 暂不可核验| E["保留用户已提交事实"]
    E --> F["进入待确认 / 异常观察"]
    D --> G["更新ASIN健康与计划完成度"]
```

### 9.2 原因

1. 用户可能确实已经提交评价。
2. Amazon 可能因为其他原因不展示该评价。
3. `额度计数` 与 `计划完成确认` 不是同一个业务事实。
4. 如果系统只保留一个“评价完成”状态，会把平台展示问题错误归因给执行人员或用户。

---

## 10. 贯穿全程的数据检查点

| 检查点 | 发生时机 | 核心检查 |
| --- | --- | --- |
| 经营检查 | 需求形成前 | 销售、ASIN、评分、评价缺口、历史计划 |
| 计划检查 | 生成计划前 | 人群、渠道、容量、规则、黑名单 |
| 画像检查 | 生成人群时 | 国家、站点、性别、年龄、绑定玩具、产品关系、活跃、历史行为 |
| 额度检查 | 生成人群、发送前、继续推进前 | 测评 4、免评 4、累计真实提交 12、进行中与已预占 |
| 身份检查 | 首次接入与每次有效互动时 | JOYHUB、邮箱、电话、设备、订单、地址、历史记录 |
| 互动复检 | 主动触达回应、再次联系、补充订单号、客服回访时 | 关键属性是否变化，是否出现新订单、新地址、新设备、新返款记录 |
| 风险检查 | 每次有效互动、退款、返款、继续推送前 | 双重退款、强弱关联、黑名单、历史异常 |
| 结果检查 | 评价提交与确认后 | 首评 / 回评、是否属本计划、是否展示、ASIN 健康变化 |

---

## 11. 第二步的新入口

第二步不再按旧版页面链路推进，而改成：

### 11.1 共用能力图

1. 真实人识别与用户上下文卡
2. 人群生成与画像拆解
3. 额度与频控控制
4. 每次有效互动复检
5. 风险与黑名单

### 11.2 渠道 / 模块专属流程图

1. IM
2. EDM
3. APP
4. TEL
5. 客服工单
6. 客服管理支撑
7. 评价完成
8. 免评执行

### 11.3 每张图都必须回答

- 进入条件是什么
- 要先查什么
- 如何判断
- 写入什么
- 状态怎么变
- 何时提醒
- 何时拦截
- 何时转人工

---

## 12. 下一次继续工作时的直接提示

1. 先读取本文件。
2. 不要重新讨论“是否从销售开始”“是否保留免评”“评价提交与展示是否拆开”，这些已确认。
3. 额度口径按当前版本执行：
   - 测评每月最多 4
   - 免评每月最多 4
   - 同一真实人累计真实提交评价最多 12
4. 不要再把风险判断理解成“首次接入才做一次”；每次有效互动都需要重做判断。
5. 不要再把第二步按页面链路拆；直接进入 `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`。
6. 旧版 `v1` / `v1.1` 保留为历史版本，不再作为后续主口径。

---

## 13. 本版结论

USER 部门未来系统的核心，不是单独记录“谁评价了”，而是把以下内容放进同一条可追踪闭环中：

1. 销售与需求
2. 计划生成与审批
3. 真实人识别与用户上下文
4. 测评 / 免评 / 累计评价额度控制
5. IM / EDM / APP / TEL / 客服协同
6. 用户身份与订单核验
7. 售后服务与评价引导
8. 免评执行与站外流量结果
9. 用户真实提交评价
10. Amazon 展示与系统确认
11. ASIN 健康回流
12. 风险与黑名单拦截

只有这条闭环建立起来，后续的点击设计、页面设计和数据设计才不会彼此脱节。