有限状态机 (FSM) — 流程构建器背后的模型

FSM 是一种数学模型，广泛应用于软件、游戏、人工智能等领域中的顺序系统设计。

"它是一种抽象机器，在任何给定时间都处于有限状态中的一个。FSM 可以根据某些输入从一个状态迁移到另一个状态；从一个状态到另一个状态的迁移称为状态迁移。FSM 由其状态列表、初始状态以及触发每个迁移的输入定义。"

来源：中田纳西州立大学

有限状态机（FSM）在现实世界中的例子包括地铁车站常见的投币式旋转门，或电梯、组合锁和自动售货机。旋转门只能处于锁定或解锁状态——因此有两个状态（有限的）。为了从锁定状态变为解锁状态，它需要一个硬币。硬币触发了从状态 A 到状态 B 的迁移。在解锁状态下，硬币不会将其重新置于锁定状态——它需要被转动并重新卡回原位。同样，没有硬币也无法打开它。因此这是一个清晰且无懈可击的系统——购买一个硬币来解锁通过旋转门的通道。

在软件中，各种 BPM 解决方案都基于有限状态机进行建模，因此必然存在相似之处。它们都可能包含状态和迁移，因为有限状态机方法主要涉及的就是这些内容。

因此，基于有限状态机模型的 Zoho CRM 中的蓝图和旅程构建器都包含相同的构建模块——状态、迁移和操作。然而，您如何使用这些组件在两者中有所不同，因为这两种解决方案的目标不同。以下是两者之间的一些基本差异因素。

主要目的

蓝图是一款用于促进合规性的业务流程管理工具，而 旅程构建器 则是一款用于优化跨业务触点的客户旅程的工具。

流程中的状态与旅程中的状态

蓝图中的状态是由记录布局中存在的选项列表值构建的。由于它有助于管理合规性，蓝图允许您将选项列表值（如线索状态、商机阶段）视为状态，并帮助您从记录创建时起管理其跨不同阶段的进展。

旅程构建器 中的状态表示客户在整个购买旅程中所处的位置。这个状态可以与 CRM 模块相关联。例如，当访客注册您的产品时，他们可以被归类为线索，他们的网页表单提交可以在旅程中被标记为名为“线索创建”的状态，该状态映射到线索模块。随着他们在旅程中前进，您需要指示 CRM 他们需要映射到哪个模块，以便跟踪。除此之外，旅程构建器 中的状态是自由形式的，也就是说，在构建旅程时，您可以创建自己选择的状态。它们不是来自一个选择列表字段，也不像 蓝图那样需要预先定义。

迁移 Vs 触发器

蓝图指导销售团队通过系统化流程。作为指导的一部分，蓝图在各个阶段提示团队提供数据，验证接收到的数据，并自动化常规操作，从而促进全面合规。无论是录入字段、获取附件还是划掉检查清单等任务的顺利执行，都会使记录从一个状态迁移 为另一个状态。

使用 旅程构建器，不存在“收集数据”或指导团队的问题，因为那并非其目标。其目标是根据先前结果来协调一系列事件。例如，当有访客访问网站时，应向其发送实时聊天消息，而随后的聊天回复则应通知客服人员并发送确认邮件给客户。这封邮件随后应触发 提醒客服人员处理聊天消息的后续提醒。在这个简单的例子中，您可以看到其目标是自动化一系列操作或事件，以使客户体验更加愉快。这不仅仅针对单个客户，而是所有通过网站和聊天小部件的客户都将获得这种体验。因此，这一切都是关于全面优化客户旅程。

推动客户从购买旅程的一个阶段进入下一个阶段的是他们接收到的信号或事件，这些信号或事件会触发或推动他们继续旅程。基于这些触发因素，后续的行动会被制定。因此，这里的迁移模块不是数据要求，而是信号或事件。例如：打开邮件、对问卷调查做出回应、提交服务台工单等等。

 

差异因素	蓝图	旅程构建器
目的	合规性管理	客户旅程优化
这是为谁设计的？	内部组织团队	客户
状态定义	业务流程中的每个阶段。也就是说，所选状态选择列表字段的值。	客户在其购买旅程中所处的阶段。
迁移定义	蓝图中的迁移规定了应遵循的指南、应执行的操作以及指定用户或团队应提交的数据。执行规定的操作将使记录从一个状态转移到另一个状态。	旅程构建器中的迁移指示了信号/触发器/事件，当遇到这些信号/触发器/事件时，记录将从一种状态转移到另一种状态。
状态和迁移的示例。	S状态 1：收到咨询 状态 2：创建需求简报 状态 1 和状态 2 之间的迁移：创建简报 附加文档 添加关于需求说明的备注 添加必填字段："所需产品/服务。" 这意味着，在收到咨询后，下一步是验证并添加正确的联系信息。只有当电话、电子邮件字段已提供时，才会进入下一阶段"咨询培育"。	状态 1：创建线索 状态 2：线索感兴趣 状态 1 和状态 2 之间的迁移（信号/事件）：打开邮件 当线索"打开邮件"时，这可能是作为状态 1 的一部分发送的。因此，打开邮件是一个信号或事件，让 CRM 系统确认并将线索从点 1 移动到旅程中的点 2。

 

常见问题解答

在 Zoho CRM 中，指挥中心是否可以被称为“跨模块的蓝图”？

不是的，这种说法并不准确，因为蓝图和指挥中心（旅程构建器）在目标本质上存在差异。确实，目前 蓝图是为单个模块构建的，而指挥中心可以跨模块构建。但这只是一个技术上的差异，仅仅因为这个差异，不能假设旅程构建器 是一个跨模块的蓝图，因为它们旨在解决不同的问题。

1. 蓝图旨在优化内部流程和合规性。
   即使 蓝图不久后能够跨模块构建，它仍然会解决合规性问题，因此其运作方式将与旅程构建器 不同。
   
2. 而旅程构建器 主要帮助您在业务触点之间协调一系列计划的互动行动。
   即使它是为单个模块构建的，它也会包含触发器和互动操作，而不是像蓝图那样包含数据要求。
   

旅程构建器 和销售节奏 有什么不同？

1. 销售节奏 可以看作是 旅程构建器 的一个子集。
   
2. 如果您只需要简化后续行为——也就是说，使用电子邮件、任务和电话等方式跟进线索，直到获得预期回应——那么请使用销售节奏。
   
3. 您同样可以在 旅程构建器 中实现上述功能，但可能会比较繁琐，而销售节奏 将帮助您轻松实现后续编排。基于先前打开、点击或退回的邮件、任务或电话关联更加无缝，并且直接在销售节奏 的界面中处理，您无需在 旅程构建器 中仔细配置这些触发器。
   
4. 这样您也可以将所有基于后续互动的编排工作从 旅程构建器 转移到销售节奏，并有效利用 旅程构建器 专注于在成功跟进后进行更专业的互动行动。
   
5. 销售节奏 在线索管理阶段直到线索参与之前非常有效。旅程构建器 则更适用于在首次成功接触后继续互动，并继续简化旅程直至购买、留存、忠诚度和倡导。

交互信息界面构建器 和向导有什么不同？交互信息界面构建器 是一种流程管理解决方案吗？

交互信息界面构建器 和 向导都是用于定制您的 Zoho CRM 账户的解决方案。交互信息界面构建器 本质上是一个定制解决方案，它帮助您定制 UI 流程以执行临时流程。它是一个无代码平台，您可以在其中创建自己的小部件，并在其中执行自定义操作，如数据输入、检索、自动化等。而 向导是一个专注于数据体验的特定定制解决方案。

向导目前以系统化的方式处理记录创建，通过将一个冗长杂乱的表单拆分为更周全的段落或"屏幕"，从而让数据录入变得不那么令人困惑，甚至成为一种享受。您可以保存记录为草稿，并在您准备更详细信息时回来继续编辑。例如，您在电话中有一个线索，并试图向他们介绍您的产品。在通话过程中，您对线索的某些字段（如他们的需求细节、公司背景等）并不清楚。因此，您可以简单地保存记录为草稿，在您掌握所有详细信息后再回来编辑，然后将其发布到系统中。因此，向导专注于在 CRM 中实现这种数据体验的灵活性。您还可以自动化告警。了解更多>>帮助文档

而交互信息界面构建器不仅仅用于数据输入或检索，还超越了这些功能——它可以帮助进行数据输入、检索、执行告警、自定义功能以及其他常规操作。更重要的是，它可以在您的 CRM 系统中的方便位置部署，例如首页、列表视图或详细信息视图，甚至是在设置空间中。您可以使用它来获取选定记录并从单个组件中的多个模块更新特定信息，您还可以将其用作调用脚本，并且几乎可以根据您组织的需求进行定制。

了解更多 >> 帮助文档

让我们以一家名为 Zylker Travels 的公司为例，看看一个简单的自助服务终端。想象一下，一位旅行代理正在与客户通电话。客户希望快速重新安排他们的行程。对于代理来说，导航到正确的模块并更新正确的字段可能很困难。因此，Zylker 创建了一个自助服务终端，无需开发人员的帮助，创建了一个定制的组件，并将其部署在主页上，以便代理可以快速访问它，与组件交互，仅更新相关字段，并导航到一个灵活且超级简单的、专门为他们的组织设计的 UI 流程。

这是交互信息界面构建器的配置样式：

蓝图、旅程构建器和销售节奏流能否都无问题地运行它们的流程？