主要参考对象

  • linkflow(客户旅程）
    • 优点：底层设计灵活（触发条件 动作 条件分支），单次事件型SOP自定义程度高
    • 缺点：没有整合默认模板，学习成本太高；只能做单次动作触发SOP，对客户管理来说，太细碎
  • 鲸奇SCRM（商机阶段+SOP)
    • 优点：商机客户分层运营SOP概念，可以周期性自动化触达；自动化标签功能比较完善；
    • 缺点：商机那块逻辑比较散，且是静态无法深度挖掘（相比有赞的“人群”概念）
  • 有赞（人群运营）
    • 优点：“客户分群”概念，自定义度非常高，对电商而言，用户分层十分清晰；UI和功能逻辑优秀易懂，支持多渠道的消息推送，且可以设置优先级
    • 缺点：人群运营只能发优惠券和公众号、短信等，相当于单动作，没有周期流程SOP概念
  • 飞书（飞书捷径）
    • 优点：事件型SOP，UI和功能逻辑优秀易懂；类似iPhone的“快捷指令APP”，平台类逻辑，可丰富拓展
    • 缺点：对客户管理场景而言，没有客户分层运营的周期性流程（类似鲸奇），太细碎，使用成本高
  • 艾客（ADMP营销)
    • 优点：客户分群的单次事件执行，自定义程度较高，拥有“任务目标”，可以拉群说明链接
    • 缺点：单次动作，只针对微信/企业微信好友的消息推送
  • 尘锋（简化版人群运营）
    • 优点：有简单的客户分群，客户分群里默认自带“评分系统”（功能没有艾克的ADMP强大）
    • 缺点：单次动作，只针对微信/企业微信好友的消息推送
艾客ADMP 鲸奇 尘峰 有赞 linkflow 飞书捷径 微伴
核心亮点功能 动态人群（标签）划分 任务目标功能

消息推送支持事件触发 | 基于时间的多次推送SOP | 动态人群划分 | 客户分群（动态）功能最强
多渠道消息推送且支持优先级
可以发优惠券、权益 | 相当于 事件工作流
扩展性强 | 相当于 事件工作流 扩展性强 | 基于时间的多次推送SOP | | 缺点 | 单次动作 | 静态客户筛选 | 单次动作 | 单次动作 | 繁琐 不适应CRM场景 | 繁琐 不适应CRM场景 | 纯API 只能提醒 没有客户SOP | | 触发 | 客户群 | 客户状态阶段 | 客户群 | 客户群 | 事件触发+循环 | 事件触发+循环 | 时间（纯API) | | 动作-消息推送 | 个微+企微+提醒 推送支持判断触发条件（如买了XX商品） | 个微+系统提醒 | 个微+企微 | 公众号等多渠道，支持渠道优先级 | 单次动作+多渠道 | 飞书消息 | 企微提醒 | | 动作-其他事件 | 拉群 | 无 | 无 | 优惠后、会员权益 | 多种事件 | 平台类，webhook多应用 | 无 | | SOP多次事件序列 | 无 | 多次序列，按时间，第一天8点，第二天9点… | 无 | 无 | 可执行多次时间，由条件触发 | 可执行多次时间，由条件触发 | 多次序列，按时间，第一天8点，第二天9点… | | 条件-客户筛选 | 动态多条件 | 静态客户阶段 | 动态多条件 | 动态多条件，支持种类最多 | 无 | 无 | 无客户，目前是支持群聊 | | 条件分支 | 无 | 无 | 无 | 无 | 支持，根据事件输入值判断条件 | 支持，根据事件输入值判断条件 | 无 | | 其他 | 任务目标：支持设定目标，客户收到推送 xx小时内购买了XX商品 则完成目标 支持多个目标 | 客户状态“商机”支持多个分组 | 客户“评分”概念 | “场景营销”少量特别开发的事件 | 支持SOP的 “终止”事件 可配合条件分支 | 终止事件 平台类 支持触发事件和动作多 | |

所有SOP的触发，本质上都是事件触发，所有的触发、操作、条件等 都是提前封装好的一个【小元件】，然后根据业务进行自定义组合

只是，应用到CRM的场景下，有赞（人群运营）和鲸奇，单独提取出【客服分群】的概念，更适合客户管理和运营这个场景，且有赞提取得更加清晰和方便 而类似捷径的飞书和linkflow提供了更灵活的扩展，方便后续应用的其他行业场景

linkflow

触发条件：流程触发
执行动作：可进行的动作/操作
条件分支：用来进行分支操作（2个分支），提前封装好的一些可支持的参数 :::info 核心是提升效率的类BOT功能 ::: image.png

触发条件

image.png

  1. （用户）加入标签组
    1. 参数：标签组选择
  2. 微信事件（公众号）
    1. 参数1：选择公众号
    2. 参数2：基于公众号的一些操作如 关注、取关、留言、卡券相关
  3. 企业微信事件
    1. 参数：添加/删除/被删除 客户
  4. 定时器触发
    1. 参数1：用户标签组
    2. 参数2：单次触发 （触发开始时间）
    3. 参数3：循环触发 每天/周/月+时间 起始日期
  5. 网页追踪触发
    1. 参数：特定网页、点击短链跳转 （这里用来分析网页的，点击、跳转等，不多做叙述）
  6. 金数据（表单工具）
    1. 参数：提交某表单
  7. 增长工具箱网站
    1. 参数：访问网页、激活应用、点击元素、退出页面等 （业务强关联，不多做叙述）

执行动作

  1. 终止旅程（流程终止符）
  2. 加入标签组
    1. 参数：标签组
  3. 移出标签组
    1. 参数：标签组
  4. 微信（公众号）
    1. 参数1：发消息，各种消息类型 图文、小程序、H5等
    2. 参数2：发卡券、海报等自定义功能 （发消息相关功能，可以带参进去，例如昵称 等）
  5. 企业微信发消息
    1. 参数1：发消息 图文、链接、小程序等（？这里不用hook，应该是API群发的功能，需要员工在手机再点一次)
    2. 参数2：发内部消息（此处应该是企业微信应用 发送消息）
  6. 变更属性
    1. 变更用户属性（如 备注名、年龄等 各种参数），可多选
  7. 改变分数
    1. 配合自定义字段，改变为数字整型的参数，的数值 （例如+20活跃 -20 活跃）
  8. 延时器
    1. 延时 x分/小时/天
    2. 延时到 XX年XX月XX日 时间
  9. A/B 分配
    1. 用来做百分比 AB测试的
  10. webhook
  11. 网页弹窗
  12. 内部通知（通过公众号实现）

条件分支

分支条件是用来做条件分支规则判断的

条件分支一般当有多个条件时，可以选择 且/或 的关系 一般判断文本/数字/日期等 条件 文本是包含/等于等 数字是大小 日期是日期前/后等

image.png

  1. 属性判断器（用户属性）
  2. 群组判断
  3. 事件判断器
    1. 用于判断进入客户旅程的联系人在该旅程触发条件中所涉及的事件的发生情况，并决定其如何继续接下来的旅程。 即要匹配触发的事件，来进行A/B条件选择
  4. 微信（公众号）判断器
    1. 判断微信公众号关注状态 48小时 24小时内有互动 关注中

鲸奇SOP

  • 相对linkflow的全部碎片化的动作，把自动化功能，抽取成 自动打标签、商机流程自动化、商机SOP、渠道新好友问候语和标签 几个部分
  • 商机SOP 对分层客户的 持续的消息推送/触达，在客户管理场景下更直观

自动打标签

image.png
image.png
自动标签：条件（单选）+参数

  1. 聊天关键字
    1. 微信号 关键字（可多个）
  2. 微信聊天总消息数
  3. 单次购买金额
  4. 购买指定商品
  5. 内容追踪（暂无）

商机流程自动化

进入商机条件：聊天中关键字识别 或者 成为客户
自动跟进提醒：停留时间 或者 未主动联系 XX天
image.png
image.png

自动跟进提醒：
image.png
进入条件：
image.png

商机SOP

核心：流程化推送消息

image.png
image.png
image.png
image.png

第一步：筛选客户

  • 新添加的客户
    • 参数：微信号、新好友添加判断的时间范围
  • 客户进入旅程（商机分类）
    • 参数：商机分类、时间范围参数
  • 客户商机类型
    • 参数：商机类型（具体商机）
  • 沉默客户
    • 参数：商机类型（具体商机）、XX天未回消息

第二步：发消息SOP流程

  • 时间：延迟XX天 +时刻 （成为XX商机后 第一天 第二天。。。 此处可以按天统计一次）
  • 循环：每天、每周 （它这里 页面设计 逻辑有问题 每天/每周 功能不明确，是每周执行一次任务，还是？ 或者这里指的是 企业微信群发API 里面的每天消息 和 每周一次的消息）
  • 动作：发消息、发朋友圈、建立提醒

第三步：执行，立即或定时

活码渠道SOP

根据渠道活码 发送问候语+打标签

相当于把问候语功能单独提取出来，这个可以借鉴，因为问候语第一天 属于一个相对特殊和固定的SOP

有赞（人群运营）

  • 有赞人群的概念，相对于通过一些前置的组合条件（可以是属性、动作、行为数据等），把客户先通过“群组”的概念分层出来，然后以分层出的群组用户，直接去做后面的SOP动作，即触发条件就是满足条件的某一类用户，以“人”为触发维度做运营。而事件型SOP一般是不能以属性值条件去做触发的，这里更加灵活方便客户管理场景的运营。
  • 场景营销，类似事件类SOP，以事件去驱动
  • 这样流程更加清晰，客户更容易理解，可以把某个场景（电商）下做到最优体验

image.png
image.png

客户分群

通过一系列自定义条件先把客户分层
image.png

人群运营

以分层后的客户群为维度去做运营
image.png

场景营销（简单事件触发SOP)

类似前面的设计逻辑，以单独事件去驱动的运营操作
image.png

飞书（飞书捷径）

  • 类似iPhone的快捷指令产品逻辑，网页版本。
  • 事件型SOP自定义，核心逻辑是提升效率的BOT，以平台（第三方不断集成丰富）来运作

image.png
image.png

客户分群功能

:::info

  • 客户分群是系统根据多筛选条件（包括信息参数、行为动作两部分）自动动态计算出来的集合属性
  • 【问题】客户分群是每天定时计算一次，更新客户群数据，还是实时响应 :::
  • 新客户（参数：来源渠道 个号/企号 来源方式：扫码渠道/主动添加 来源账号）作为一个特殊的客户群，为了方便客户理解，单独抽取出来，不和客户分群放在一起，虽然底层技术可以用同一套逻辑，（新客户必须实时处理）
  • 商机阶段 和新客户同理，方便理解，单独抽取出来

分群条件参数

条件只支持且的模式

  1. 静态属性筛选
    1. 直接参考有赞
  2. 行为动作筛选
    1. 购买了XX商品
    2. 。。。待拓展

      SCRM Pro-SOP(我们的策略）

  • 核心分为两个部分：客户群运营SOP、事件运营SOP
  • 底层逻辑还是触发条件+执行动作，客户运营SOP是先把客户群（分层）单独抽取出来，更适合客户管理的场景
  • 事件SOP为底层逻辑，可以为后续扩展做支撑
  • 目前SOP主要动作为微信好友状态下的运营（底层逻辑是可扩充的，其他动作）

SOP类型

  • 新客户SOP
  • 客户群SOP
  • 商机阶段SOP（分群的简化，针对偏销售主动跟进的场景）

触发条件

  1. 成为某个客户群的客户（承接 客户群运营SOP)
    1. 参数：选择客户分群
  2. 新客户（底层逻辑是事件触发，因为新客户要实时响应，如果客户分群功能能够实时触发，那么逻辑也一样）
    1. 参数：客户来源渠道、来源微信号、来源方式
  3. 商机阶段触发（偏向 销售主动跟进的 场景）
  4. 独立事件
    1. 根据功能和接入不断完善 独立事件的触发
    2. 聊天中包含XX关键词
    3. 购买XX商品
    4. 关注XX公众号
    5. 使用XX小程序
    6. 填写提交了XX表单
    7. 。。。
  5. 循环定时任务
    1. 参数：每天/每周/每月 +时刻
  6. 属性变更事件（暂不处理，这里和 先设置客户群，然后SOP概念有一定重复）

~~

执行操作

  1. 发消息触达 微信/企业微信/公众号/抖音/短信 消息
    1. 参数：消息类型 和 消息内容
  2. 发送UIM&系统提醒
  3. 打AI电话
  4. 发送自定义表单
  5. 发优惠券
  6. 发会员权益
  7. 拉群
  8. 筛选器（相当于定义一个变量X，满足条件时，继续）
  9. 延时器
    1. 延迟XXX天/周/分/小时 延时到日期时刻
  10. 修改属性参数
    1. 参数：属性 和 值
  11. 其他拓展。。。

条件分支

条件分支 是关联月 触发/操作 事件的，提取出参数，然后进行参数进行if else 的判断

关于时间控制器

  1. 循环定时任务
  2. 延迟功能
  3. 在客户群运营SOP处，参考鲸奇，把延迟和动作整理到一个组件，这样方便客户理解和编辑运营流程

SOP冲突

如果有一个用户同时落在多个SOP内，则只执行一个SOP
优先级顺序： 事件SOP>客户群>客户商机>新客户 或者两个客户群SOP都命中的时候

暂时都执行，并线处理更简单，但是可能造成信息骚扰的情况 （后续根据实际客户反馈 再讨论优化）

草稿

产品 实现策略 缺点 优点
有赞 客户分群/营销计划 不支持多个计划 动态用户分层
尘锋 客户分群/营销计划 不支持多个计划 动态用户分层
艾客 客户分群/营销计划 不支持多个计划 动态用户分层
微伴 Board/Stage 静态用户分层 支持多计划，符合社交剧本
鲸奇 Board/Stage 静态用户分层 支持多计划，符合社交剧本

综上，我们采取策略：
客户分群/Stage

任务
触发条件
时间
一次性定时执行
每多长时间定时执行
事件
触发事件
事件:
自定义 发消息
事件类目
参数:
渠道：微信 / 企业微信

事件不完全列表
发消息
拉群
发朋友圈