同样的数据录两遍？怎么把现有系统连起来

重复录入，就是同一份信息靠人手再敲进第二个系统：新客户在 CRM 里建了一遍，到财务软件里再建一遍；完工的业务照着抄进发票；网上表单收到的内容，再一条条录进表格。每次只要几分钟，加起来每周就是好几个小时，而且每敲一次，都可能敲错一个数字。

更大的代价，是几份数据越走越不一样。有人在一个系统里改了客户的邮箱，另一个系统没改；发出去的发票用的还是上个月的数字；最后谁也说不清哪一份才是对的。

挑工具之前，先把所有靠人手抄数据的地方写下来。每一处都记下：

• 抄的是什么，具体到字段：名称、邮箱、ABN、金额、日期
• 从哪个系统抄到哪个系统，什么时候要抄，比如一笔交易成交了，或者一项业务完工了
• 谁在抄，多久抄一次，每次花多长时间
• 抄晚了或者抄错了，会出什么问题。

列完以后，通常能看出有几处最费时间、最容易出错，就从这几处做起。也有些暂时不值得自动化：每周就几条记录，录错了很快能发现，录进去以后很少再改。

也不是每一处抄录都发生在两个系统之间。如果信息是从邮件和 PDF 里读出来再录进去，那是另一类工作：可以让 AI 来读文件，再由人核对结果。如果抄录的一头是表格，更好的办法可能是把表格换成正式系统，而不是把它连起来。

最要紧的决定不是技术问题：每一种记录，都要定好原始数据放在哪个系统。常见的分法是：

• CRM 管联系人和销售机会，管到成交为止
• 运营平台或派单系统管工作本身：业务、阶段和任务
• 财务软件管发票和收款。

其他系统从它那里拿到自己需要的部分，要修改就回到源头去改。如果两边确实都有人改同一个字段，比如销售和财务都会更新客户电话，对接就要定一条规则：以哪一边的修改为准。没有这条规则，两个系统会一直互相覆盖。

每条连接的方向也在这一步定下来：一个系统只需要读，就做单向同步；两边都有人在用、在改，才做双向同步。

很多产品之间本来就能连。Xero 的应用商店 Xero App Store 里列着能和它连接的应用，HubSpot 也有自己的 HubSpot Marketplace。动手开发之前，先看看你的两个产品之间有没有现成的连接，再拿前面那份清单去试：

• 需要的字段能不能都同步过去，包括你自己加的自定义字段
• 方向对不对，时机对不对：是成交那一刻就同步，还是每晚才跑一次
• 两个系统里原本都有的记录，它怎么认成同一条
• 同步失败的时候，谁会知道，怎么知道。

这几条都过关，就用它。厂商自己维护的连接，你就少操心一样东西。

API 是一个系统公开出来、让别的系统读写它数据的接口。比如 Xero 的 Accounting API（在新标签页打开） 可以让应用读取、新增和更新联系人；HubSpot 也在文档里写明，它的联系人 API（在新标签页打开） 可以用来在 HubSpot 和其他系统之间同步联系人数据。

下面这些情况，就值得直接对接：

• 没有现成的连接，行业软件和企业自己开发的系统常常是这样
• 有现成的连接，但缺了要用的字段，或者同步的时机不对
• 什么时候同步什么，要按你自己的规则，比如业务审批通过以后才开发票
• 一件事要按顺序更新三个以上的系统
• 每次同步都要留下记录，失败了要告警。

接下来四节，讲这样的对接必须做对的几件事。拿它们来检查现成的连接器，也一样适用。

名称会改，写法也常常不一样，按名称匹配的对接迟早会造出重复的记录。Xero 的开发者文档建议用它的 ContactID 来识别联系人（在新标签页打开），而不要依赖联系人名称；它还专门有一个 ContactNumber 字段，用来存放其他系统（比如 CRM）给同一个客户的编号。在 HubSpot 里，邮箱地址是避免联系人重复的主要标识（在新标签页打开），企业也可以加一个自己的唯一编号属性，比如客户编号。

所以，对接在另一边新建记录时，要把那条记录的 ID 存到自己这边，以后每次都按 ID 去找。两边原本就有的记录，开始时要先匹配一遍，对不上的由人逐条核对。

每个 API 都会限制调用的速度。Xero 允许一个应用对每个已连接的组织每分钟调用 60 次（在新标签页打开），每天还有总量上限。HubSpot 按每 10 秒和每天分别计数（在新标签页打开），上限取决于账号的订阅级别：在 Free 或 Starter 账号上，私有分发的应用每 10 秒最多发 100 个请求，同一个账号里的所有应用共用一个每日上限。超过上限，两边返回的都是错误，而不是数据。

两家也都建议批量发送记录；Xero 还建议，数据量大的读取任务按计划或排队来跑，不要指望马上返回结果。这样做出来的对接，系统让它等就等，等完接着跑，而不是在月底数据量最大的时候把更新丢掉。

对接不一定要每隔几分钟去问一次对方有没有变化，也可以等对方来通知。比如联系人或发票新建、修改时，Xero 都能发出通知（在新标签页打开）。如果接收的一端没有正常响应，Xero 会持续重试 24 小时，之后停用这项通知，并发邮件告诉这个应用的开发者；这段时间里发生的事件最多保留 31 天，修好以后按顺序补发。Xero 的文档也要求，应用要能应付同一条消息被重复送达。

由此要养成两个习惯：一是记下哪些消息已经处理过，同一条消息再来，也不会再改动任何东西；二是定期核对一遍，把漏掉的补上，中断过的部分也能追回来。

只给它需要的权限。企业把一个应用连到 Xero 时，Xero 会列出这个应用要访问哪些数据（在新标签页打开），文档也要求开发者只申请最少的权限。一个只需要读发票的对接，就只给它发票的只读权限。

每次运行都留记录：同步了什么、跳过了什么、为什么跳过。一旦失败，要送到能处理的人手里，写清楚细节，赶在客户发现少了一张发票之前。

先在测试账号或数据副本上试，不要直接拿正式数据试，还要专门试那些麻烦的情况：一个客户有两个邮箱，发票发出以后又被修改，已经成交的交易又被重新打开。

从清单里挑最费时间或最常出错的那一处，先把它连起来，跑完一个完整的周期，比如一个月的开票。然后看记录：同步了多少条，失败了多少条，为什么失败。看清楚了，再连下一处。一次全部连上，出了问题很难分清是哪一段造成的。

同时告诉团队，现在每种数据以哪个系统为准，并定一个日期停止手工抄录。不然总有人会“以防万一”再录一遍，重复的记录又回来了。

Vetrox 是一家澳洲 IT 公司，帮企业把已经在用的系统连起来。从 Lark（飞书国际版）到 Microsoft 365、Google Workspace、Xero、HubSpot、Stripe，再到电子签名服务和共享网盘，每个集成都直接对接各个系统自己的 API，需要双向同步的地方就双向同步。中间不多一个第三方服务经手你的数据；每次同步都有记录，一旦失败会发出告警，不会悄悄漏掉。如果现成的连接器已经够用，第一次通话我们就会直说。