假设你在一家面向所有行业销售机器人的初创公司工作. 你接受各种客户的订单, 运营团队会对订单进行评估，并与第三方供应商合作，为客户提供合适的机器人.

打造MVP很有压力，但也很有趣. 你的投资者很兴奋，给了你大量的钱. 下一个阶段开始了. 你需要更多的盈利能力的可见性，你想获得更大的客户，需要更复杂的发票. 同时, 你有一个相当复杂的产品路线图，可以销售利润更高的机器人. 资源是稀缺的，但你仍然需要确保公司的运转.

就像小公司经常鼓吹的那样, 专注于你擅长的事情是一个很好的经验法则. 但是那些维持公司日常运作的领域呢? 你肯定不想建一个 客户关系管理(CRM) 系统或会计系统. 毕竟，有很多产品可以解决所有的问题. 但是这些系统如何与你现有的订单系统一起工作呢?

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

CRM集成

你是否在做低接触销售(内容营销), 社交媒体广告, 或新闻通讯)或高接触销售(陌生电话), 参加会议, 或通过电话跟进现有客户), 客户关系管理系统可以让你了解到你是如何与现有客户打交道的，以及你是如何成功地说服新客户的.

通常，客户关系管理系统的选择主要留给销售和营销部门. 总的来说，这并没有什么错. 毕竟，这些人最了解如何增加收入，也需要最好的支持. 但是，即使是最好的软件，如果不能与你的机器人点餐系统正常合作，也毫无价值.

让你的技术部门参与决策

无论是首席技术官还是专门的工程师，从一开始就让他们参与其中. 它们很可能会让你更深入地了解这两个系统未来将如何协同工作.

给工程师们一句话:对第三方解决方案保持开放的心态. 人们很容易忽视这些产品，因为它们的API不是最好的，或者它们的UI很丑. 然而，围绕现有系统找到优雅的解决方案是非常值得的.

Nevertheless, 在做决定之前，有几个话题是有益的. 一般的话题 “我们真的需要这个吗??” 需要解决. 但是，已经知道范围是什么也是一个好主意. 是否需要双向同步，或者第三方系统将遵循订单系统? 只要把瞄准镜移开, 还需要对实现细节(如webhook或API限制的评估)进行技术讨论.

您是否需要自定义集成?

当涉及到积分时, 毫不奇怪，已经有一些现有的平台承诺可以解决您可能遇到的一些问题. Currently, Zapier and IFTTT 哪些是最有前途的呢.

取决于你想要解决的问题, 您的机器人订购系统甚至可能不涉及集成. 假设您正在使用CRM系统管理您的通讯订户，例如 Salesforce or HubSpot 只是想通过Mailchimp等电子邮件服务提供商更方便地与他们联系, Zapier has 大量的现有集成 来帮助你. 从这一点来看，选择具有Zapier连接器的提供者是一个不错的选择.

即使涉及到整合定制数据(订购的机器人及其价格)， Zapier人 可以作为你整合的中间人吗.

另一方面, 如果您已经将数据发送给第三方, 为什么不直接发送到CRM系统呢? 您想要同步的数据越多，直接集成就越有用.

这就引出了我的下一个观点.

你需要双向同步吗?

通常，集成从一个简单的需求开始，例如 我们能让所有的客户都进入我们的客户关系管理系统吗?, 通常与单个机器人订单的值相结合, 使其更容易利用客户细分工具.

However, 迟早的事, 人们可能会想要使用CRM套件通常提供的联系人管理工具. 其中包括重复数据删除等功能, 用社交媒体数据修改欧博体育app下载, 收货地址规范化, 或者只是简单地删除旧联系人.

在CRM系统中更改联系人很可能意味着您需要在另一个系统中更改联系人详细信息, i.e.在美国，改变需要是双向的.

这方面的实现工作远远超出了简单的单向同步, 所以这是一个很好的思考如何策略性地使用一个新系统的点.

客户关系管理的变更如何通知您?

如果你决定进行双向同步，还有一个后续问题: 你怎么知道CRM方面发生了什么变化?

大多数系统提供程序都有相应的工具, 但是对于即时改变来说，最好的方法是网络钩子——本质上, 一个HTTP通知系统，可以配置为让您知道相关的更改(对于某些系统), 即使是在逐场的基础上).

如果系统不提供webhook, 至少检查一下是否可以获得最近更新过的所有实体的列表. 这样，您就不必为了更新自己的数据而遍历所有联系人和交易. 但是请记住，您需要定期对系统进行轮询.

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

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

取决于系统提供的功能, 集成任务的复杂性和实现时间各不相同. 确保提前检查系统提供的内容，并仔细检查你打算购买的计划. 例如，一些CRM系统在高收入层提供webhook.

HubSpot的CRM就是一个例子, 他们一般都提供webhook，但是webhook特性只在他们的企业包中可用. 会计工具Zoho Books将在其最底层提供五个自动化工作流(包括webhook).

你的数据状态良好吗?

在外部系统中创建数据集时, 最好知道数据在您自己的系统中是什么样子. Luckily, 没有太多不同的方式来展示联系和交易, 但有一个字段总是会引起麻烦，那就是电子邮件字段.

不同的系统对什么是有效的电子邮件地址有不同的看法, 这里有一个剧透警告-您的客户可能已经向您提供了各种无效的电子邮件地址. 很多CRM系统会拒绝创建带有无效电子邮件地址的联系人(当然, CRM提供商定义什么是有效的，什么是无效的).

Tip: 如果可能，只将确认的电子邮件地址同步到CRM. 从长远来看，这将为你省去很多痛苦.

API的限制

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

假设有一个API(这基本上是任何集成的必需品), 了解一下API的局限性是有益的. 大多数初创公司可以应付大多数CRM系统的基本API限制. 举个例子，HubSpot每24小时提供25万个API调用，即使是免费的. 另一方面，它还将调用限制为每秒10次(如果使用 OAuth). 市场领导者Salesforce每24小时只允许10万个订单，但会购买更多.

大多数时候, 你将很容易陷入这些限制, 但有一件事需要考虑:你最初的跑步怎么样? 一开始, 你将向你的客户关系管理系统推送大量的联系和交易(如果出现问题，可能会推送多次)。. 因此，您可能会达到每日API限制.

为了缓解这种情况, 您可以使用一个小数据集进行测试，并在整个实现过程中慢慢增加数据集的数量，以保持在API的限制内. 对于初始迁移，要在几天内或周末进行计划. 或者，联系供应商，让他们知道你的意图. 当您处于评估阶段时(并且还没有为系统付费), 他们可能会愿意稍微增加你的空气污染指数津贴.

CRM的实施

假设你们都同意. 你选择了一个很棒的CRM工具，工程师们相信它可以很容易地集成. 您决定将其限定为仅推送客户数据和接受的机器人订单. Therefore, 双向同步是不必要的, 地址更改只会在您自己的订单系统中处理.

在实现阶段仍然有一些最佳实践需要遵循.

在测试环境中尝试所有内容

在大多数情况下，CRM系统只有在集成完成并准备使用后才会使用. 对于这个用例，在开发期间只使用生产系统似乎很有吸引力. 毕竟，您不会影响任何生产数据. 一旦开发完成, 您只需删除您创建的所有测试数据, 运行初始迁移, 将你的订单系统指向这个环境.

这种方法存在几个问题:

1. 你这是在拖延时间. 即使你的上线很顺利, 迟早的事, 将会有一个特性请求来改变集成的一部分. 如果特性请求足够大，您可能需要另一个测试阶段. 此时此刻, a separate testing system is unavoidable; otherwise, 最终可能会弄乱生产数据. 因此，为什么要等到您被要求实现第一个特性时再进行设置呢?

2. 最终得到一个混乱的构型. 您的CRM系统很可能需要某种配置来满足订单系统的需求. 可能需要调整状态名，通常需要创建自定义字段，等等. 因为大多数开发人员需要习惯CRM系统, 将添加一个长期不需要的配置. 实际上，这个未使用的配置以后不会被删除，甚至可能永远留在CRM中. 通过强制执行将配置从测试系统复制到生产系统的附加步骤, 您很可能最终在生产系统上使用更精简的配置.
   
   应该注意的是，如果您忘记将配置从测试系统复制到生产系统，这也会给您带来不利影响, 这样就会出现生产错误.
   
   虽然有一些CRM系统可以帮助您比较和复制配置项, in general, 写下你的配置是很有用的，这样你就不会忘记关键的项目. 大多数crm为其配置提供API，因此可以自动执行此步骤.

3. 您将面临污染生产数据的更高风险. 想象一下，两个开发人员在一个集成上工作. 你已经有了一个机器人订单系统的分期系统. 这个阶段也连接到您的CRM. 一旦您的集成发布, 您需要记住断开所有三个系统的连接, or else, 您最终可能会在(现在的)生产CRM上创建测试数据.

所有这些问题都可以通过从一开始就针对测试系统进行开发来避免. 制作只在最后介绍，就在一切上线之前. This way, 最终得到一个干净的构型, 不要冒忘记断开本地系统的风险, 并且在实现新功能时要事先知道.

定义匹配实体的ID

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

虽然使用电子邮件地址似乎很有吸引力(毕竟), 它是联系人记录的通用标识符), 有一个更通用的解决方案——适用于每条记录, 您将同步到外部系统持有和您自己数据库中的ID.

因此，用一个名为 crm_id or external_id. 这种方法有几个优点:

• 因为它是一个ID，所以不会更改(不像电子邮件地址或电话号码)。.
• 您可以查看是否需要创建或更新实体，而无需首先执行API调用(如果外部id字段为空), 你可以假设这个联系人不存在).

Before:

After:

例如，假设你是 Ruby on Rails开发者 正在开发一个应用程序，需要将现有和新客户同步到HubSpot.

一个简化的代码示例如下:

类HubspotSync
  def同步(客户)
    Hubspot_return = if customer.hubspot_id.present?
      更新(客户、客户.hubspot_id)
    else
      创建(客户)
    end

    customer.更新(hubspot_id: hubspot_return [' companyId '])
  end

  private

  def创建(客户)
    response = httparty.邮报》(" http://api.hubapi.com/companies/v2/companies”,地图(公司))

    handle_response(响应)
  end

  Def update(customer, hubspot_id)
    response = httparty.put (" http://api.hubapi.com/companies/v2/companies/ # {hubspot_id}”,地图(公司))

    handle_response(响应)
  end

  def handle_response(响应)
    抛出RuntimeError， "Unexpected Status code: #{response ..Code}" if响应.code >= 500

    JSON.解析(响应.body)
  end

  def地图(公司)
    # mapping代码放在这里
    {
      属性:【
        名称:“名字”,
        价值:公司.name
      ]
    }
  end
end

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

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

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

在现实中，只有几种方式来表示联系和交易. 所以与其花很多时间思考如何精确地映射, 为什么不从实验开始呢? 给开发人员一些空间来弄清楚映射，但也要保持联系，以便尽早提出问题.

至少对于一般联系人字段(姓名, 电子邮件地址, phone number, address), 映射将非常简单, 变换通常是微不足道的.

当涉及到交易的状态映射, 多一点交流是有帮助的(有时), 第一个状态被调用 open, sometimes new，有时，状态模型不匹配100%，所以你必须把状态组在一起). 而不是想出完美的解决方案, 查看您当前的数据，看看它如何最适合CRM的数据模型. 毕竟，你们是一家敏捷的公司，对吧?

在上面的例子中, 您可以看到一个map方法，它将我们的Rails模型转换为HubSpot可以理解的常规哈希. 对于这个特殊的用例，唯一同步的项是名称. 更高级的用法, 您可能希望包含更多字段, 而是为了一个伟大的结果, 从有根据的猜测开始，并经常与业务方面沟通细节.

考虑重试

让我们深入到更技术性的层面:实现系统和CRM之间的实际同步. 几乎可以肯定的是，集成将通过HTTP连接进行. 大多数系统都提供HTTP API, 所有的编程语言都能让你很容易地进行HTTP调用.

不幸的是，无论你在CRM系统上花了多少钱，最终都无法实现. 这将在某一时刻发生，你对此无能为力. 所以，当你在开发你的集成时，你可以把这个因素考虑进去.

这在实践中意味着——无论何时调用API, 如果出现问题，请确保您的呼叫被重试(来自另一方的500状态码). 实现重试通常是由您选择的语言的第三方库提供的.

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

So, 而不是向您的错误频道发送已解决的问题, 记录所有的callout和重试次数，以了解系统的可靠性-一个您刚刚支付了很多钱的系统.

如果我们以我们创建的类为例，我们停留在Ruby on Rails的上下文中, 我们可以简单地将调用封装在 ActiveJob 并且相当确定这个呼叫最终会成功. The handle_response 方法将在意外状态码的情况下引发错误 ActiveJob 会以指数级后退尝试重试吗. 获取更高级的解决方案, 您还应该考虑4xx状态码，以便阻止重试并引发错误消息.

类HubspotSyncJob < ApplicationJob
  def执行(客户)
    HubspotSync.new.同步(客户)
  end
End

确保系统被实际使用

好吧，让我们假设你把它都运出去了. 你对自己的工作非常自豪，然后系统就上线了. Now what? 这仅仅是个开始. 因为不管你做了多少测试，总会有bug和要求的修改.

问题是，你不会发现这些，除非你实际使用你的系统. 这种情况的发生有各种各样的原因——销售部门现在太忙了，没有时间开始使用它, 战略的改变, 甚至新的系统已经在评估中了.

So, 为了避免长期的潜在问题, 确保您已经消除了妨碍系统在生产环境中使用的所有障碍. 经常在团队之间进行沟通，以使新的需求保持一致. 如果你发现这个系统不适合你，就把积分关掉. 这听起来很刺耳，会让人感到非常沮丧, 但这比总是必须修复数据不一致问题和处理变通办法要少得多.

Wrapping Up

In the end, 集成项目是一个非常棒的项目, 有很多事情可能会出错. 由于一些原因，它在工程师中不太受欢迎, 但看到一项实施对坐在你旁边的人的工作效率产生了积极影响，这是值得的.

因此，对于工程师来说，通过提出以下具体问题，试着理解外部系统(如CRM或发票系统)的需求: 这个产品将如何使你的生活更轻松? 你考虑过竞争对手吗?? 为什么它们不起作用?

对于其他参与的人——让工程师尽早参与进来, 相信他们指出的红线, 当您看到集成的实现从长远来看会使它变得更加困难时，不要选择便宜的计划.