46 KiB
丹阳公益婚恋服务平台
V1.0 公益红娘工作台与人工服务SOP详细设计
版本：V1.0
适用范围：公益红娘工作台、运营管理后台、妇联/工会/公益服务中心等参与机构
核心目标：让公益红娘“有标准地服务、有边界地介入、有记录地跟进”，减少对个人经验和微信群/Excel/纸质记录的依赖
第一章 设计目标
公益红娘不是传统商业婚介销售。
在本平台中，公益红娘承担的是：
人工辅助匹配 + 用户服务 + 沟通协助 + 线下活动衔接。
红娘工作台必须解决：
- 今天有哪些用户需要处理
- 每个用户现在是什么状态
- 用户真正希望得到什么帮助
- 系统已经找到哪些合适候选
- 哪些候选值得人工推荐
- 已经推荐给用户什么人
- 用户有没有回应
- 下一次什么时候跟进
- 服务什么时候可以结束
- 哪些问题需要转运营、审核或风控
核心原则：
系统帮助红娘减少查资料和重复劳动，红娘帮助系统处理复杂的人际问题。
第二章 公益红娘角色定位
红娘是：
服务人员
+
人工匹配辅助者
+
线下婚恋服务连接者
红娘不是：
销售顾问
付费转化人员
用户账号代运营人员
情感操控者
平台管理员
风控调查员
第三章 红娘最重要的三条边界
第一条
红娘可以推荐，但不能替用户喜欢。
第二条
红娘可以协助联系，但不能未经授权直接泄露联系方式。
第三条
红娘可以了解用户需求，但不能因为服务需要无限访问用户隐私。
第四章 红娘服务总流程
用户申请红娘帮助
↓
生成服务单
↓
系统分配/红娘接单
↓
查看用户基础情况
↓
理解服务需求
↓
必要时第一次沟通
↓
系统生成候选
↓
红娘人工筛选
↓
发送候选推荐
↓
用户查看并自主决定
↓
红娘跟进
↓
继续推荐 / 调整建议 / 活动推荐
↓
形成进一步了解
↓
继续跟进
↓
服务完成
第五章 红娘工作台一级导航
建议：
工作台
服务申请
我的用户
待跟进
红娘推荐
活动协同
不需要大量菜单。
第六章 红娘工作台首页
首页目标：
一打开就知道今天先处理什么。
建议布局：
今日待处理
├── 新服务申请
├── 待首次联系
├── 今日待跟进
├── 用户待回复
└── 推荐后待反馈
我的服务
├── 服务中
├── 等待用户
└── 即将超时
第七章 首页不做大数据驾驶舱
红娘首页不要堆：
- 用户总数
- 平台GMV
- 男女比例大图
- 地区热力图
- 各种排行榜
这些不是红娘每天完成服务所需要的信息。
第八章 红娘工作台核心状态
服务单状态：
submitted
assigned
in_service
waiting_user
completed
cancelled
第九章 submitted
表示：
用户已提交申请，尚未明确由谁负责。
后台显示：
新申请。
第十章 assigned
表示：
已经分配给具体红娘，但服务尚未正式开始。
需要尽快：
首次查看并处理。
第十一章 in_service
表示：
正在为用户提供服务。
包括：
- 理解需求
- 推荐候选
- 调整建议
- 活动推荐
- 后续跟进
第十二章 waiting_user
表示：
当前已经完成红娘侧动作，正在等待用户回应。
例如：
已经推荐3位候选
↓
等待用户查看
不应该继续每天重复打扰用户。
第十三章 completed
表示：
本次服务目标已经完成或阶段性结束。
不代表：
用户一定成功牵手。
第十四章 cancelled
适用于：
- 用户主动取消
- 重复服务单合并
- 用户退出婚恋服务
- 账号状态异常导致无法继续服务
第十五章 用户可以申请的服务类型
沿用已确定范围：
帮我推荐合适的人
帮我看看择偶条件
帮我联系意向对象
想参加线下活动
匹配很久无结果
不知道怎么开始聊天
其他
内部编码建议：
recommend_partner
review_preference
contact_intention
join_activity
no_match_help
chat_help
other
第十六章 一个服务单只解决一个主要目标
不要让一个服务单同时写：
推荐对象+活动+聊天+资料修改+投诉。
如果出现多个明显不同任务：
红娘可以拆分服务记录或创建关联任务。
但V1不必做复杂工单系统。
第十七章 用户申请后的第一步
红娘打开服务详情后，首先看：
用户基本资料
择偶条件
当前婚恋状态
服务申请内容
推荐历史摘要
红娘历史服务摘要
不是先打电话。
第十八章 红娘服务详情三栏布局
PC推荐：
左栏：用户信息
中栏：服务记录/历史
右栏：当前操作
第十九章 左栏：用户摘要
展示：
头像
展示名
年龄
身高
所在区域
学历
职业类别
婚姻状况
子女情况
已实名
已审核
婚恋状态
第二十章 左栏：择偶条件
优先显示：
必须符合
最好符合
例如：
必须符合
年龄 30～38
丹阳/镇江
可接受离异
最好符合
本科以上
不吸烟
1～2年内有结婚计划
第二十一章 红娘不能看到的内容
默认不展示：
- 身份证
- 完整手机号
- 用户完整实名信息
- 私人聊天正文
- 举报证据
- 风控调查详情
- 精确住址
第二十二章 用户联系方式
红娘若确实需要进行服务沟通：
可通过受控联系方式联系用户。
工作台默认建议：
点击“联系用户”。
由系统显示必要联系方式或提供内部拨号信息。
查看完整手机号应根据角色权限控制。
第二十三章 第一次服务判断
红娘打开服务单后，首先判断：
需求是否明确？
资料是否足够？
择偶条件是否合理可执行？
是否已经存在合适候选？
是否有安全/账号异常？
第二十四章 服务前异常检查
若发现：
账号封禁
资料重新审核
明显风险状态
服务已退出
不得继续普通婚恋推荐。
应：
暂停服务并根据状态转相应处理。
第二十五章 首次联系是否必须
不是所有服务单都必须电话沟通。
例如：
“帮我推荐合适的人”
如果用户资料和条件已经非常清楚：
红娘可以直接进入候选筛选。
第二十六章 必须进一步确认的情况
例如：
- 服务描述太模糊
- 条件互相矛盾
- “必须符合”过多导致0候选
- 用户提出特殊需求
- 用户明确要求红娘联系
- 近期婚恋状态发生变化
这种情况下需要进一步沟通。
第二十七章 首次沟通目标
第一次沟通不是“聊得越久越好”。
只需要搞清：
用户当前最想解决什么
哪些条件是真正不能接受
哪些条件只是理想偏好
近期是否愿意见面
是否愿意参加活动
是否愿意接受红娘推荐
第二十八章 首次沟通不要重新问完整资料
平台已有的信息：
不要再问一遍。
例如系统已有：
32岁
本科
丹阳
未婚
红娘不要重新：
“请问你今年多大？”
降低用户负担。
第二十九章 红娘沟通记录
每次正式沟通后，创建：
MatchmakerFollowup
至少记录：
时间
沟通渠道
内容摘要
结果
下一步
下次跟进时间
第三十章 跟进渠道
建议：
平台内
电话
线下面谈
活动现场
其他
如果未来使用微信工作号：
可以增加。
第三十一章 跟进记录原则
只记录：
服务必要摘要。
不要把用户所有私人谈话逐字记录。
错误：
用户和前任交往了3年，某年某月发生……
正确：
用户更重视稳定沟通，希望对方近期有明确婚姻计划。
第三十二章 跟进内容结构
建议：
沟通内容
处理结果
用户意向
下一步行动
第三十三章 下一次跟进
每条跟进可以设置：
next_followup_at
红娘首页自动进入：
今日待跟进。
第三十四章 不要依赖红娘自己记日历
工作台必须帮助红娘记：
谁需要联系
什么时候联系
为什么联系
上次聊了什么
这是系统价值之一。
第三十五章 候选生成
红娘点击：
查看合适候选
调用：
Match Engine。
不是直接查询全部用户。
第三十六章 候选必须先通过
Eligibility
+
A Required → B
+
B Required → A
也就是说：
系统先做硬筛。
第三十七章 红娘候选列表
每张卡建议：
头像
展示名
年龄
区域
学历
职业
婚姻状态
综合：很合适
必须条件
✓ 全部符合
推荐理由
✓ 年龄符合双方要求
✓ 都愿意长期在丹阳生活
✓ 婚姻计划接近
第三十八章 红娘可展开“匹配详情”
展开可看到：
年龄 双方符合
地区 双方符合
婚姻状态 双方符合
子女 双方符合
学历 A偏好未满足
身高 符合
婚姻计划 较一致
生活方式 部分一致
第三十九章 不显示复杂公式
不要给红娘看：
ScoreAB 87.34
ScoreBA 81.72
MutualScore 83.946
可以后台技术调试时保留。
红娘界面用：
很合适
比较合适
值得了解
第四十章 红娘人工筛选价值
红娘主要判断：
- 候选是否和用户当前服务需求吻合
- 用户刚刚补充的偏好是否值得考虑
- 是否近期适合线下见面
- 是否已经推荐过类似对象
- 是否适合本次服务阶段
第四十一章 红娘不能重新创造一套匹配规则
不能出现：
系统认为不符合，但红娘觉得“男方条件好”，强行推荐。
尤其不能突破：
用户Required。
第四十二章 候选不适合的人工标记
红娘可以选择：
本次不推荐
并可记录内部原因：
本次服务方向不符
近期已推荐相似用户
用户明确补充不考虑该情况
其他
第四十三章 人工不推荐不等于永久Pass
红娘本次不推荐：
不自动替用户写入passed。
因为用户本人还没有表达拒绝。
第四十四章 候选推荐数量
一次人工推荐建议：
1～3位。
不要：
一次推20人。
公益红娘的价值是：
帮用户做一定人工筛选。
第四十五章 推荐理由要求
红娘发送推荐前填写/确认理由。
建议系统先自动生成：
年龄、地区和婚姻计划比较符合，
双方都希望长期在丹阳生活。
红娘可以编辑。
第四十六章 推荐理由不能虚构
不能写：
对方人特别好。
如果红娘根本没接触过对方。
只能基于：
- 已有资料
- 已有明确服务事实
- 合法授权范围内的信息
第四十七章 发送推荐
流程：
红娘选择候选
↓
确认推荐理由
↓
系统再次检查候选有效性
↓
创建MatchmakerRecommendation
↓
发送系统通知
↓
用户端“红娘推荐”
第四十八章 推荐发送前必须二次校验
因为候选可能刚刚：
- 暂停寻找
- 被封禁
- 修改条件
- 拉黑用户
- 成功牵手
服务端重新验证。
第四十九章 用户收到红娘推荐
用户看到：
公益红娘为你推荐了一位朋友
王女士 · 32岁
丹阳
本科
教师
推荐理由：
年龄、地区和婚姻计划比较符合。
[查看资料]
第五十章 用户自主操作
进入资料后：
喜欢
不合适
仍然由用户本人点击。
第五十一章 红娘不能知道用户浏览的每一个细节
红娘需要看到的反馈：
未查看
已查看
已喜欢
不考虑
已互相喜欢
足够服务。
不需要：
用户在页面停留17秒。
第五十二章 推荐状态
建议：
pending_view
viewed
liked
passed
mutual_match
expired
第五十三章 推荐有效期
候选关系可能变化。
因此推荐可设置：
业务有效状态实时判断。
不一定必须用固定“7天过期”。
如果目标已经不可推荐：
状态自动：
expired
第五十四章 推荐后跟进
不要刚推荐5分钟就电话问：
“你觉得怎么样？”
建议给用户合理时间。
跟进时间：
可由红娘设定。
例如：
1～3天后
但不写死。
第五十五章 用户已喜欢候选
如果用户已经点击喜欢：
红娘可以看到：
用户已表达喜欢。
如果对方还没回应：
红娘默认：
不介入。
第五十六章 不替用户催对方
A喜欢B。
红娘不要立刻：
打电话催B赶快选A。
除非A明确申请：
帮我联系意向对象
并且走专门流程。
第五十七章 联系意向对象服务
服务类型：
contact_intention
流程：
A提出希望红娘协助
↓
确认A明确授权
↓
检查B状态
↓
向B发送中性邀请
↓
B自主决定
第五十八章 重要：联系意向对象的同意机制
当前产品中：
“红娘在什么前置同意条件下可以主动联系另一位用户”
仍属于需要最终确认的业务细节。
V1实现建议采用更保守方案：
A明确发起本次协助请求后，红娘只能通过平台系统向B发送一次中性意向通知，不能直接提供联系方式，也不默认电话联系B。
如后续确定允许电话联系，应另行补充：
- 用户事先授权范围
- 联系频率
- 隐私政策说明
- 拒绝后停止联系规则
第五十九章 B收到的通知
建议：
有一位平台用户希望进一步了解你，公益红娘受其委托向你发出邀请。是否愿意查看对方资料？
按钮：
查看资料
暂不考虑
第六十章 不告诉B过多信息
在B同意查看之前：
不发送A完整婚恋资料。
第六十一章 B拒绝
如果B选择：
暂不考虑。
则：
- A收到中性结果
- 红娘结束本次联系
- 不再重复骚扰B
第六十二章 给A的拒绝反馈
建议：
对方目前暂未选择进一步了解，公益红娘可以继续为你推荐其他合适的人。
不要：
对方嫌你年龄大。
即使红娘知道原因，也不应直接传播伤害性评价。
第六十三章 红娘协助择偶条件
服务类型：
review_preference
适用于：
- 长时间无候选
- Required过多
- 用户不知道怎么设置
- 条件之间矛盾
第六十四章 工作台条件分析
系统可显示：
当前必须条件：5项
系统候选池：
基础符合 186人
应用你的必须条件后 3人
最终双方符合 0人
第六十五章 红娘解释
正确：
当前符合你所有“必须符合”条件的人比较少，可以看看哪些条件更适合改成“最好符合”。
避免：
你的要求太高。
第六十六章 系统条件建议
例如：
学历
当前：必须本科以上
如果改为“最好符合”
预计候选范围会扩大。
不要承诺具体人数，除非系统实时准确计算。
第六十七章 谁修改条件
首选：
用户本人在小程序修改。
红娘发送：
查看我的择偶条件
入口。
第六十八章 红娘代修改
V1原则：
不提供常规代修改。
如果未来为特殊群体提供线下协助录入：
必须：
- 用户明确确认
- 操作记录
- 变更内容可回看
第六十九章 匹配很久无结果
服务类型：
no_match_help
系统应先给红娘诊断摘要。
第七十章 无结果诊断
可能包括：
候选池过小
必须条件过多
地区限制严格
用户较少主动表达喜欢
资料吸引信息较少
近期活跃度较低
推荐已较充分
第七十一章 禁止负面用户标签
不要后台生成：
条件差
低价值用户
没人喜欢
难匹配用户
建议使用中性状态：
候选范围较小
长期未形成双向匹配
需要人工协助
第七十二章 无结果处理顺序
检查资料完整性
↓
检查条件范围
↓
重新生成候选
↓
人工推荐
↓
推荐适合活动
↓
持续跟进
第七十三章 活动服务
用户选择：
想参加线下活动。
红娘工作台显示：
当前符合基本条件的活动。
第七十四章 红娘可以推荐活动
例如：
丹阳青年公益相亲会
9月20日
25～40岁
报名中
按钮：
推荐给用户
第七十五章 红娘不能替用户报名
活动报名最终：
用户本人确认并提交。
避免：
- 时间冲突
- 条款未读
- 活动规则未确认
第七十六章 特殊线下协助报名
如果未来存在工作人员线下帮助不会操作小程序的人群：
需要独立：
代办授权机制。
V1正常线上流程不做。
第七十七章 聊天帮助服务
服务类型：
chat_help
红娘可以提供：
- 开场建议
- 聊什么话题
- 如何礼貌表达
- 线下见面前注意事项
第七十八章 红娘不能查看聊天内容
即使用户申请：
不知道怎么聊天。
红娘默认仍然：
不读取Conversation。
用户可以主动描述情况。
第七十九章 用户主动提供聊天内容
如果用户自己说：
“对方刚才这样回复，我不知道怎么回。”
红娘可以针对用户主动提供的信息给建议。
但不要因此获取整个聊天权限。
第八十章 红娘不能代聊
禁止：
- 帮用户登录账号
- 代发消息
- 冒充用户
- 自动回复
第八十一章 红娘服务中的风险发现
如果红娘在服务过程中发现：
- 疑似诈骗
- 虚假婚姻状态
- 骚扰
- 广告营销
- 身份异常
不能自行决定封禁。
第八十二章 风险转交
操作：
标记风险
↓
填写简要原因
↓
转风控
系统创建：
RiskEvent / Report-like internal case
第八十三章 红娘看到风险状态
只需要看到：
正常
暂不可推荐
服务暂停
不一定能看到完整风控调查内容。
第八十四章 风控优先
若用户服务中被Risk暂停：
MatchmakerService：
自动进入暂停/不可继续处理状态。
红娘收到：
当前用户服务暂时不可继续，请等待平台处理。
第八十五章 红娘不能主动调查诈骗
红娘不是风控人员。
不要让红娘：
- 调聊天
- 查身份证
- 查举报证据
发现问题后：
转交。
第八十六章 红娘“我的用户”
显示：
服务中
等待用户
已完成
第八十七章 我的用户卡片
建议：
张先生 36岁
丹阳
服务类型：推荐合适对象
状态：服务中
上次跟进：昨天
下次跟进：明天
第八十八章 今日待跟进
系统按照：
next_followup_at <= today
AND
service.status可处理
进入列表。
第八十九章 超时提醒
例如：
距离上次有效跟进已超过配置时间。
显示：
待跟进
已超时2天
只是工作提醒。
不是用户风险标签。
第九十章 首次响应指标
平台可以内部统计：
服务申请 → 第一次有效处理
的时间。
目标是提高服务及时性。
第九十一章 不以通话次数作为红娘核心绩效
错误指标：
每天必须打30个电话
正确更关注：
有效服务
推荐反馈
按期跟进
用户问题解决
进一步了解结果
第九十二章 红娘服务完成条件
至少满足一种：
已完成本轮人工推荐
用户已进入进一步了解
用户主动暂停/取消
用户已参加适合活动
用户成功牵手
当前阶段无更多合适候选且已反馈
服务目标已解决
第九十三章 完成服务不等于关闭用户
用户以后：
可以再次申请红娘帮助。
Service是一次服务记录。
不是永久绑定一个红娘。
第九十四章 完成服务必须填写结果
例如：
已推荐3位用户，用户已查看
协助调整择偶条件，用户已确认修改
用户已与一位对象进入进一步了解阶段
第九十五章 服务完成结果编码
建议：
recommendation_completed
preference_adjusted
activity_recommended
mutual_match_formed
getting_to_know
successful
no_candidate
user_paused
user_cancelled
other
第九十六章 用户成功牵手
如果平台已经完成双方确认：
relationship_status = matched_successfully
相关普通红娘服务：
可以标记完成。
第九十七章 红娘不能自己点击“成功牵手”
成功必须来自：
用户双方确认。
红娘最多：
提醒用户可以在系统中确认状态。
第九十八章 红娘后续回访
对于进入：
getting_to_know
的用户，
可以在用户允许和服务范围内安排轻量回访。
第九十九章 回访目的
不是：
打听隐私。
而是：
是否需要继续推荐
是否继续暂停推荐
是否需要红娘帮助
当前服务是否可以结束
第一百章 不问过度私人内容
例如：
“你们亲密到什么程度了？”
完全没有业务必要。
第一百零一章 红娘推荐记录永久可追溯
至少知道：
谁
什么时候
给哪个用户
推荐了谁
为什么
用户结果
第一百零二章 同一候选重复推荐
系统必须提醒：
该用户已于8月10日推荐过
结果：不考虑
原则上不重复推。
第一百零三章 不同红娘之间防重复
Recommendation是平台级记录。
不是：
每个红娘自己记。
因此另一个红娘接手后也能看到：
已推荐历史。
第一百零四章 红娘服务转交
管理员可以：
将服务从红娘A转给红娘B。
转交必须保留：
- 原服务记录
- 历史跟进
- 原推荐
第一百零五章 转交原因
例如：
工作调整
人员休假
机构调整
用户需求更适合其他红娘
其他
第一百零六章 转交后旧红娘权限
如果服务不再属于其授权范围：
不再继续编辑。
是否仍可查看历史根据机构权限决定。
建议：
最小权限。
第一百零七章 红娘离职
必须：
停用Operator
↓
查找其所有active服务
↓
管理员重新分配
不能出现用户服务丢失。
第一百零八章 机构分配策略
V1可支持：
管理员手工分配
红娘主动领取
二选一或同时支持。
第一百零九章 V1更推荐
对早期丹阳本地运营：
管理员分配 + 红娘可领取待分配服务
均可。
不需要复杂自动派单算法。
第一百一十章 自动分配暂不建设
不需要：
- 负载算法
- AI分单
- 技能路由系统
人员规模小的时候：
手工更清晰。
第一百一十一章 红娘工作台用户搜索
红娘不能拥有：
全平台随意搜索全部用户资料
的无限权限。
候选搜索应通过：
当前服务上下文。
第一百一十二章 临时查用户
若业务确实需要：
只能查询：
公共/必要婚恋资料。
不允许通过手机号任意查完整隐私档案。
第一百一十三章 红娘不能建立私人“用户数据库”
平台应要求：
不把用户婚恋资料下载到个人Excel/微信/笔记软件长期保存。
所有服务记录尽量回平台。
第一百一十四章 红娘工作台导出
V1原则：
不提供婚恋用户批量导出。
活动执行如需要：
使用活动专用脱敏名单。
第一百一十五章 用户资料展示水印
对于红娘工作台敏感程度较高页面，可考虑轻量动态水印：
张老师 2026-08-28
P1实现即可。
第一百一十六章 红娘数据权限矩阵
| 数据 | 红娘权限 |
|---|---|
| 公共婚恋资料 | 服务必要可见 |
| 择偶条件 | 可见 |
| 推荐历史 | 可见 |
| 红娘服务历史 | 授权范围内可见 |
| 完整手机号 | 按权限/服务必要 |
| 身份证 | 不可见 |
| 私人聊天 | 不可见 |
| 举报证据 | 不可见 |
| 风控详情 | 默认不可见 |
| 活动历史 | 必要摘要 |
| 活动单向意向 | 默认不可见 |
第一百一十七章 “等待用户”使用规则
红娘已经完成动作，例如：
推荐3人。
状态可以：
in_service → waiting_user
第一百一十八章 用户回应后
系统自动或红娘操作：
waiting_user → in_service
继续处理。
第一百一十九章 自动状态更新
例如用户对红娘推荐：
已喜欢。
系统可以自动提醒红娘：
用户已对推荐对象表达喜欢。
但不一定自动切服务状态。
第一百二十章 红娘消息提醒
工作台提醒：
新服务申请
用户已回复
推荐对象已失效
今日待跟进
管理员转交服务
第一百二十一章 不要实时弹窗轰炸
工作台采用：
- 数字Badge
- 待办列表
- 页面通知
即可。
第一百二十二章 红娘与用户是否需要单独聊天
V1建议：
不建设“红娘即时聊天系统”作为独立复杂模块。
服务进度可以通过：
- 系统通知
- 服务备注
- 必要电话
- 运营实际沟通方式
完成。
第一百二十三章 如果需要平台内联系红娘
后续可以增加：
服务留言。
但V1不是核心。
避免又建设一套客服聊天系统。
第一百二十四章 红娘服务进度用户端
用户看到：
已提交申请
↓
公益红娘已接手
↓
正在为你筛选
↓
已有推荐
↓
服务跟进中
↓
本次服务完成
第一百二十五章 不暴露内部操作细节
用户不需要看到：
SQL候选46人
红娘淘汰32人
算法分数81
只显示有意义的服务进度。
第一百二十六章 服务用户体验
红娘服务不能让用户感觉：
“申请后进入黑洞。”
因此至少需要：
申请成功
已接手
有结果时通知
第一百二十七章 服务暂无候选
正确反馈：
当前暂时没有找到完全符合双方条件的对象，我们会继续关注合适的推荐机会。
可以建议：
查看择偶条件 / 参加活动。
第一百二十八章 不能为了“交差”乱推荐
红娘工作台不能以：
必须完成推荐数量
作为硬任务。
如果没有合适候选：
可以如实结束本轮服务。
第一百二十九章 公益属性服务原则
公益红娘不做：
充值
VIP销售
高价套餐转化
付费见面
资源优先级售卖
服务排序应基于：
- 申请时间
- 紧急程度
- 服务状态
- 实际资源
而不是付费等级。
第一百三十章 特殊人群服务
如果未来对：
- 残障人士
- 大龄单身
- 困难家庭等
开展专项公益婚恋活动，
可以建立：
特定服务项目。
但不能在V1普通用户模型中随意增加敏感标签。
需要专项设计。
第一百三十一章 红娘不得给用户做“价值分级”
后台禁止：
A级男
B级女
优质资源
低端用户
高价值男嘉宾
可以有：
匹配条件摘要
服务优先级
风险状态
服务管理标签不等于人的价值等级。
第一百三十二章 用户照片与红娘判断
红娘可以查看：
用户已经审核通过的公开照片。
不能：
下载后私下转发给其他用户。
推荐对象查看资料应通过平台。
第一百三十三章 红娘发候选给用户
系统只发送：
平台用户详情入口。
不要：
把截图发到微信群。
这样能持续执行权限和隐私控制。
第一百三十四章 线下红娘服务
如果公益组织线下接待用户：
红娘可通过工作台：
搜索服务编号/本人授权信息。
完成服务记录后：
回写平台。
第一百三十五章 纸质材料原则
尽可能少使用。
如果线下确需纸质：
- 最小化字段
- 不打印身份证
- 使用结束后安全销毁
- 不长期堆放个人婚恋档案
第一百三十六章 服务质量检查
运营管理员可以随机检查：
是否长期未处理
是否存在无记录推荐
是否越权查看
是否有不适当服务用语
是否反复骚扰用户
第一百三十七章 红娘不能高频打扰
用户已经：
waiting_user
且没有回应。
红娘应遵循合理频率。
不要：
一天打3次电话。
第一百三十八章 用户拒绝红娘继续联系
如果用户明确：
暂时不需要红娘服务。
应：
service → completed/cancelled
并停止后续主动服务。
第一百三十九章 用户暂停寻找
所有普通红娘服务：
暂停主动推荐。
如果用户已经有进行中的咨询：
可以完成必要收尾。
第一百四十章 用户退出婚恋服务
服务：
自动终止。
红娘收到系统状态更新。
第一百四十一章 用户成功牵手
系统：
- 停止新红娘推荐
- 当前推荐类服务自动提示完成
- 不再产生候选任务
第一百四十二章 红娘成功案例收集
如果服务最终成功：
可以询问：
是否愿意分享公益服务体验。
默认：
不分享。
第一百四十三章 不能默认拿成功案例宣传
用户明确授权后才可以。
这是独立宣传授权，不属于普通红娘服务。
第一百四十四章 红娘绩效指标建议
公益服务内部可看：
当前服务用户数
首次响应及时率
按时跟进率
人工推荐数
推荐查看率
推荐Like率
形成Mutual Match数
进入进一步了解数
服务完成率
第一百四十五章 不建议作为绩效核心
打电话数量
推荐人数越多越好
成功牵手排行榜
用户资产质量
第一百四十六章 红娘服务Dashboard
建议：
今日
新申请 5
待首次处理 3
待跟进 8
等待用户 12
服务中 26
即将超时 4
足够。
第一百四十七章 Service Priority
可以简单分：
normal
attention
urgent
但urgent只用于：
工作时效。
不是给用户贴婚恋等级。
第一百四十八章 urgent适用
例如：
- 活动马上开始需要确认
- 用户提交安全相关信息，需要转风控
普通“想快点找对象”：
不建议定义urgent。
第一百四十九章 红娘服务SOP总表
Step 1 接单
检查：
用户状态
服务类型
服务内容
Step 2 理解需求
检查：
资料
择偶条件
匹配历史
必要补充信息
Step 3 候选生成
系统：
Eligibility
Required
MutualScore
Step 4 人工筛选
红娘：
选择1～3位
确认理由
Step 5 用户决定
用户：
查看
喜欢
不合适
Step 6 跟进
根据结果：
继续推荐
条件建议
活动推荐
等待
Step 7 结束
记录：
服务结果
第一百五十章 “推荐对象”SOP
查看用户条件
↓
生成候选
↓
筛选1～3位
↓
发送推荐
↓
等待用户反馈
↓
需要则继续下一轮
↓
完成
第一百五十一章 “调整条件”SOP
查看当前Required/Preferred
↓
查看候选池
↓
识别过窄维度
↓
给出中性建议
↓
用户本人修改
↓
重新计算候选
↓
完成
第一百五十二章 “联系意向对象”SOP
V1保守流程：
A明确申请
↓
检查B状态
↓
平台向B发送一次中性邀请
↓
B自主选择
├→ 愿意查看
│ ↓
│ 正常关系流程
└→ 暂不考虑
↓
服务反馈A
第一百五十三章 “参加活动”SOP
查看适合活动
↓
推荐用户
↓
用户自己查看活动
↓
用户本人报名
↓
活动模块处理
↓
必要时后续跟进
第一百五十四章 “长期无结果”SOP
查看系统诊断
↓
资料是否完整
↓
Required是否过窄
↓
用户活跃与回应情况
↓
人工候选
↓
活动推荐
↓
必要调整条件
↓
持续服务/完成
第一百五十五章 “聊天帮助”SOP
用户说明困惑
↓
红娘根据公开资料与用户描述
↓
提供沟通建议
↓
用户自己发送
↓
不查看私聊
↓
不代发
第一百五十六章 安全转交SOP
红娘发现异常
↓
停止自行调查
↓
创建风险标记/转交
↓
Risk团队处理
↓
MatchmakerService根据结果继续/暂停/结束
第一百五十七章 工作台必须防止的七种错误
- 红娘把候选电话直接发给用户
- 红娘替用户点喜欢
- 红娘无服务关系随意浏览用户
- 红娘看私人聊天
- 红娘私下Excel保存用户档案
- 红娘绕过Required推荐
- 红娘为了完成任务强行推荐不合适用户
第一百五十八章 红娘服务接口建议补充
在此前API基础上：
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
第一百五十九章 工作台接口权限
建议：
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。
不要直接复用：
AdminUserDTO
第一百六十一章 MatchmakerUserDTO
建议：
userId
displayName
avatar
age
height
region
education
occupation
maritalStatus
childrenStatus
interests
relationshipStatus
preferenceSummary
matchSummary
activitySummary
serviceHistorySummary
不含：
idNumber
privateChat
riskEvidence
第一百六十二章 工作台高保真关键页面
优先：
R01 登录
R02 工作台
R03 服务申请列表
R04 服务详情
R05 候选推荐
R06 推荐确认
R07 跟进记录
R08 我的用户
沿用此前高保真页面规划。
第一百六十三章 R02工作台
建议：
左侧导航
今日待处理
[新申请 5]
[待首次处理 3]
[今日跟进 8]
[等待反馈 12]
下方：
待处理列表
点击卡片进入对应筛选列表。
第一百六十四章 R04服务详情
三栏：
┌─────────┬──────────────────┬────────────┐
│ 用户资料 │ 服务历史/跟进 │ 当前操作 │
│ │ │ │
│ 择偶条件 │ Timeline │ 看候选 │
│ │ │ 添加跟进 │
│ 状态 │ Recommendation │ 推荐活动 │
│ │ │ 完成服务 │
└─────────┴──────────────────┴────────────┘
第一百六十五章 Timeline
时间轴包括：
用户提交申请
红娘接手
首次沟通
推荐候选
用户查看
用户喜欢
跟进
活动推荐
服务完成
第一百六十六章 R05候选推荐
过滤：
系统推荐等级
年龄
地区
但不要让红娘自己做复杂数据库筛选。
候选已由系统先筛。
第一百六十七章 候选详情
可以打开右侧Drawer：
快速查看。
但正式用户完整详情：
使用统一Profile组件。
第一百六十八章 R06推荐确认
发送前显示：
推荐给：
张先生
推荐对象：
王女士
系统理由：
年龄、地区、婚姻计划较符合
红娘推荐说明：
[可编辑]
按钮：
确认推荐
第一百六十九章 推荐成功反馈
推荐已发送
等待用户查看后，可以在服务详情中继续跟进。
第一百七十章 R07跟进记录
字段：
沟通方式
沟通摘要
处理结果
下一步
下次跟进时间
第一百七十一章 跟进模板
可提供快捷结果：
用户愿意继续了解
用户暂不考虑
等待用户查看推荐
建议调整条件
推荐参加活动
暂时暂停寻找
减少输入。
第一百七十二章 不能全部模板化
允许红娘补充：
简短文字备注。
因为人工服务存在复杂情况。
第一百七十三章 服务质量自动提醒
系统可以检查：
服务已分配但24小时无处理
服务中超过配置时间无跟进
推荐后长时间无状态
具体时长：
配置化，待运营确认。
不要在代码写死。
第一百七十四章 用户满意度
V1可以在服务结束后：
轻量评价。
例如：
这次公益红娘服务是否对你有帮助？
很有帮助
有帮助
一般
没有帮助
不是必须。
第一百七十五章 不做红娘公开评分
用户评价：
用于内部改进。
不前台显示：
张红娘 4.9分
避免商业婚介化。
第一百七十六章 用户投诉红娘
帮助/反馈中可以：
对公益红娘服务提出反馈。
如涉及：
- 隐私泄露
- 骚扰
- 不当言语
应转：
管理员/风险处理。
第一百七十七章 红娘敏感访问日志
如果红娘权限允许查看某些非公开联系方式：
每次访问建议记录：
operatorId
userId
dataType
serviceId
time
第一百七十八章 无服务关系访问
红娘尝试查看：
与自己没有服务关联的敏感用户数据。
必须：
拒绝。
第一百七十九章 机构范围
红娘默认只能处理：
被分配给自己/本机构授权范围的服务。
跨机构需要：
明确授权。
第一百八十章 平台级公益红娘池
未来若多个组织共同运营：
可以有：
平台红娘池
机构红娘池
V1数据模型可以支持organizationId。
但无需建设复杂资源调度。
第一百八十一章 机构协同原则
机构之间：
不默认共享全部用户数据。
可以共享：
服务任务
前提：
- 业务授权
- 权限明确
- 数据最小化
第一百八十二章 红娘与审核员职责分离
审核员：
判断资料是否符合平台展示要求。
红娘：
帮助寻找合适对象。
红娘不能自行：
把审核未通过用户改为通过。
第一百八十三章 红娘与活动管理员职责分离
红娘可以：
推荐活动。
不能自动：
审核活动报名。
除非同时被授予活动管理员角色。
第一百八十四章 红娘与风控职责分离
红娘发现问题：
转交。
没有风控权限就不能：
封禁。
第一百八十五章 服务异常场景一
红娘准备推荐B。
B刚暂停寻找。
服务端：
TARGET_UNAVAILABLE
工作台：
候选当前不可推荐。
第一百八十六章 服务异常场景二
用户服务中突然成功牵手。
工作台：
用户已成功牵手，暂停普通推荐。
推荐类服务提示：
可完成服务。
第一百八十七章 服务异常场景三
用户删除红娘推荐对象的Like。
若尚未Match：
Recommendation状态同步。
红娘只需看到：
用户当前未选择进一步了解。
第一百八十八章 服务异常场景四
两名红娘同时接单。
数据库原子更新。
一人成功。
另一人：
服务已由其他红娘接手。
第一百八十九章 服务异常场景五
红娘推荐后目标被封禁。
Recommendation：
expired
用户侧不再显示正常候选资料。
红娘收到：
推荐对象当前不可继续推荐。
第一百九十章 服务异常场景六
用户已经暂停寻找，但还有待跟进任务。
工作台提示：
用户已暂停寻找。
红娘不继续推新人。
可以做必要收尾。
第一百九十一章 服务异常场景七
用户明确不想接电话。
如果未来有沟通偏好设置：
必须遵守。
V1至少应允许跟进记录中注明：
不接受电话联系。
第一百九十二章 服务异常场景八
用户要求：
“把对方手机号直接给我。”
红娘不能执行。
正确：
通过平台邀请对方自主决定是否进一步联系。
第一百九十三章 红娘工作台P0功能
登录
工作台
服务列表
服务详情
服务领取/分配
用户必要资料
择偶条件
候选列表
人工推荐
跟进记录
我的用户
服务完成
第一百九十四章 P1功能
活动推荐
联系意向对象流程
风险转交
超时提醒
用户服务评价
服务转交
第一百九十五章 P2功能
工作量统计
质量统计
动态水印
更多服务分析
机构间协同增强
第一百九十六章 红娘服务验收标准
测试时必须确认：
- 红娘没有服务关系不能访问敏感用户数据
- 红娘不能查看身份证
- 红娘不能查看私人聊天
- Required冲突候选不能推荐
- 红娘不能替用户Like
- 推荐前目标状态会重新检查
- 不同红娘不会重复乱推同一候选
- 用户暂停后停止新推荐
- 风控限制能立即暂停服务
- 服务完成保留全部历史记录
第一百九十七章 SOP验收标准
随机给新红娘一张服务单。
不看说明书也应能知道：
现在为什么找我
↓
用户当前是什么情况
↓
我下一步做什么
↓
系统推荐谁
↓
我推荐后发生什么
↓
什么时候回来跟进
↓
什么时候可以结束
如果做不到：
工作台设计仍然不够清晰。
第一百九十八章 红娘核心工作流最终图
用户申请
│
↓
MatchmakerService
│
↓
分配红娘
│
↓
┌── 理解服务需求 ──┐
│ │
↓ ↓
条件已清晰 需要补充沟通
│ │
└────────┬─────────┘
↓
Match Engine
↓
候选池
↓
红娘人工筛选
↓
推荐1～3位
↓
用户决定
┌─────┴─────┐
↓ ↓
Like Pass
│ │
↓ ↓
Match? 下一候选
│
┌──────┴──────┐
↓ ↓
否 Mutual
│ │
等待 ↓
Conversation
↓
Getting to Know
↓
Successful / 继续服务
第一百九十九章 公益红娘最终服务原则
必须坚持：
红娘帮助用户做选择，但不替用户做选择。
系统帮红娘找人，但不把红娘变成机械审核员。
用户的Required是底线，不是红娘可以协商掉的系统规则。
联系方式属于用户本人，不属于红娘可以自由分配的资源。
私人聊天属于用户隐私，不属于红娘的常规服务资料。
没有合适对象时可以如实告诉用户，不需要为了完成任务乱推荐。
每一次推荐、跟进和服务结束都要留下必要记录。
红娘发现风险要及时转交，但不自行做风控调查。
公益服务的评价标准是用户有没有得到真正帮助，而不是推荐了多少人、打了多少电话。
第二百章 最终设计结论
公益红娘工作台的真正价值，不是给工作人员增加一个后台系统。
而是把过去可能存在的：
微信群
Excel
纸质表格
个人微信
个人记忆
电话记录
逐步变成：
统一服务单
+
统一用户状态
+
系统候选
+
人工判断
+
统一推荐记录
+
统一跟进提醒
+
统一权限控制
+
统一服务结果
最终形成：
算法做初筛，红娘做服务，平台守边界，用户做决定。
这套机制既能提高公益组织服务效率，也能避免红娘服务过度依赖某个工作人员个人经验，从而让平台真正做到：
人员可以更换，服务不会丢；红娘可以辅助，用户仍然自主；公益服务有温度，同时又有标准。