用户分层
优先试点这一场景的目标是把标签、互动、购买、渠道和生命周期整理成用户分层、特征和触达建议。
- 输入
- 标签、互动、购买、渠道和生命周期
- 输出
- 用户分层、特征和触达建议
- 验收
- 检查交接耗时、用户标签准确率、过度触达投诉率
- 边界
- 标签不得涉及敏感歧视信息

私域与社群运营需要兼顾用户上下文和触达克制,频率、隐私与平台规则优先。
左起第一列是这个岗位可交给 WorkBuddy 的场景; 中间两列是它需要什么、能交付什么;最后一列是必须由人或系统决定的部分 —— 这一列才是评审时真正要看的,因为它决定哪些环节不能自动化。
| 场景 | 需要输入 | WorkBuddy可辅助交付 | 人工或系统边界 |
|---|---|---|---|
| 用户分层 | 标签、互动、购买、渠道和生命周期 | 用户分层、特征和触达建议 | 标签不得涉及敏感歧视信息 |
| 欢迎语与SOP | 来源、用户类型、产品和服务流程 | 欢迎语、首轮问题和后续SOP | 避免诱导、骚扰和夸大承诺 |
| 内容与分层触达 | 用户层级、内容、时间和频率 | 分层内容、发送计划和A/B测试 | 外发前人工审核,允许用户退订 |
| 社群答疑 | 知识库、聊天上下文和升级规则 | 答复、来源和转人工建议 | 群内隐私和无答案时拒答 |
| 线索识别 | 咨询、互动、资料领取和购买信号 | 意向线索和销售跟进建议 | 评分不能替代真实沟通 |
| 活动转化 | 活动目标、用户层级、权益和历史数据 | 活动方案、报名、提醒和复盘 | 价格、权益和抽奖规则需审核 |
| 聊天总结与交接 | 授权聊天记录、客户状态和任务 | 客户摘要、承诺和下一步 | 敏感聊天最小化使用 |
| 流失预警 | 互动、购买、投诉和服务数据 | 流失信号和挽回建议 | 相关性不等于客户真实意愿 |
| 合规与封号风险 | 发送规则、内容、频率和平台政策 | 风险清单、禁用动作和审核点 | 遵守广告、个人信息和平台规则 |
三个优先场景在各岗位下按同一套方法拆解:明确任务口径 → 收集并检查输入 → 让 WorkBuddy 执行整理、检索或生成 → 输出可编辑结果 → 由岗位负责人复核后进入下一流程。
这一场景的目标是把标签、互动、购买、渠道和生命周期整理成用户分层、特征和触达建议。

这一场景的目标是把来源、用户类型、产品和服务流程整理成欢迎语、首轮问题和后续SOP。

这一场景的目标是把用户层级、内容、时间和频率整理成分层内容、发送计划和A/B测试。
同一个岗位的场景会分散在四层里:文件层只用本地文档就能跑, 知识层要先建好有版本、有出处、有权限的资料,系统层要接业务系统, 决策层则必须保留人工批准。先看自己能从哪一层起步。
使用本地文档、表格和模板,结果可人工检查
建立有版本、有出处、有权限的知识资料
通过受控的Connector、MCP或API读写业务系统
展示依据、假设和影响,高风险决定由人批准
推荐先做“聊天总结与交接”。它所需输入是授权聊天记录、客户状态和任务,目标交付是客户摘要、承诺和下一步。
试点可按四个动作推进:第一,抽取一批真实历史任务作为基线;第二,用同一批输入让人工流程和WorkBuddy流程并行;第三,记录失败、遗漏和人工修改原因;第四,只在结果稳定、权限清楚、可以回滚时扩大范围。
建议验收指标包括:交接耗时、用户标签准确率、过度触达投诉率。如果结果需要大量重做、来源无法追溯、系统写入不可回滚,试点应暂停并先修复数据或流程。
把你们这个岗位最耗人的一件事说清楚,我们按上面四层能力给出可切入点、需要对接的系统清单和人工边界 —— 不是通用方案,是照着你们现有流程改的版本。