不要构建，不要集成 - CRM 集成指南

已发表: 2022-03-11

假设您正在为一家在所有行业销售机器人的初创公司工作。您接受来自各种客户的订单，运营团队评估订单并与第三方供应商合作，为您的客户提供合适的机器人。

建立 MVP 压力很大，但也很有趣。你的投资者很兴奋，并用钱给你洗澡。下一阶段开始。您需要更多地了解盈利能力，并且希望获得需要更复杂发票的更大客户。同时，你有一个非常复杂的产品路线图，可以销售利润率更高的机器人。资源稀缺，但您仍然需要确保公司保持运转。

正如小公司经常宣扬的那样，专注于你擅长的事情是一个很好的经验法则。但是，维持公司日常运营的所有领域又如何呢？您当然不想构建客户关系管理 (CRM) 系统或会计系统。毕竟，有很多产品可以解决所有问题。但是这些系统将如何与您现有的订单系统协同工作？

这是第三方集成派上用场的地方。所以，让我们深入研究一下，看看我们是否可以避免一些常见的陷阱。

客户关系管理整合

无论您是进行低接触式销售（内容营销、社交媒体广告或时事通讯）还是高接触式销售（电话推销、参加会议或通过电话跟进现有客户），CRM 系统都可以为您提供很多了解您在现有客户方面的表现以及您在说服新客户方面的成功程度。

通常，CRM 系统的选择主要由销售和营销部门决定。一般来说，这没有什么问题。毕竟，这些人最了解如何增加收入，并且需要最好的支持。但是，如果不能与您的机器人订购系统一起正常工作，即使是最好的软件也一文不值。

在决策中包括您的技术部门

无论是 CTO 还是专门的工程师，从一开始就让他们参与进来。它们很可能让您更深入地了解这两个系统将来如何协同工作。

对工程师说一句话：对第三方解决方案保持开放的态度。很容易忽略这些，因为它们的 API 不是最好的，或者它们的 UI 很丑。但是，围绕现有系统找到优雅的解决方案可能会非常有益。

然而，在做出决定之前，有几个话题可以讨论。诸如“我们需要这个吗？”之类的一般主题需要解决。但是，已经了解范围是什么也是一个好主意。是否需要双向同步，还是第三方系统只会遵循订单系统？一旦范围超出了范围，还需要就实现细节进行技术讨论，例如 webhook 或 API 限制的评估。

您是否需要自定义集成？

在集成方面，已经有现有的平台承诺解决您可能遇到的一些问题也就不足为奇了。目前，Zapier 和 IFTTT 是最有前途的。

根据您要解决的问题，您的机器人订单系统甚至可能不参与集成。假设您正在使用 Salesforce 或 HubSpot 等 CRM 系统管理您的时事通讯订阅者，并且只想通过 Mailchimp 等电子邮件服务提供商以更方便的方式与他们联系，Zapier 拥有大量现有的集成来帮助您。从这一点来看，选择具有 Zapier 连接器的提供商是一个很好的前进方向。

即使涉及到集成自定义数据（订购的机器人及其价格），Zapier Webhooks 也可以充当您集成的中间人。

另一方面，如果您已经在向第三方发送数据，为什么不直接将其发送到 CRM 系统呢？您要同步的数据越多，直接集成就越有用。

这让我想到了下一点。

您需要双向同步吗？

通常，集成从一个简单的要求开始，例如我们可以让所有客户进入我们的 CRM 系统吗？ ，通常与单个机器人订单的值相结合，从而更容易使用客户端细分工具。

但是，迟早，人们可能会想要使用 CRM 套件通常提供的联系人管理工具。其中包括重复数据删除、使用社交媒体数据修改联系人详细信息、规范送货地址或只是删除旧联系人等功能。

更改 CRM 系统中的联系人很可能意味着您需要更改另一个系统中的联系人详细信息，即，更改需要双向进行。

实现这一目标的工作远远超出了简单的单向同步，因此这是考虑如何战略性地使用新系统的绝佳点。

您将如何收到来自 CRM 的更改通知？

如果您决定进行双向同步，还有一个后续问题：您如何知道 CRM 方面发生了变化？

大多数系统提供商都有这方面的工具，但最好的即时更改工具是 webhook——本质上是一个 HTTP 通知系统，可以配置为让您了解相关更改（对于某些系统，甚至逐个字段） .

如果系统不提供 webhook，至少检查您是否可以获得最近更新的所有实体的列表。这样，您不必通过所有联系人和交易来更新您自己的数据。但请记住，您需要定期轮询系统。

在这种情况下，您的订单系统仍将通过 CRM 系统上的 API 调用来更改和创建数据。但是 CRM 系统的所有更改都将在定义的时间间隔内进行轮询。

值得注意的是，更新将被限制在这个间隔内，并可能导致临时数据不一致。例如，当您每天只从 CRM 系统同步一次到订单系统时，您在订单系统中查看的数据可能长达 24 小时。

根据系统提供的功能，集成任务的复杂性和实施时间会有所不同。确保提前检查系统提供的内容，并仔细检查您打算购买的计划。例如，一些 CRM 系统在高薪层提供 webhook。

此处的一个示例是 HubSpot 的 CRM，它通常提供 webhook，但 webhook 功能仅在其 Enterprise 包中可用。会计工具 Zoho Books 将在其最低层提供五个自动化工作流程（包括 webhook）。

您的数据状况良好吗？

在外部系统中创建数据集时，最好了解数据在您自己的系统中的样子。幸运的是，没有太多不同的方式来呈现联系人和交易，但总是会引起麻烦的一个字段是电子邮件字段。

不同的系统对什么是有效的电子邮件地址有不同的想法，这里有一个剧透警告——您的客户可能向您提供了各种无效的电子邮件地址。许多 CRM 系统会拒绝使用无效电子邮件地址创建联系人（当然，CRM 提供商会定义什么是有效的，什么是无效的）。

提示：如果可能，仅将确认的电子邮件地址同步到您的 CRM。 从长远来看，这将为您节省很多痛苦。

API 限制

最后，API 限制是需要尽早解决的问题。

假设有一个 API（这基本上是任何集成的必备），看看 API 的局限性是有益的。大多数初创公司可以应对大多数 CRM 系统的基本 API 限制。例如，HubSpot 每 24 小时提供 250,000 次 API 调用，即使在其免费套餐中也是如此。另一方面，它还将调用限制为每秒 10 次（如果使用 OAuth，则为 100 次）。市场领导者 Salesforce 每 24 小时只允许 100,000 个，但提供购买更多。

大多数情况下，您很容易陷入这些限制，但需要考虑一件事：您的初始运行情况如何？一开始，您将向您的 CRM 推送大量联系人和交易（如果有问题，可能会多次推送）。因此，您可能会达到每日 API 限制。

为了缓解这种情况，您可以使用小型数据集进行测试，并在整个实施过程中缓慢增加数量以保持在 API 的限制范围内。对于初始迁移，请计划好几天或一个周末。或者，联系提供商并让他们知道您的意图。当您处于评估阶段（并且尚未为系统付费）时，他们可能愿意稍微增加您的 API 限额。

客户关系管理实施

假设你们都同意。您选择了一款出色的 CRM 工具，工程师们相信它可以很容易地集成。您决定将其范围限定为仅推送客户数据并接受机器人订单。因此，不需要双向同步，地址更改只会在您自己的订单系统中处理。

在实施阶段仍有一些最佳实践需要遵循。

在测试环境中尝试一切

在大多数情况下，只有在您的集成完成并准备好使用后，才会使用 CRM 系统。对于这个用例，在开发过程中只使用生产系统似乎很有吸引力。毕竟，没有您可能影响的生产数据。开发完成后，您只需删除您创建的所有测试数据，运行初始迁移，并将您的订单系统指向此环境。

这种方法有几个问题：

你只是在路上踢罐子。 即使您的上线顺利进行，迟早也会有功能请求来更改您的部分集成。鉴于功能请求足够大，您可能需要另一个测试阶段。在这一点上，一个单独的测试系统是不可避免的；否则，您最终可能会弄乱生产数据。那么，为什么要等到您被要求实现第一个功能时才进行设置呢？
你最终会得到一个混乱的配置。 您的 CRM 系统很可能需要某种配置来满足您的订单系统的需求。状态名称可能需要调整，通常需要创建自定义字段等等。由于大多数开发人员需要习惯 CRM 系统，因此将添加一个长期不需要的配置。实际上，这种未使用的配置不会在以后删除，甚至可能永远保留在您的 CRM 中。通过强制将配置从测试系统复制到生产系统的额外步骤，您很可能最终会在生产系统上获得更精简的配置。

应该注意的是，如果您忘记将配置从测试复制到生产系统，这也会对您不利，最终会出现生产错误。

虽然有一些 CRM 系统可以帮助您比较和复制配置项，但一般来说，写下您的配置以免忘记关键项目会很有用。大多数 CRM 为其配置提供 API，因此可以自动执行此步骤。
污染生产数据的风险更高。 想象一下，两个开发人员正在进行集成。您已经拥有机器人订单系统的暂存系统。此登台也与您的 CRM 相关联。集成交付后，您需要记住断开所有三个系统的连接，否则，您最终可能会在（现在）生产 CRM 上创建测试数据。

从一开始就针对测试系统进行开发可以避免所有这些问题。制作只在最后介绍，就在一切上线之前。通过这种方式，您最终得到了一个干净的配置，不会冒忘记断开本地系统连接的风险，并且在实施新功能时要注意。

定义匹配实体的 ID

现在，让我们开始编写实际的集成代码。让我们以将联系人同步到 CRM 系统为例。据推测，您将需要创建新联系人并更新现有联系人。为了区分创建和更新，您需要链接这两个实体。这样，您可以检查系统中的联系人是否存在于外部系统上。

虽然只使用电子邮件地址似乎很有吸引力（毕竟，它是联系人记录的通用标识符），但有一个更通用的解决方案 - 对于每条记录，您同步到外部系统保留和您自己数据库中的 ID。

因此，使用名为crm_id或external_id的列修改您的联系人表。这种方法有几个优点：

因为它是一个 ID，所以它不会改变（与电子邮件地址或电话号码不同）。
无需先调用 API 即可查看是否需要创建或更新实体（如果外部 id 字段为空，则可以假设联系人不存在）。

前：

顾客
大整数	ID
细绳	姓名
细绳	电子邮件

后：

顾客
大整数	ID
细绳	姓名
细绳	电子邮件
细绳	hubspot_id

例如，假设您是一名 Ruby on Rails 开发人员，正在开发一个需要将现有客户和新客户同步到 HubSpot 的应用程序。

一个简化的代码示例可能如下所示：

 class HubspotSync def sync(customer) hubspot_return = if customer.hubspot_id.present? update(customer, customer.hubspot_id) else create(customer) end customer.update(hubspot_id: hubspot_return['companyId']) end private def create(customer) response = HTTParpty.post("https://api.hubapi.com/companies/v2/companies", map(company)) handle_response(response) end def update(customer, hubspot_id) response = HTTParpty.put("https://api.hubapi.com/companies/v2/companies/#{hubspot_id}", map(company)) handle_response(response) end def handle_response(response) raise RuntimeError, "Unexpected Status code: #{response.code}" if response.code >= 500 JSON.parse(response.body) end def map(company) # mapping code goes here { properties: [ name: 'name', value: company.name ] } end end

请注意我们如何利用保存从 HubSpot 返回的companyId 。它不仅可以帮助我们确定是否要在 HubSpot 上更新或创建公司，而且我们还可以在数据库表中看到哪些实体已经同步到 HubSpot，哪些实体仍然缺失。

当涉及到映射字段时，去自由式

我见过在实施之前创建一个巨大的 Excel 电子表格的项目，该电子表格定义了哪些列在 CRM 系统中的位置，并带有关于如何转换数据的注释。

实际上，只有几种表示联系人和交易的方法。因此，与其花大量时间思考您究竟想如何映射，何不从实验开始呢？给开发人员一些空间来弄清楚映射，但也要保持联系，以便尽早提出问题。

至少对于一般的联系人字段（姓名、电子邮件地址、电话号码、地址），映射会非常简单，而且转换通常是微不足道的。

当涉及到交易的状态映射时，多一点沟通会很有帮助（有时，第一个状态称为open ，有时是new ，有时状态模型不是 100% 匹配，因此您必须将状态组合在一起）。与其想出完美的解决方案，不如查看您当前的数据，看看它如何最适合 CRM 的数据模型。毕竟，你是一家敏捷公司，对吧？

在上面的示例中，您可以看到将我们的 Rails 模型转换为 HubSpot 可以理解的常规哈希的 map 方法。对于这个特定的用例，唯一同步的项目是名称。对于更高级的用法，您可能希望包含更多字段，但为了获得更好的结果，请从有根据的猜测开始，并经常与业务方沟通以获取详细信息。

考虑重试

让我们深入到技术层面：实现系统和 CRM 之间的实际同步。几乎可以肯定的是，集成将通过 HTTP 连接进行。大多数系统都提供 HTTP API，所有编程语言都可以让您非常轻松地进行 HTTP 调用。

不幸的是，无论您在 CRM 系统上花多少钱，最终都无法使用。这将在某个时候发生，您对此无能为力。因此，您不妨在开发集成时考虑到这一点。

这在实践中意味着——无论何时调用 API，确保在出现问题时重试调用（来自另一端的 500 状态代码）。实现重试通常由您选择的语言的第三方库提供。

除了重试之外，您可能还需要考虑记录到底发生了什么。收到有关在第一次重试中已解决的错误的通知可能会令人沮丧。

因此，与其用已解决的问题向您的错误通道发送垃圾邮件，不如记录所有带有重试次数的标注，以了解系统的可靠性——您刚刚花了很多钱购买的系统。

如果我们以我们创建的类为例，并且我们停留在 Ruby on Rails 的上下文中，我们可以简单地将调用包装在ActiveJob中，并且相当肯定调用最终会成功。如果出现意外状态代码， handle_response方法将引发错误，并且ActiveJob将尝试使用指数退避重试。对于更高级的解决方案，您还应该考虑 4xx 状态代码，以便防止重试并引发错误消息。

 class HubspotSyncJob < ApplicationJob def perform(customer) HubspotSync.new.sync(customer) end End

确保系统被实际使用

好的，假设您已全部发货。你为你的工作感到非常自豪，系统上线了。怎么办？这仅仅是个开始。因为无论您进行多少测试，总会有错误和请求的更改。

问题是，除非您实际使用您的系统，否则您不会知道这些。发生这种情况的原因有很多——销售部门目前太忙而无法开始使用它，战略改变了，甚至新系统已经在评估中。

因此，为了避免长期的潜在问题，请确保您已经消除了阻碍系统生产使用的所有障碍。经常在团队之间进行沟通，以使新需求保持一致。如果您发现该系统不适合您，请关闭集成。这听起来很刺耳，可能会让人感到非常沮丧，但它比总是必须修复数据不一致问题和处理变通方法更令人沮丧。

包起来

归根结底，集成项目是一个地狱项目，有很多事情可能会出错。由于多种原因，它在工程师中不是很受欢迎，但看到实施对坐在你旁边的人的生产力产生积极影响可能会很有意义。

因此，对于工程师来说——尝试通过提出具体问题来了解外部系统（如 CRM 或发票系统）的需求，例如：该产品将如何让您的生活更轻松？ 你考虑过竞争对手吗？ 为什么他们不工作？

对于其他所有相关人员 - 尽早让工程师加入，当他们指出红线时信任他们，并且当您看到集成的实施将使其变得更加困难时，不要选择便宜的计划长跑。