danyang-match/公益红娘工作台与人工服务SOP详细设计.md

# 丹阳公益婚恋服务平台
# V1.0 公益红娘工作台与人工服务SOP详细设计

版本：V1.0  
适用范围：公益红娘工作台、运营管理后台、妇联/工会/公益服务中心等参与机构  
核心目标：让公益红娘“有标准地服务、有边界地介入、有记录地跟进”，减少对个人经验和微信群/Excel/纸质记录的依赖

---

# 第一章 设计目标

公益红娘不是传统商业婚介销售。

在本平台中，公益红娘承担的是：

> **人工辅助匹配 + 用户服务 + 沟通协助 + 线下活动衔接。**

红娘工作台必须解决：

1. 今天有哪些用户需要处理
2. 每个用户现在是什么状态
3. 用户真正希望得到什么帮助
4. 系统已经找到哪些合适候选
5. 哪些候选值得人工推荐
6. 已经推荐给用户什么人
7. 用户有没有回应
8. 下一次什么时候跟进
9. 服务什么时候可以结束
10. 哪些问题需要转运营、审核或风控

核心原则：

> **系统帮助红娘减少查资料和重复劳动，红娘帮助系统处理复杂的人际问题。**

---

# 第二章 公益红娘角色定位

红娘是：

```text
服务人员
+
人工匹配辅助者
+
线下婚恋服务连接者
```

红娘不是：

```text
销售顾问
付费转化人员
用户账号代运营人员
情感操控者
平台管理员
风控调查员
```

---

# 第三章 红娘最重要的三条边界

## 第一条

> 红娘可以推荐，但不能替用户喜欢。

## 第二条

> 红娘可以协助联系，但不能未经授权直接泄露联系方式。

## 第三条

> 红娘可以了解用户需求，但不能因为服务需要无限访问用户隐私。

---

# 第四章 红娘服务总流程

```text
用户申请红娘帮助
↓
生成服务单
↓
系统分配/红娘接单
↓
查看用户基础情况
↓
理解服务需求
↓
必要时第一次沟通
↓
系统生成候选
↓
红娘人工筛选
↓
发送候选推荐
↓
用户查看并自主决定
↓
红娘跟进
↓
继续推荐 / 调整建议 / 活动推荐
↓
形成进一步了解
↓
继续跟进
↓
服务完成
```

---

# 第五章 红娘工作台一级导航

建议：

```text
工作台
服务申请
我的用户
待跟进
红娘推荐
活动协同
```

不需要大量菜单。

---

# 第六章 红娘工作台首页

首页目标：

> 一打开就知道今天先处理什么。

建议布局：

```text
今日待处理
├── 新服务申请
├── 待首次联系
├── 今日待跟进
├── 用户待回复
└── 推荐后待反馈

我的服务
├── 服务中
├── 等待用户
└── 即将超时
```

---

# 第七章 首页不做大数据驾驶舱

红娘首页不要堆：

- 用户总数
- 平台GMV
- 男女比例大图
- 地区热力图
- 各种排行榜

这些不是红娘每天完成服务所需要的信息。

---

# 第八章 红娘工作台核心状态

服务单状态：

```text
submitted
assigned
in_service
waiting_user
completed
cancelled
```

---

# 第九章 submitted

表示：

> 用户已提交申请，尚未明确由谁负责。

后台显示：

> 新申请。

---

# 第十章 assigned

表示：

> 已经分配给具体红娘，但服务尚未正式开始。

需要尽快：

> 首次查看并处理。

---

# 第十一章 in_service

表示：

> 正在为用户提供服务。

包括：

- 理解需求
- 推荐候选
- 调整建议
- 活动推荐
- 后续跟进

---

# 第十二章 waiting_user

表示：

> 当前已经完成红娘侧动作，正在等待用户回应。

例如：

```text
已经推荐3位候选
↓
等待用户查看
```

不应该继续每天重复打扰用户。

---

# 第十三章 completed

表示：

> 本次服务目标已经完成或阶段性结束。

不代表：

> 用户一定成功牵手。

---

# 第十四章 cancelled

适用于：

- 用户主动取消
- 重复服务单合并
- 用户退出婚恋服务
- 账号状态异常导致无法继续服务

---

# 第十五章 用户可以申请的服务类型

沿用已确定范围：

```text
帮我推荐合适的人
帮我看看择偶条件
帮我联系意向对象
想参加线下活动
匹配很久无结果
不知道怎么开始聊天
其他
```

内部编码建议：

```text
recommend_partner
review_preference
contact_intention
join_activity
no_match_help
chat_help
other
```

---

# 第十六章 一个服务单只解决一个主要目标

不要让一个服务单同时写：

> 推荐对象+活动+聊天+资料修改+投诉。

如果出现多个明显不同任务：

红娘可以拆分服务记录或创建关联任务。

但V1不必做复杂工单系统。

---

# 第十七章 用户申请后的第一步

红娘打开服务详情后，首先看：

```text
用户基本资料
择偶条件
当前婚恋状态
服务申请内容
推荐历史摘要
红娘历史服务摘要
```

不是先打电话。

---

# 第十八章 红娘服务详情三栏布局

PC推荐：

```text
左栏：用户信息
中栏：服务记录/历史
右栏：当前操作
```

---

# 第十九章 左栏：用户摘要

展示：

```text
头像
展示名
年龄
身高
所在区域
学历
职业类别
婚姻状况
子女情况
已实名
已审核
婚恋状态
```

---

# 第二十章 左栏：择偶条件

优先显示：

```text
必须符合
最好符合
```

例如：

```text
必须符合
年龄 30～38
丹阳/镇江
可接受离异

最好符合
本科以上
不吸烟
1～2年内有结婚计划
```

---

# 第二十一章 红娘不能看到的内容

默认不展示：

- 身份证
- 完整手机号
- 用户完整实名信息
- 私人聊天正文
- 举报证据
- 风控调查详情
- 精确住址

---

# 第二十二章 用户联系方式

红娘若确实需要进行服务沟通：

可通过受控联系方式联系用户。

工作台默认建议：

> 点击“联系用户”。

由系统显示必要联系方式或提供内部拨号信息。

查看完整手机号应根据角色权限控制。

---

# 第二十三章 第一次服务判断

红娘打开服务单后，首先判断：

```text
需求是否明确？
资料是否足够？
择偶条件是否合理可执行？
是否已经存在合适候选？
是否有安全/账号异常？
```

---

# 第二十四章 服务前异常检查

若发现：

```text
账号封禁
资料重新审核
明显风险状态
服务已退出
```

不得继续普通婚恋推荐。

应：

> 暂停服务并根据状态转相应处理。

---

# 第二十五章 首次联系是否必须

不是所有服务单都必须电话沟通。

例如：

> “帮我推荐合适的人”

如果用户资料和条件已经非常清楚：

红娘可以直接进入候选筛选。

---

# 第二十六章 必须进一步确认的情况

例如：

- 服务描述太模糊
- 条件互相矛盾
- “必须符合”过多导致0候选
- 用户提出特殊需求
- 用户明确要求红娘联系
- 近期婚恋状态发生变化

这种情况下需要进一步沟通。

---

# 第二十七章 首次沟通目标

第一次沟通不是“聊得越久越好”。

只需要搞清：

```text
用户当前最想解决什么
哪些条件是真正不能接受
哪些条件只是理想偏好
近期是否愿意见面
是否愿意参加活动
是否愿意接受红娘推荐
```

---

# 第二十八章 首次沟通不要重新问完整资料

平台已有的信息：

> 不要再问一遍。

例如系统已有：

```text
32岁
本科
丹阳
未婚
```

红娘不要重新：

> “请问你今年多大？”

降低用户负担。

---

# 第二十九章 红娘沟通记录

每次正式沟通后，创建：

```text
MatchmakerFollowup
```

至少记录：

```text
时间
沟通渠道
内容摘要
结果
下一步
下次跟进时间
```

---

# 第三十章 跟进渠道

建议：

```text
平台内
电话
线下面谈
活动现场
其他
```

如果未来使用微信工作号：

可以增加。

---

# 第三十一章 跟进记录原则

只记录：

> 服务必要摘要。

不要把用户所有私人谈话逐字记录。

错误：

```text
用户和前任交往了3年，某年某月发生……
```

正确：

```text
用户更重视稳定沟通，希望对方近期有明确婚姻计划。
```

---

# 第三十二章 跟进内容结构

建议：

```text
沟通内容
处理结果
用户意向
下一步行动
```

---

# 第三十三章 下一次跟进

每条跟进可以设置：

```text
next_followup_at
```

红娘首页自动进入：

> 今日待跟进。

---

# 第三十四章 不要依赖红娘自己记日历

工作台必须帮助红娘记：

```text
谁需要联系
什么时候联系
为什么联系
上次聊了什么
```

这是系统价值之一。

---

# 第三十五章 候选生成

红娘点击：

> 查看合适候选

调用：

> Match Engine。

不是直接查询全部用户。

---

# 第三十六章 候选必须先通过

```text
Eligibility
+
A Required → B
+
B Required → A
```

也就是说：

> 系统先做硬筛。

---

# 第三十七章 红娘候选列表

每张卡建议：

```text
头像
展示名
年龄
区域
学历
职业
婚姻状态

综合：很合适

必须条件
✓ 全部符合

推荐理由
✓ 年龄符合双方要求
✓ 都愿意长期在丹阳生活
✓ 婚姻计划接近
```

---

# 第三十八章 红娘可展开“匹配详情”

展开可看到：

```text
年龄       双方符合
地区       双方符合
婚姻状态    双方符合
子女       双方符合
学历       A偏好未满足
身高       符合
婚姻计划    较一致
生活方式    部分一致
```

---

# 第三十九章 不显示复杂公式

不要给红娘看：

```text
ScoreAB 87.34
ScoreBA 81.72
MutualScore 83.946
```

可以后台技术调试时保留。

红娘界面用：

```text
很合适
比较合适
值得了解
```

---

# 第四十章 红娘人工筛选价值

红娘主要判断：

- 候选是否和用户当前服务需求吻合
- 用户刚刚补充的偏好是否值得考虑
- 是否近期适合线下见面
- 是否已经推荐过类似对象
- 是否适合本次服务阶段

---

# 第四十一章 红娘不能重新创造一套匹配规则

不能出现：

> 系统认为不符合，但红娘觉得“男方条件好”，强行推荐。

尤其不能突破：

> 用户Required。

---

# 第四十二章 候选不适合的人工标记

红娘可以选择：

```text
本次不推荐
```

并可记录内部原因：

```text
本次服务方向不符
近期已推荐相似用户
用户明确补充不考虑该情况
其他
```

---

# 第四十三章 人工不推荐不等于永久Pass

红娘本次不推荐：

> 不自动替用户写入passed。

因为用户本人还没有表达拒绝。

---

# 第四十四章 候选推荐数量

一次人工推荐建议：

> 1～3位。

不要：

> 一次推20人。

公益红娘的价值是：

> 帮用户做一定人工筛选。

---

# 第四十五章 推荐理由要求

红娘发送推荐前填写/确认理由。

建议系统先自动生成：

```text
年龄、地区和婚姻计划比较符合，
双方都希望长期在丹阳生活。
```

红娘可以编辑。

---

# 第四十六章 推荐理由不能虚构

不能写：

> 对方人特别好。

如果红娘根本没接触过对方。

只能基于：

- 已有资料
- 已有明确服务事实
- 合法授权范围内的信息

---

# 第四十七章 发送推荐

流程：

```text
红娘选择候选
↓
确认推荐理由
↓
系统再次检查候选有效性
↓
创建MatchmakerRecommendation
↓
发送系统通知
↓
用户端“红娘推荐”
```

---

# 第四十八章 推荐发送前必须二次校验

因为候选可能刚刚：

- 暂停寻找
- 被封禁
- 修改条件
- 拉黑用户
- 成功牵手

服务端重新验证。

---

# 第四十九章 用户收到红娘推荐

用户看到：

```text
公益红娘为你推荐了一位朋友

王女士 · 32岁
丹阳
本科
教师

推荐理由：
年龄、地区和婚姻计划比较符合。

[查看资料]
```

---

# 第五十章 用户自主操作

进入资料后：

```text
喜欢
不合适
```

仍然由用户本人点击。

---

# 第五十一章 红娘不能知道用户浏览的每一个细节

红娘需要看到的反馈：

```text
未查看
已查看
已喜欢
不考虑
已互相喜欢
```

足够服务。

不需要：

> 用户在页面停留17秒。

---

# 第五十二章 推荐状态

建议：

```text
pending_view
viewed
liked
passed
mutual_match
expired
```

---

# 第五十三章 推荐有效期

候选关系可能变化。

因此推荐可设置：

> 业务有效状态实时判断。

不一定必须用固定“7天过期”。

如果目标已经不可推荐：

状态自动：

```text
expired
```

---

# 第五十四章 推荐后跟进

不要刚推荐5分钟就电话问：

> “你觉得怎么样？”

建议给用户合理时间。

跟进时间：

> 可由红娘设定。

例如：

```text
1～3天后
```

但不写死。

---

# 第五十五章 用户已喜欢候选

如果用户已经点击喜欢：

红娘可以看到：

> 用户已表达喜欢。

如果对方还没回应：

红娘默认：

> 不介入。

---

# 第五十六章 不替用户催对方

A喜欢B。

红娘不要立刻：

> 打电话催B赶快选A。

除非A明确申请：

> 帮我联系意向对象

并且走专门流程。

---

# 第五十七章 联系意向对象服务

服务类型：

```text
contact_intention
```

流程：

```text
A提出希望红娘协助
↓
确认A明确授权
↓
检查B状态
↓
向B发送中性邀请
↓
B自主决定
```

---

# 第五十八章 重要：联系意向对象的同意机制

当前产品中：

> “红娘在什么前置同意条件下可以主动联系另一位用户”

仍属于需要最终确认的业务细节。

V1实现建议采用更保守方案：

> **A明确发起本次协助请求后，红娘只能通过平台系统向B发送一次中性意向通知，不能直接提供联系方式，也不默认电话联系B。**

如后续确定允许电话联系，应另行补充：

- 用户事先授权范围
- 联系频率
- 隐私政策说明
- 拒绝后停止联系规则

---

# 第五十九章 B收到的通知

建议：

> 有一位平台用户希望进一步了解你，公益红娘受其委托向你发出邀请。是否愿意查看对方资料？

按钮：

```text
查看资料
暂不考虑
```

---

# 第六十章 不告诉B过多信息

在B同意查看之前：

> 不发送A完整婚恋资料。

---

# 第六十一章 B拒绝

如果B选择：

> 暂不考虑。

则：

- A收到中性结果
- 红娘结束本次联系
- 不再重复骚扰B

---

# 第六十二章 给A的拒绝反馈

建议：

> 对方目前暂未选择进一步了解，公益红娘可以继续为你推荐其他合适的人。

不要：

> 对方嫌你年龄大。

即使红娘知道原因，也不应直接传播伤害性评价。

---

# 第六十三章 红娘协助择偶条件

服务类型：

```text
review_preference
```

适用于：

- 长时间无候选
- Required过多
- 用户不知道怎么设置
- 条件之间矛盾

---

# 第六十四章 工作台条件分析

系统可显示：

```text
当前必须条件：5项

系统候选池：
基础符合 186人
应用你的必须条件后 3人
最终双方符合 0人
```

---

# 第六十五章 红娘解释

正确：

> 当前符合你所有“必须符合”条件的人比较少，可以看看哪些条件更适合改成“最好符合”。

避免：

> 你的要求太高。

---

# 第六十六章 系统条件建议

例如：

```text
学历
当前：必须本科以上

如果改为“最好符合”
预计候选范围会扩大。
```

不要承诺具体人数，除非系统实时准确计算。

---

# 第六十七章 谁修改条件

首选：

> 用户本人在小程序修改。

红娘发送：

> 查看我的择偶条件

入口。

---

# 第六十八章 红娘代修改

V1原则：

> 不提供常规代修改。

如果未来为特殊群体提供线下协助录入：

必须：

- 用户明确确认
- 操作记录
- 变更内容可回看

---

# 第六十九章 匹配很久无结果

服务类型：

```text
no_match_help
```

系统应先给红娘诊断摘要。

---

# 第七十章 无结果诊断

可能包括：

```text
候选池过小
必须条件过多
地区限制严格
用户较少主动表达喜欢
资料吸引信息较少
近期活跃度较低
推荐已较充分
```

---

# 第七十一章 禁止负面用户标签

不要后台生成：

```text
条件差
低价值用户
没人喜欢
难匹配用户
```

建议使用中性状态：

```text
候选范围较小
长期未形成双向匹配
需要人工协助
```

---

# 第七十二章 无结果处理顺序

```text
检查资料完整性
↓
检查条件范围
↓
重新生成候选
↓
人工推荐
↓
推荐适合活动
↓
持续跟进
```

---

# 第七十三章 活动服务

用户选择：

> 想参加线下活动。

红娘工作台显示：

> 当前符合基本条件的活动。

---

# 第七十四章 红娘可以推荐活动

例如：

```text
丹阳青年公益相亲会
9月20日
25～40岁
报名中
```

按钮：

> 推荐给用户

---

# 第七十五章 红娘不能替用户报名

活动报名最终：

> 用户本人确认并提交。

避免：

- 时间冲突
- 条款未读
- 活动规则未确认

---

# 第七十六章 特殊线下协助报名

如果未来存在工作人员线下帮助不会操作小程序的人群：

需要独立：

> 代办授权机制。

V1正常线上流程不做。

---

# 第七十七章 聊天帮助服务

服务类型：

```text
chat_help
```

红娘可以提供：

- 开场建议
- 聊什么话题
- 如何礼貌表达
- 线下见面前注意事项

---

# 第七十八章 红娘不能查看聊天内容

即使用户申请：

> 不知道怎么聊天。

红娘默认仍然：

> 不读取Conversation。

用户可以主动描述情况。

---

# 第七十九章 用户主动提供聊天内容

如果用户自己说：

> “对方刚才这样回复，我不知道怎么回。”

红娘可以针对用户主动提供的信息给建议。

但不要因此获取整个聊天权限。

---

# 第八十章 红娘不能代聊

禁止：

- 帮用户登录账号
- 代发消息
- 冒充用户
- 自动回复

---

# 第八十一章 红娘服务中的风险发现

如果红娘在服务过程中发现：

- 疑似诈骗
- 虚假婚姻状态
- 骚扰
- 广告营销
- 身份异常

不能自行决定封禁。

---

# 第八十二章 风险转交

操作：

```text
标记风险
↓
填写简要原因
↓
转风控
```

系统创建：

> RiskEvent / Report-like internal case

---

# 第八十三章 红娘看到风险状态

只需要看到：

```text
正常
暂不可推荐
服务暂停
```

不一定能看到完整风控调查内容。

---

# 第八十四章 风控优先

若用户服务中被Risk暂停：

MatchmakerService：

> 自动进入暂停/不可继续处理状态。

红娘收到：

> 当前用户服务暂时不可继续，请等待平台处理。

---

# 第八十五章 红娘不能主动调查诈骗

红娘不是风控人员。

不要让红娘：

- 调聊天
- 查身份证
- 查举报证据

发现问题后：

> 转交。

---

# 第八十六章 红娘“我的用户”

显示：

```text
服务中
等待用户
已完成
```

---

# 第八十七章 我的用户卡片

建议：

```text
张先生 36岁
丹阳
服务类型：推荐合适对象
状态：服务中
上次跟进：昨天
下次跟进：明天
```

---

# 第八十八章 今日待跟进

系统按照：

```text
next_followup_at <= today
AND
service.status可处理
```

进入列表。

---

# 第八十九章 超时提醒

例如：

> 距离上次有效跟进已超过配置时间。

显示：

```text
待跟进
已超时2天
```

只是工作提醒。

不是用户风险标签。

---

# 第九十章 首次响应指标

平台可以内部统计：

```text
服务申请 → 第一次有效处理
```

的时间。

目标是提高服务及时性。

---

# 第九十一章 不以通话次数作为红娘核心绩效

错误指标：

```text
每天必须打30个电话
```

正确更关注：

```text
有效服务
推荐反馈
按期跟进
用户问题解决
进一步了解结果
```

---

# 第九十二章 红娘服务完成条件

至少满足一种：

```text
已完成本轮人工推荐
用户已进入进一步了解
用户主动暂停/取消
用户已参加适合活动
用户成功牵手
当前阶段无更多合适候选且已反馈
服务目标已解决
```

---

# 第九十三章 完成服务不等于关闭用户

用户以后：

> 可以再次申请红娘帮助。

Service是一次服务记录。

不是永久绑定一个红娘。

---

# 第九十四章 完成服务必须填写结果

例如：

```text
已推荐3位用户，用户已查看
```

```text
协助调整择偶条件，用户已确认修改
```

```text
用户已与一位对象进入进一步了解阶段
```

---

# 第九十五章 服务完成结果编码

建议：

```text
recommendation_completed
preference_adjusted
activity_recommended
mutual_match_formed
getting_to_know
successful
no_candidate
user_paused
user_cancelled
other
```

---

# 第九十六章 用户成功牵手

如果平台已经完成双方确认：

```text
relationship_status = matched_successfully
```

相关普通红娘服务：

> 可以标记完成。

---

# 第九十七章 红娘不能自己点击“成功牵手”

成功必须来自：

> 用户双方确认。

红娘最多：

> 提醒用户可以在系统中确认状态。

---

# 第九十八章 红娘后续回访

对于进入：

```text
getting_to_know
```

的用户，

可以在用户允许和服务范围内安排轻量回访。

---

# 第九十九章 回访目的

不是：

> 打听隐私。

而是：

```text
是否需要继续推荐
是否继续暂停推荐
是否需要红娘帮助
当前服务是否可以结束
```

---

# 第一百章 不问过度私人内容

例如：

> “你们亲密到什么程度了？”

完全没有业务必要。

---

# 第一百零一章 红娘推荐记录永久可追溯

至少知道：

```text
谁
什么时候
给哪个用户
推荐了谁
为什么
用户结果
```

---

# 第一百零二章 同一候选重复推荐

系统必须提醒：

```text
该用户已于8月10日推荐过
结果：不考虑
```

原则上不重复推。

---

# 第一百零三章 不同红娘之间防重复

Recommendation是平台级记录。

不是：

> 每个红娘自己记。

因此另一个红娘接手后也能看到：

> 已推荐历史。

---

# 第一百零四章 红娘服务转交

管理员可以：

> 将服务从红娘A转给红娘B。

转交必须保留：

- 原服务记录
- 历史跟进
- 原推荐

---

# 第一百零五章 转交原因

例如：

```text
工作调整
人员休假
机构调整
用户需求更适合其他红娘
其他
```

---

# 第一百零六章 转交后旧红娘权限

如果服务不再属于其授权范围：

> 不再继续编辑。

是否仍可查看历史根据机构权限决定。

建议：

> 最小权限。

---

# 第一百零七章 红娘离职

必须：

```text
停用Operator
↓
查找其所有active服务
↓
管理员重新分配
```

不能出现用户服务丢失。

---

# 第一百零八章 机构分配策略

V1可支持：

```text
管理员手工分配
红娘主动领取
```

二选一或同时支持。

---

# 第一百零九章 V1更推荐

对早期丹阳本地运营：

> **管理员分配 + 红娘可领取待分配服务**

均可。

不需要复杂自动派单算法。

---

# 第一百一十章 自动分配暂不建设

不需要：

- 负载算法
- AI分单
- 技能路由系统

人员规模小的时候：

> 手工更清晰。

---

# 第一百一十一章 红娘工作台用户搜索

红娘不能拥有：

> 全平台随意搜索全部用户资料

的无限权限。

候选搜索应通过：

> 当前服务上下文。

---

# 第一百一十二章 临时查用户

若业务确实需要：

只能查询：

> 公共/必要婚恋资料。

不允许通过手机号任意查完整隐私档案。

---

# 第一百一十三章 红娘不能建立私人“用户数据库”

平台应要求：

> 不把用户婚恋资料下载到个人Excel/微信/笔记软件长期保存。

所有服务记录尽量回平台。

---

# 第一百一十四章 红娘工作台导出

V1原则：

> 不提供婚恋用户批量导出。

活动执行如需要：

> 使用活动专用脱敏名单。

---

# 第一百一十五章 用户资料展示水印

对于红娘工作台敏感程度较高页面，可考虑轻量动态水印：

```text
张老师 2026-08-28
```

P1实现即可。

---

# 第一百一十六章 红娘数据权限矩阵

| 数据 | 红娘权限 |
|---|---|
| 公共婚恋资料 | 服务必要可见 |
| 择偶条件 | 可见 |
| 推荐历史 | 可见 |
| 红娘服务历史 | 授权范围内可见 |
| 完整手机号 | 按权限/服务必要 |
| 身份证 | 不可见 |
| 私人聊天 | 不可见 |
| 举报证据 | 不可见 |
| 风控详情 | 默认不可见 |
| 活动历史 | 必要摘要 |
| 活动单向意向 | 默认不可见 |

---

# 第一百一十七章 “等待用户”使用规则

红娘已经完成动作，例如：

> 推荐3人。

状态可以：

```text
in_service → waiting_user
```

---

# 第一百一十八章 用户回应后

系统自动或红娘操作：

```text
waiting_user → in_service
```

继续处理。

---

# 第一百一十九章 自动状态更新

例如用户对红娘推荐：

> 已喜欢。

系统可以自动提醒红娘：

> 用户已对推荐对象表达喜欢。

但不一定自动切服务状态。

---

# 第一百二十章 红娘消息提醒

工作台提醒：

```text
新服务申请
用户已回复
推荐对象已失效
今日待跟进
管理员转交服务
```

---

# 第一百二十一章 不要实时弹窗轰炸

工作台采用：

- 数字Badge
- 待办列表
- 页面通知

即可。

---

# 第一百二十二章 红娘与用户是否需要单独聊天

V1建议：

> 不建设“红娘即时聊天系统”作为独立复杂模块。

服务进度可以通过：

- 系统通知
- 服务备注
- 必要电话
- 运营实际沟通方式

完成。

---

# 第一百二十三章 如果需要平台内联系红娘

后续可以增加：

> 服务留言。

但V1不是核心。

避免又建设一套客服聊天系统。

---

# 第一百二十四章 红娘服务进度用户端

用户看到：

```text
已提交申请
↓
公益红娘已接手
↓
正在为你筛选
↓
已有推荐
↓
服务跟进中
↓
本次服务完成
```

---

# 第一百二十五章 不暴露内部操作细节

用户不需要看到：

```text
SQL候选46人
红娘淘汰32人
算法分数81
```

只显示有意义的服务进度。

---

# 第一百二十六章 服务用户体验

红娘服务不能让用户感觉：

> “申请后进入黑洞。”

因此至少需要：

```text
申请成功
已接手
有结果时通知
```

---

# 第一百二十七章 服务暂无候选

正确反馈：

> 当前暂时没有找到完全符合双方条件的对象，我们会继续关注合适的推荐机会。

可以建议：

> 查看择偶条件 / 参加活动。

---

# 第一百二十八章 不能为了“交差”乱推荐

红娘工作台不能以：

> 必须完成推荐数量

作为硬任务。

如果没有合适候选：

> 可以如实结束本轮服务。

---

# 第一百二十九章 公益属性服务原则

公益红娘不做：

```text
充值
VIP销售
高价套餐转化
付费见面
资源优先级售卖
```

服务排序应基于：

- 申请时间
- 紧急程度
- 服务状态
- 实际资源

而不是付费等级。

---

# 第一百三十章 特殊人群服务

如果未来对：

- 残障人士
- 大龄单身
- 困难家庭等

开展专项公益婚恋活动，

可以建立：

> 特定服务项目。

但不能在V1普通用户模型中随意增加敏感标签。

需要专项设计。

---

# 第一百三十一章 红娘不得给用户做“价值分级”

后台禁止：

```text
A级男
B级女
优质资源
低端用户
高价值男嘉宾
```

可以有：

```text
匹配条件摘要
服务优先级
风险状态
```

服务管理标签不等于人的价值等级。

---

# 第一百三十二章 用户照片与红娘判断

红娘可以查看：

> 用户已经审核通过的公开照片。

不能：

> 下载后私下转发给其他用户。

推荐对象查看资料应通过平台。

---

# 第一百三十三章 红娘发候选给用户

系统只发送：

> 平台用户详情入口。

不要：

> 把截图发到微信群。

这样能持续执行权限和隐私控制。

---

# 第一百三十四章 线下红娘服务

如果公益组织线下接待用户：

红娘可通过工作台：

> 搜索服务编号/本人授权信息。

完成服务记录后：

> 回写平台。

---

# 第一百三十五章 纸质材料原则

尽可能少使用。

如果线下确需纸质：

- 最小化字段
- 不打印身份证
- 使用结束后安全销毁
- 不长期堆放个人婚恋档案

---

# 第一百三十六章 服务质量检查

运营管理员可以随机检查：

```text
是否长期未处理
是否存在无记录推荐
是否越权查看
是否有不适当服务用语
是否反复骚扰用户
```

---

# 第一百三十七章 红娘不能高频打扰

用户已经：

> waiting_user

且没有回应。

红娘应遵循合理频率。

不要：

> 一天打3次电话。

---

# 第一百三十八章 用户拒绝红娘继续联系

如果用户明确：

> 暂时不需要红娘服务。

应：

```text
service → completed/cancelled
```

并停止后续主动服务。

---

# 第一百三十九章 用户暂停寻找

所有普通红娘服务：

> 暂停主动推荐。

如果用户已经有进行中的咨询：

可以完成必要收尾。

---

# 第一百四十章 用户退出婚恋服务

服务：

> 自动终止。

红娘收到系统状态更新。

---

# 第一百四十一章 用户成功牵手

系统：

- 停止新红娘推荐
- 当前推荐类服务自动提示完成
- 不再产生候选任务

---

# 第一百四十二章 红娘成功案例收集

如果服务最终成功：

可以询问：

> 是否愿意分享公益服务体验。

默认：

> 不分享。

---

# 第一百四十三章 不能默认拿成功案例宣传

用户明确授权后才可以。

这是独立宣传授权，不属于普通红娘服务。

---

# 第一百四十四章 红娘绩效指标建议

公益服务内部可看：

```text
当前服务用户数
首次响应及时率
按时跟进率
人工推荐数
推荐查看率
推荐Like率
形成Mutual Match数
进入进一步了解数
服务完成率
```

---

# 第一百四十五章 不建议作为绩效核心

```text
打电话数量
推荐人数越多越好
成功牵手排行榜
用户资产质量
```

---

# 第一百四十六章 红娘服务Dashboard

建议：

```text
今日
新申请 5
待首次处理 3
待跟进 8
等待用户 12

服务中 26
即将超时 4
```

足够。

---

# 第一百四十七章 Service Priority

可以简单分：

```text
normal
attention
urgent
```

但urgent只用于：

> 工作时效。

不是给用户贴婚恋等级。

---

# 第一百四十八章 urgent适用

例如：

- 活动马上开始需要确认
- 用户提交安全相关信息，需要转风控

普通“想快点找对象”：

不建议定义urgent。

---

# 第一百四十九章 红娘服务SOP总表

## Step 1 接单

检查：

```text
用户状态
服务类型
服务内容
```

---

## Step 2 理解需求

检查：

```text
资料
择偶条件
匹配历史
必要补充信息
```

---

## Step 3 候选生成

系统：

```text
Eligibility
Required
MutualScore
```

---

## Step 4 人工筛选

红娘：

```text
选择1～3位
确认理由
```

---

## Step 5 用户决定

用户：

```text
查看
喜欢
不合适
```

---

## Step 6 跟进

根据结果：

```text
继续推荐
条件建议
活动推荐
等待
```

---

## Step 7 结束

记录：

```text
服务结果
```

---

# 第一百五十章 “推荐对象”SOP

```text
查看用户条件
↓
生成候选
↓
筛选1～3位
↓
发送推荐
↓
等待用户反馈
↓
需要则继续下一轮
↓
完成
```

---

# 第一百五十一章 “调整条件”SOP

```text
查看当前Required/Preferred
↓
查看候选池
↓
识别过窄维度
↓
给出中性建议
↓
用户本人修改
↓
重新计算候选
↓
完成
```

---

# 第一百五十二章 “联系意向对象”SOP

V1保守流程：

```text
A明确申请
↓
检查B状态
↓
平台向B发送一次中性邀请
↓
B自主选择
├→ 愿意查看
│   ↓
│ 正常关系流程
└→ 暂不考虑
    ↓
   服务反馈A
```

---

# 第一百五十三章 “参加活动”SOP

```text
查看适合活动
↓
推荐用户
↓
用户自己查看活动
↓
用户本人报名
↓
活动模块处理
↓
必要时后续跟进
```

---

# 第一百五十四章 “长期无结果”SOP

```text
查看系统诊断
↓
资料是否完整
↓
Required是否过窄
↓
用户活跃与回应情况
↓
人工候选
↓
活动推荐
↓
必要调整条件
↓
持续服务/完成
```

---

# 第一百五十五章 “聊天帮助”SOP

```text
用户说明困惑
↓
红娘根据公开资料与用户描述
↓
提供沟通建议
↓
用户自己发送
↓
不查看私聊
↓
不代发
```

---

# 第一百五十六章 安全转交SOP

```text
红娘发现异常
↓
停止自行调查
↓
创建风险标记/转交
↓
Risk团队处理
↓
MatchmakerService根据结果继续/暂停/结束
```

---

# 第一百五十七章 工作台必须防止的七种错误

1. 红娘把候选电话直接发给用户  
2. 红娘替用户点喜欢  
3. 红娘无服务关系随意浏览用户  
4. 红娘看私人聊天  
5. 红娘私下Excel保存用户档案  
6. 红娘绕过Required推荐  
7. 红娘为了完成任务强行推荐不合适用户

---

# 第一百五十八章 红娘服务接口建议补充

在此前API基础上：

```text
GET /operator/matchmaker/workbench

GET /operator/matchmaker/services
GET /operator/matchmaker/services/{id}

POST /operator/matchmaker/services/{id}/claim
POST /operator/matchmaker/services/{id}/start
POST /operator/matchmaker/services/{id}/followups
POST /operator/matchmaker/services/{id}/waiting-user

GET /operator/matchmaker/services/{id}/candidates
POST /operator/matchmaker/services/{id}/recommendations

POST /operator/matchmaker/services/{id}/recommend-activity
POST /operator/matchmaker/services/{id}/complete
POST /operator/matchmaker/services/{id}/cancel

POST /operator/matchmaker/services/{id}/risk-referral
```

---

# 第一百五十九章 工作台接口权限

建议：

```text
matchmaker.workbench
matchmaker.service.view
matchmaker.service.claim
matchmaker.service.followup
matchmaker.candidate.view
matchmaker.recommend
matchmaker.activity.recommend
matchmaker.service.complete
matchmaker.risk.referral
```

---

# 第一百六十章 用户服务数据API

红娘获取用户资料：

> 使用专门MatchmakerUserDTO。

不要直接复用：

```text
AdminUserDTO
```

---

# 第一百六十一章 MatchmakerUserDTO

建议：

```text
userId
displayName
avatar
age
height
region
education
occupation
maritalStatus
childrenStatus
interests

relationshipStatus

preferenceSummary

matchSummary
activitySummary

serviceHistorySummary
```

不含：

```text
idNumber
privateChat
riskEvidence
```

---

# 第一百六十二章 工作台高保真关键页面

优先：

```text
R01 登录
R02 工作台
R03 服务申请列表
R04 服务详情
R05 候选推荐
R06 推荐确认
R07 跟进记录
R08 我的用户
```

沿用此前高保真页面规划。

---

# 第一百六十三章 R02工作台

建议：

```text
左侧导航

今日待处理

[新申请 5]
[待首次处理 3]
[今日跟进 8]
[等待反馈 12]

下方：
待处理列表
```

点击卡片进入对应筛选列表。

---

# 第一百六十四章 R04服务详情

三栏：

```text
┌─────────┬──────────────────┬────────────┐
│ 用户资料 │ 服务历史/跟进      │ 当前操作    │
│         │                  │            │
│ 择偶条件 │ Timeline         │ 看候选      │
│         │                  │ 添加跟进    │
│ 状态     │ Recommendation   │ 推荐活动    │
│         │                  │ 完成服务    │
└─────────┴──────────────────┴────────────┘
```

---

# 第一百六十五章 Timeline

时间轴包括：

```text
用户提交申请
红娘接手
首次沟通
推荐候选
用户查看
用户喜欢
跟进
活动推荐
服务完成
```

---

# 第一百六十六章 R05候选推荐

过滤：

```text
系统推荐等级
年龄
地区
```

但不要让红娘自己做复杂数据库筛选。

候选已由系统先筛。

---

# 第一百六十七章 候选详情

可以打开右侧Drawer：

> 快速查看。

但正式用户完整详情：

> 使用统一Profile组件。

---

# 第一百六十八章 R06推荐确认

发送前显示：

```text
推荐给：
张先生

推荐对象：
王女士

系统理由：
年龄、地区、婚姻计划较符合

红娘推荐说明：
[可编辑]
```

按钮：

> 确认推荐

---

# 第一百六十九章 推荐成功反馈

```text
推荐已发送

等待用户查看后，可以在服务详情中继续跟进。
```

---

# 第一百七十章 R07跟进记录

字段：

```text
沟通方式
沟通摘要
处理结果
下一步
下次跟进时间
```

---

# 第一百七十一章 跟进模板

可提供快捷结果：

```text
用户愿意继续了解
用户暂不考虑
等待用户查看推荐
建议调整条件
推荐参加活动
暂时暂停寻找
```

减少输入。

---

# 第一百七十二章 不能全部模板化

允许红娘补充：

> 简短文字备注。

因为人工服务存在复杂情况。

---

# 第一百七十三章 服务质量自动提醒

系统可以检查：

```text
服务已分配但24小时无处理
服务中超过配置时间无跟进
推荐后长时间无状态
```

具体时长：

> 配置化，待运营确认。

不要在代码写死。

---

# 第一百七十四章 用户满意度

V1可以在服务结束后：

> 轻量评价。

例如：

```text
这次公益红娘服务是否对你有帮助？

很有帮助
有帮助
一般
没有帮助
```

不是必须。

---

# 第一百七十五章 不做红娘公开评分

用户评价：

> 用于内部改进。

不前台显示：

```text
张红娘 4.9分
```

避免商业婚介化。

---

# 第一百七十六章 用户投诉红娘

帮助/反馈中可以：

> 对公益红娘服务提出反馈。

如涉及：

- 隐私泄露
- 骚扰
- 不当言语

应转：

> 管理员/风险处理。

---

# 第一百七十七章 红娘敏感访问日志

如果红娘权限允许查看某些非公开联系方式：

每次访问建议记录：

```text
operatorId
userId
dataType
serviceId
time
```

---

# 第一百七十八章 无服务关系访问

红娘尝试查看：

> 与自己没有服务关联的敏感用户数据。

必须：

> 拒绝。

---

# 第一百七十九章 机构范围

红娘默认只能处理：

> 被分配给自己/本机构授权范围的服务。

跨机构需要：

> 明确授权。

---

# 第一百八十章 平台级公益红娘池

未来若多个组织共同运营：

可以有：

```text
平台红娘池
机构红娘池
```

V1数据模型可以支持organizationId。

但无需建设复杂资源调度。

---

# 第一百八十一章 机构协同原则

机构之间：

> 不默认共享全部用户数据。

可以共享：

> 服务任务

前提：

- 业务授权
- 权限明确
- 数据最小化

---

# 第一百八十二章 红娘与审核员职责分离

审核员：

> 判断资料是否符合平台展示要求。

红娘：

> 帮助寻找合适对象。

红娘不能自行：

> 把审核未通过用户改为通过。

---

# 第一百八十三章 红娘与活动管理员职责分离

红娘可以：

> 推荐活动。

不能自动：

> 审核活动报名。

除非同时被授予活动管理员角色。

---

# 第一百八十四章 红娘与风控职责分离

红娘发现问题：

> 转交。

没有风控权限就不能：

> 封禁。

---

# 第一百八十五章 服务异常场景一

红娘准备推荐B。

B刚暂停寻找。

服务端：

```text
TARGET_UNAVAILABLE
```

工作台：

> 候选当前不可推荐。

---

# 第一百八十六章 服务异常场景二

用户服务中突然成功牵手。

工作台：

> 用户已成功牵手，暂停普通推荐。

推荐类服务提示：

> 可完成服务。

---

# 第一百八十七章 服务异常场景三

用户删除红娘推荐对象的Like。

若尚未Match：

Recommendation状态同步。

红娘只需看到：

> 用户当前未选择进一步了解。

---

# 第一百八十八章 服务异常场景四

两名红娘同时接单。

数据库原子更新。

一人成功。

另一人：

> 服务已由其他红娘接手。

---

# 第一百八十九章 服务异常场景五

红娘推荐后目标被封禁。

Recommendation：

```text
expired
```

用户侧不再显示正常候选资料。

红娘收到：

> 推荐对象当前不可继续推荐。

---

# 第一百九十章 服务异常场景六

用户已经暂停寻找，但还有待跟进任务。

工作台提示：

> 用户已暂停寻找。

红娘不继续推新人。

可以做必要收尾。

---

# 第一百九十一章 服务异常场景七

用户明确不想接电话。

如果未来有沟通偏好设置：

> 必须遵守。

V1至少应允许跟进记录中注明：

> 不接受电话联系。

---

# 第一百九十二章 服务异常场景八

用户要求：

> “把对方手机号直接给我。”

红娘不能执行。

正确：

> 通过平台邀请对方自主决定是否进一步联系。

---

# 第一百九十三章 红娘工作台P0功能

```text
登录
工作台
服务列表
服务详情
服务领取/分配
用户必要资料
择偶条件
候选列表
人工推荐
跟进记录
我的用户
服务完成
```

---

# 第一百九十四章 P1功能

```text
活动推荐
联系意向对象流程
风险转交
超时提醒
用户服务评价
服务转交
```

---

# 第一百九十五章 P2功能

```text
工作量统计
质量统计
动态水印
更多服务分析
机构间协同增强
```

---

# 第一百九十六章 红娘服务验收标准

测试时必须确认：

1. 红娘没有服务关系不能访问敏感用户数据  
2. 红娘不能查看身份证  
3. 红娘不能查看私人聊天  
4. Required冲突候选不能推荐  
5. 红娘不能替用户Like  
6. 推荐前目标状态会重新检查  
7. 不同红娘不会重复乱推同一候选  
8. 用户暂停后停止新推荐  
9. 风控限制能立即暂停服务  
10. 服务完成保留全部历史记录  

---

# 第一百九十七章 SOP验收标准

随机给新红娘一张服务单。

不看说明书也应能知道：

```text
现在为什么找我
↓
用户当前是什么情况
↓
我下一步做什么
↓
系统推荐谁
↓
我推荐后发生什么
↓
什么时候回来跟进
↓
什么时候可以结束
```

如果做不到：

> 工作台设计仍然不够清晰。

---

# 第一百九十八章 红娘核心工作流最终图

```text
                    用户申请
                       │
                       ↓
                  MatchmakerService
                       │
                       ↓
                    分配红娘
                       │
                       ↓
              ┌── 理解服务需求 ──┐
              │                  │
              ↓                  ↓
        条件已清晰            需要补充沟通
              │                  │
              └────────┬─────────┘
                       ↓
                 Match Engine
                       ↓
                    候选池
                       ↓
                 红娘人工筛选
                       ↓
                  推荐1～3位
                       ↓
                   用户决定
                 ┌─────┴─────┐
                 ↓           ↓
                Like         Pass
                 │           │
                 ↓           ↓
              Match?      下一候选
                 │
          ┌──────┴──────┐
          ↓             ↓
         否            Mutual
          │             │
        等待            ↓
                    Conversation
                         ↓
                   Getting to Know
                         ↓
                 Successful / 继续服务
```

---

# 第一百九十九章 公益红娘最终服务原则

必须坚持：

> **红娘帮助用户做选择，但不替用户做选择。**

> **系统帮红娘找人，但不把红娘变成机械审核员。**

> **用户的Required是底线，不是红娘可以协商掉的系统规则。**

> **联系方式属于用户本人，不属于红娘可以自由分配的资源。**

> **私人聊天属于用户隐私，不属于红娘的常规服务资料。**

> **没有合适对象时可以如实告诉用户，不需要为了完成任务乱推荐。**

> **每一次推荐、跟进和服务结束都要留下必要记录。**

> **红娘发现风险要及时转交，但不自行做风控调查。**

> **公益服务的评价标准是用户有没有得到真正帮助，而不是推荐了多少人、打了多少电话。**

---

# 第二百章 最终设计结论

公益红娘工作台的真正价值，不是给工作人员增加一个后台系统。

而是把过去可能存在的：

```text
微信群
Excel
纸质表格
个人微信
个人记忆
电话记录
```

逐步变成：

```text
统一服务单
+
统一用户状态
+
系统候选
+
人工判断
+
统一推荐记录
+
统一跟进提醒
+
统一权限控制
+
统一服务结果
```

最终形成：

> **算法做初筛，红娘做服务，平台守边界，用户做决定。**

这套机制既能提高公益组织服务效率，也能避免红娘服务过度依赖某个工作人员个人经验，从而让平台真正做到：

> **人员可以更换，服务不会丢；红娘可以辅助，用户仍然自主；公益服务有温度，同时又有标准。**