如何为CRM实时行动自动化创建一个规则引擎? - Picnic

22-04-08 banq

Picnic公司的独特的服务有赖于两个团队:Customer Success 和 Marketing 团队,但是与客户群规模相比,这两个团队相对较小,因此人少办事多,那么自动化就是应对这一挑战的答案,而这正是规则引擎发挥作用的地方。
在这篇博文中,我们将深入探讨业务流程自动化领域,特别是我们营销活动中的客户定向互动,以及传统的营销CRM解决方案在多大程度上能够解决我们的问题。最后,我们将解释为什么Picnic决定在这个已经很拥挤的解决方案领域建立规则引擎,即我们自制的自动化平台 :)

实现独特体验的自动化
我们的业务团队每天都在努力工作,以确保尽可能好的客户体验。为了实现这一目标,有必要对横跨我们主张的每一部分的广泛主题进行个性化。其中一些个性化的内容包括

  • 确保我们在产品缺货的情况下选择合适的替代品。
  • 确保我们在延迟交货的情况下迅速通知客户,如果与客户之前的订单相关,则要求客户提供具体的退货物品(如瓶子)。
  • 从客户的购物行为中学习,例如,将他们最喜欢的产品放在最前面,或者如果他们以前搜索过奶酪,则将其与 "broodbeleg "交叉列出。

尽管我们的许多日常流程属于 "通用自动化 "的范畴,但由我们的决策流程产生的大多数行动都属于 "针对客户的行动自动化 "的范畴。这包括营销活动,交易沟通,以及其他类型的 "提示",我们可以针对客户。
为了处理此类行动,我们采用了传统的客户关系管理器(CRM)。
在接下来的两章中,我们将充实我们对以客户为目标的行动自动化的需求,并对我们目前的第三方CRM解决方案的优势和劣势进行概述。

我们对以客户为目标的行动的需求
以下是我们对针对客户的行动的一些要求。

  • 营销沟通:营销沟通包括所有主动的对外沟通,从在线收购绩效营销到客户旅程信息和我们每周的促销摘要电子邮件。我们希望有一个易于使用的平台来操作这些流程。
  • 交易性沟通:交易性沟通是我们发送给客户的所有反应性沟通,这些沟通与所下的订单有一定关系,或由客户的直接行动引发。它包括订单确认信息、ETA信息、收据、密码重置邮件和注册确认。我们在这里需要低延迟和正常运行时间的保证。
  • 其他以客户为目标的劝告:我们使用通用术语 "暗示 "来描述一切我们可以个性化或针对特定客户的非直接沟通。这可能包括在客户的购物篮中添加礼物,以纪念他们在Picnic购物一周年,在主题页面的顶部展示素食产品,或对有足够信用分数的客户启用直接借记作为支付方式。我们需要一个解决方案,能够将这些暗示与更传统的沟通行动结合起来,以支持强大的活动。


失败教训:用于CRM营销的Selligent
对业务流程自动化的需求有相当大的一部分来自营销和个性化领域,我们的营销和业务团队为此使用了Selligent。让我们来看看我们的实施情况,以了解哪些方面对我们有效,哪些方面我们面临困难。

对我们有利的是什么:
有几个因素使我们对Selligent的使用特别有效。

  • 数据:两年前,我们向Selligent实施了事件驱动的数据同步。我们的整个营销数据模型现在可以达到1分钟的延迟,包括所有细分处理。
  • 为营销人员提供简单的用户界面。建立营销活动的用户界面对于技术水平不高的营销人员来说相对容易使用。受众的选择也可以通过数据模型上的拖放用户界面来完成。
  • 渠道和催促:电子邮件由Selligent开箱即用,所以我们不必担心SMTP的问题。除此之外,我们还建立了与大量内部通信发送API的集成,因此,例如,发送应用内信息就像发送电子邮件一样简单。我们还与其他内部API集成,以获得针对客户的提示,如礼物、功能旗帜等。
  • 交易性沟通:我们的大部分交易通信是由Selligent处理的。然而,它在很大程度上依赖于外部触发逻辑和数据供应,这意味着我们这边有一些特定的供应商集成逻辑。


哪些事情不那么好办:
正如你可以想象的那样,也有一些事情让我们感到纠结。我们现在已经在这个领域做了相当多的研究,这个清单似乎对大多数第三方CRM供应商来说都是真实的。
  • 只有基于时间表:CRM平台中的开箱即用活动是基于时间表的。安排一个活动每10分钟运行一次并不能满足实时执行SLA,而且严重增加了系统的运行负荷。这意味着,实时触发依赖于后端集成,因此需要开发,这就剥夺了业务用户的灵活性和可用性。
  • 有限的数据保留:营销依靠数据进行受众选择、个性化和细分。然而,这些CRM平台的存储容量是有限的,额外的数据保留往往是有代价的。
  • 缺少版本控制和可观察性:营销型CRM是营销人员的灵活和敏捷的工具,但它们缺乏我们在工程中习惯的关于版本控制和可观察性的能力。这对一次性的批量营销活动来说不是问题,但当你实施更多的关键操作流程时,它就变得越来越具有挑战性。
  • 只针对客户的行动:CRM营销活动从选择主要客户名单的一个子集作为受众开始,并按照流程图对这些受众成员执行行动。这种流程在这些平台中是相当牢固的,这使得它们在通用的行动自动化方面不太灵活。

总之,CRM营销应用在其建立的目的方面非常出色:基于日程的营销沟通自动化。但是,当你试图将其扩展到实时或通用的行动自动化时,你很快就会遇到一些砖墙。

实时业务规则
这是规则引擎项目的出发点。我们对实时通信和个性化的兴趣越来越大,我们看到越来越多的用例用于更通用的行动自动化。

  • 当一个送货时段满了90%,我们想用推送通知的方式通知客户。
  • 当一辆送货车辆晚了15分钟,我们想用短信通知客户。
  • 当我们由于库存不足而无法挑选物品时,那么我们希望尽快提供一个替代物的选择。
  • 当客户付款失败时,我们希望通过应用内的信息立即伸出援助之手。
  • 当一个送货时段几乎满员时,我们要平衡它与邻近时段的容量。

这样的例子不胜枚举 :)
请注意,所有这些例子最终都会触发某种时间关键的 "行动",但它们超越了交易性通信的标准列表,因为它们比你的静态密码重置邮件更灵活,或者甚至与通信无关。
另外,请注意,这种流量的 "触发器 "必须来自我们的后端系统。这些是唯一能即时知道车辆被延迟的系统。

最后,我们要对这些触发器做出反应的 "如果 "和 "如何",主要是业务团队的关注。我们是否在延迟10分钟或15分钟后发送该短信?一个推送信息就够了吗?对客户沟通感兴趣的业务团队在这方面有很大的利益。然而,负责设置这一流程的后端工程师可能对这种实施细节不太感兴趣。

当我们注意到所有这些例子都可以用一个标准的形式来表述时,这一切都汇集到了一起--

"当X,如果Y,然后做Z"
- 我们称它们为实时业务规则。
正是在这个时候,规则引擎的想法(或者至少是名字:/)诞生了。

项目目标
因此,我们想建立一个工具来实现业务规则的自动化。它必须提供比CRM应用更多的灵活性,但又能完全由对操作它感兴趣的业务团队来建立和管理。
很好。现在我们需要用一些功能需求和组织目标来完善它。

功能要求:

  • 实时自动化:用于面向客户的和通用的行动自动化,具有高发送SLA。
  • 由广泛的数据支持:根据广泛和深入的背景数据进行决策,实现个性化和生命周期细分。
  • 行动输出控制。支持所有针对客户的和通用的API,对行动组进行原子式执行。
  • 规则生命周期管理。逻辑的版本控制,组件测试功能,以及回滚变化的能力。
  • 实时监控。即时了解规则评估、产生的行动和执行的行动。
  • 透明度。对所有触发的行动、负责的规则和触发的原因进行全面的历史回顾。


组织目标

  • 业务拥有:规则由业务分析员建立和配置 - 不需要后端开发。
  • 持续集成:不依赖产品团队的发布周期,导致更快的迭代。
  • 总览和可审计性:在一个地方可以看到、检查和管理所有的规则。

有了这些要求和目标,我们希望能解决在我们的CRM应用中发现的缺点,同时使业务团队也能开始工作在更普遍的自动化主题。

走向一个落地架构
如前所述,从概念上讲,每个规则都是一个触发器的组合,它启动了一个评估("when"),一组要检查的条件("if"),和一组要执行的行动("then")的条件。我们需要找到候选人来实现这些。
最后,我们需要一个系统来定义规则逻辑并管理版本控制,还需要一个接口来管理我们规则的生命周期并提供监控。

触发器:
对于实时触发器,我们有一个很好的候选人。Picnic 运行一个微服务架构,因此我们已经有了一个在 RabbitMQ 中实现的成熟的事件总线,其中每个服务通过事件交流相关的状态变化。用这些事件来触发评估是有意义的。

条件:
为了检查我们业务规则中的条件,我们需要可与我们的 CRM 中的数据相媲美的上下文数据,但又能为更广泛的用途进行大量扩展。此外,我们还需要一些DSL来使用户和规则评估能够访问这些数据。SQL似乎是这里的自然选择。

行动:
大多数与我们相关的行动已经以处理这些请求的内部服务所暴露的REST端点的形式实现。剩下的就是为每个动作创建绑定,并进行有意义的输入验证。

定义规则逻辑:
我们想让我们的业务分析员能够定义这些规则。以上所有的组件都需要由我们的分析员在逻辑上粘在一起。我们选择用脚本语言Javascript和Python来完成这些工作,这些语言对他们来说是可访问的,而且足够熟悉。
我们的技术团队已经广泛地使用GitHub,包括CI/CD、linting和组件测试的集成。我们需要验证我们的业务用户在多大程度上愿意并能够来到黑暗的一面。

生命周期管理和监控:
在规则逻辑得到验证、同行评议并合并到我们的规则库后,是时候将其推入运行了。为此,我们将需要一个专有的前端来启用、禁用和监控规则。这可以作为另一个博客的主题,所以现在我们先不谈这个问题 :)

使我们的团队能够做他们最擅长的事情
规则引擎最初是业务团队的一个概念性愿望,即能够直接为实时和通用的行动自动化作出贡献。它演变成一个项目,使分析师能够拥有自己的实时互动流程,同时将后端团队从这些流程的设置和迭代中解脱出来。
有了规则引擎,后端团队现在可以专注于他们最擅长的工作。

  • 发出丰富的数据事件以示任何相关的状态变化,以及
  • 暴露端点以触发强大的行动。

而业务团队现在可以专注于他们最擅长的事情。
  • 定义逻辑,将发生的事情转化为行动,以及
  • 迭代和微调,以便每天更好地服务客户。

在接下来的两篇关于这个主题的博客文章中,我的同事Philip Leonard将详细介绍我们实施的技术细节,敬请关注
详细点击标题。
 

猜你喜欢