# 丹阳公益婚恋服务平台 # 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 统一服务单 + 统一用户状态 + 系统候选 + 人工判断 + 统一推荐记录 + 统一跟进提醒 + 统一权限控制 + 统一服务结果 ``` 最终形成： > **算法做初筛，红娘做服务，平台守边界，用户做决定。** 这套机制既能提高公益组织服务效率，也能避免红娘服务过度依赖某个工作人员个人经验，从而让平台真正做到： > **人员可以更换，服务不会丢；红娘可以辅助，用户仍然自主；公益服务有温度，同时又有标准。**