qiaoxinjiu/Fulfilled-Knowledge

Fork 0

Files

qiaoxinjiu e31a75d2bb Add under-anything knowledge dashboard

2026-05-27 15:40:32 +08:00

24 KiB

Raw Blame History

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. 已确认目标

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

2. 当前边界与资料依据

2.1 当前纳入范围

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

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

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

2.3 资料依据

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

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

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

3. 角色与职责

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

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

4. 总体业务结构

4.1 主流程

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 主动触达支线

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["用户真实提交评价"]

关键规则

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

6.2 免评执行支线

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

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

6.3 被动售后与 TEL 支线

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

关键规则2

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

6.4 风险 / 诈骗拦截支线

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

已确认风险口径

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

已确认业务问题

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

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

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

工单与管理事实

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

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

7.1 真实人识别原则

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

7.2 实际收件人判定

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

7.3 用户上下文卡

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

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

7.4 额度规则

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

7.5 额度控制原则

额度判断必须放在 真实人识别 之后，而不是只看单一账号。
系统不能等到真正超限才提示，必须在接近上限时提前预警。
一旦 已用 + 进行中 + 已预占 + 本次拟发送 会导致超限，就不能进入自动推送。
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 必须拆开的两个节点

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

9.2 原因

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

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

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

11. 第二步的新入口

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

11.1 共用能力图

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

11.2 渠道 / 模块专属流程图

IM
EDM
APP
TEL
客服工单
客服管理支撑
评价完成
免评执行

11.3 每张图都必须回答

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

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

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

13. 本版结论

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

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

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

24 KiB Raw Blame History Unescape Escape