业务系统如何对接第三方服务？

在产品工作中，我们时常要对接第三方服务。本文作者从过往的对接项目经历中，提炼的关于业务系统，如何对接第三方服务的方法论，希望能对你有所帮助。

随着公司业务的发展，我们有时**遇到，需要在自身业务系统中加入新服务，但不能纯自主开发的情况。

比如**有以下三种：

1. 没有资质：有些业务需要有相应的行业资质才能开展，如第三方支付业务，就要求有支付牌照才具有研发资质；
2. 能力不足：相比头部互联网公司，中小型公司的自研能力相对不强，难以实现需求。如人脸识别，就需要基于AI的识别算法提取人脸特征，没有一定的技术积累则可能无法实现；
3. 能做但投入产出比不高：要投入大量的资源和精力，且开发难度大，周期长，很容易得不偿失。如搭建客服系统，光是保证消息的收发稳定，都要不短的开发周期，更别说智能分配客服和智能机器人这样的高级功能了。

而这时如果恰好市面上有成熟的解决方案，我们便可以把专业的活，交给有一定资质且专业的人，接入他们的能力来解决自己的问题。

比如，我们要在电商系统中，接入物流轨迹查询的能力，自研的话，需要对接多家物流公司的单号系统，费时费力还可能对接不成功。此时若有第三方服务商，已经整合了多家物流公司的物流轨迹查询，我们便可以直接通过与其进行对接合作，来实现自己的物流查询功能。

通过接入合适的第三方服务，既不用让公司在新领域自研试错，投入过高的开发成本，又能缩短开发周期，让我们的业务产品快速获得更加专业稳定的服务，变得更加成熟、强大。

以上对公司的好处我们了解了，但了解并接入三方服务，这工作对产品经理来说往往不是件易事。

做产品没有标准答案，我们做的每一个产品方案，都是在一个特别具体的环境下产生的。每一次都是定制，对接第三方更为如此。既要快速了解另一个领域的基本知识和行业产品，又要结合选定的第三方服务与公司新提出的业务需求，设计出一期最适合的产品方案，每一次都像是在摸着石头过河，有着说不上来的困难。

在对过往的多个对接项目经历，进行反思后，我将整个对接过程划分为三个阶段，并试图提炼出各个阶段应遵循的共性要点，让我们在对接时能够有章可依，降低事情难度，希望能对你有所帮助。

阶段一：设计前

产品经理在进行具体的方案设计之前，应做哪些事情呢？

1. 对自身业务系统有整体的理解

只有对我们的业务系统，先有全局的理解和把握，才能在知晓业务需求和三方的解决方案后，剖析出要改动的所有部位，做到纤悉无遗。

如若不然，对自身系统结构和业务都还一知半解，就贸然开始着手三方调研和方案设计，很容易因为前期考虑不全，而造成难以预见的危险后果。

举个例子，有一个后台管理系统，管理着线上商城和线下门店的零售业务，你要在整套系统中接入新的第三方聚合支付，逐步替换掉原有的三方支付服务。

若你对业务系统的了解还不足，就直接分析如何使用三方服务能力，并产出方案，推动项目上线。运气好的话，你可能只犯了点小错误。比如在前端商城中，对某个业务页面改了些字段，而后台的一个统计页面，你遗漏了对其进行同步更改，导致无法正常显示。这影响范围还较小，你还能在上线后进行及时补救。

但若严重的话，你的考虑不全，甚至可能**直接影响到系统关联业务的正常运行。比如，之前一直都是负责线上产品的迭代，在这次项目中，由于你没有去加强对线下业务的理解，导致在设计过程中，你直接疏忽了门店的重要设备——POS机，在里面软件的自建订单页面中，也需要更换新的支付方式。由于没有在这次项目中同步更改，将直接影响线下**卡、扫码等场景的业务的正常开展。

那么需要对业务系统了解到什么程度呢？我们可以通过对风险进行分类，然后倒推得出前期的准备。

可以跟我一样，将这些可能的风险，用二分法，简单划分为直接影响业务与间接影响业务。

直接影响，即影响业务的闭环运行。一旦没有兼顾到里面的任一环节，都**干扰到业务的正常进行。所以你需要做到，对该业务需求所涉及的主线业务流程，和其中的逻辑都有清晰的认识，哪怕对里面的任一个字段规则抱有疑问，你都应该剖根问底。分析其如若是个错误，是否应在这次项目中一同解决，避免其对新老业务产生影响。

间接影响，即不影响项目主流程正常进行的其他影响。如统计、设置等地方的关联改动，这种属于支线流程的需求最容易被我们忽略，但只有都顾及到，才能让方案更加完整。在开发评审时，我们的方案很少能一次通过，都**有或多或少的修改。你可以跟我一样，将在每次评审时所发现的，设计时被遗漏的功能或业务，都记在备忘录中，用于在后续每次设计方案产出后进行自查，以提高初次方案的完整度。

为了更好地降低风险，还可以邀请公司中对该业务熟悉的相关人员，来参与你的设计方案评审，一同检查是否有设计遗漏，多一道保险，避免自己顾此失彼。

2. 完成第三方产品的调研

我们在购物时，为了选到最心仪的商品，通常**货比三家。同样的，为实现业务需求而接入的第三方，将**在很长的时间内伴随着自身产品，这就更需要我们去仔细的筛选。

商品不喜欢，我们可以选择退货或者重新选购，但接入的三方服务不合适，即使我们去重新找新的服务商合作，却也已经在之前的对接过程中，让企业付出了成本，这是无法挽回的。

所以在具体对接前，我们应对三方服务商做仔细地调研与筛选。

这过程我划分为两个小阶段，调研初筛和名单提交。

1）调研初筛
刚开始去了解一个新的领域，你需要做的是，快速研究清楚里面的一些核心概念，然后尽可能多地收集行业产品的信息，并简要分析其服务能力与我们业务需求的匹配度如何。

而考察其服务能力，最为关键的点，无疑就是对我们基础需求的满足度，和其产品的拓展性了。

1.基础需求

基础需求，即本期要实现的业务需求能否满足，这一点还是相对容易判断的。

比如，你要在业务系统中，实现在线下单发货的功能。在订单发货时，通过接口传送面单信息后，接收物流公司返回的快递单号信息，并且能获取物流轨迹更新。

这种只需将核心需求梳理后，与其官网的业务描述进行比对，或者直接询问客服或销售，就可以快速知道能否实现。

2.产品拓展性

业务需求极少能一次性满足，往往**随着业务的发展而变化。所以仅考虑现阶段需求的满足，是不够的，你还需要进一步了解。这次为满足基础需求，所用到的三方产品和服务，能否满足未来定制化的需求。判断其拓展性如何，即二次开发的能力。

比如，在对新业务需求进行分析梳理后，我们通常**有多期项目规划。一期满足核心需求，后续就要考虑，如何实现重要但非一期优先的附加需求了。如果届时的迭代方案，需要对已经使用到的三方产品页面或者系统，进行调整设计，而对方并不支持对其二次开发或者改动难度大，周期长，那就需要更加慎重的考量了。

在平常工作中，我们也要不断去锻炼思考问题本质的能力，不让产品设计停留在表面，只能解决当前问题，而要考虑到是否能承接业务未来更多变化的需求。

2）名单提交
在初步调研后，你需要对初筛合格的三方服务商进行纵向研究，完成调研对比产出，并附上综合分析后的建议，给到对应的决策者进行选择。

其中的分析至少包括以下三个维度：

1.成本

在使用第三方服务时，往往**伴随着各种费用的产生，这也是公司最为关注的点之一，需要我们做仔细地调研。

常见的费用类型有：

• 服务费用：在使用服务商的某款产品或服务的过程中，产生的服务资费，一般按实际使用量或使用时长付费。如，调用人脸识别的次数，按次收费，使用即时通讯服务的期限，按每月固定的费用收取。
• 授权费用：我们所选择的服务，需要通过使用对方的SDK去对接时，就有可能要收取对应的费用，即该SDK在固定期限内的使用授权费。 不过也不是固定收取的，有时也**结合服务费用里的套餐包免费赠送，如**云直播购买特定流量包后，就**赠送一年的直播SDK使用权限。
• 对接费用：在初次对接对方产品时，需要一次性收取的接入费用。一般只在系统级的定制对接，即业务对接复杂度较高时，才有可能要支付这项费用。类似于平台接入银行的存管系统这种，才**收取对接费用。

每家服务商都有自己的收费模式，我们需要了解清楚后，结合自己的需求，去思考最适合公司现阶段的选项或组合。

2.风险

若是接入的三方服务不稳定，那么在上线后，对自身产品所带来的影响将是灾难级的。

服务不稳定带来的卡顿，或者数据错误与丢失等问题，将**直接影响用户对产品的体验和印象，甚至直接弃用产品。

所以稳定，便是对三方服务能力要求的重中之重了，但这也是我们在初次对接时，往往很难判断的一项。

如果直接问服务商其接口的稳定性如何，对方一定**说很稳定，因为没有人**想在初次合作时，暴露自身问题，让客户动摇导致合作失败。所以我们需要，多从其他途径去了解真实情况。

比如可以通过以下几个小点去评估和减小风险：

• 了解对方业务的沉淀程度：新业务代表着不成熟与高风险，业务的发展需要一定时间的摸爬滚打才能趋于完善。新业务的性能不足和异常流程处理机制的不完善，都**让我们在使用时具有极大的不确定性。所以业务沉淀越久越好，个人建议直接找头部的服务商，或者该业务至少开展了2年的服务商。
• 先接入支线业务：确定服务商后，最低风险的对接方法，就是先拿自身业务流程中的边缘业务去试手。在对三方服务能力不够确定的情况下，先不要对接核心业务。在熟悉对接流程与其服务能力后，再逐步进行核心业务的全面对接。比如，之前在对接某银行的聚合支付时，我们就先挑选了业务系统中的一个简单业务进行对接验证，即后台系统中的短信付费，有个扫码支付的场景，可以直接接入这项新支付方式进行测试。然后该支线业务的流程跑通后，我们再在所有的支付场景中，接入该聚合支付。
• 要有备选的服务商：项目上线后，才能验证当时方案的可行性和三方的服务能力。没上线前，我们也不能确信，初次合作的三方服务商，其服务能力能否很好实现业务要求。所以你需要在接入效果不好时，有可以紧急更换的选项，才能做到有备无患。

3.产品配套

初筛时我们所关注的是，要使用到的单个产品的拓展性，这里还需了解对应的产品配套如何，即思考其他的产品资源，能否为我们后期业务的发展而服务。

如接入视频直播服务时，关注美颜、转码、连麦聊天等配套功能，考虑在未来的发展中是否有可能应用上。这既能帮助我们在对未来的规划思考上，拓宽思维，又能进一步判断对方的服务能力和业务成熟度。

3. 初步方案

确定好对接哪家第三方后，我们需要给出初步的方案与服务商进行沟通，确认可以实现后，再进行具体的设计。

这就需要我们先了解，本次需求背后的核心问题是什么，通过识别业务核心，找到简单快速的解法，了解优先级和紧急程度后，给出自己的最小方案。并结合自身系统的简单介绍和业务背景说明，让服务商更好的判断自身产品或服务能否满足。

方案中为了更好的阐述需要实现的业务需求，可配合简要流程图进行说明，同时确认**在哪些环节用到什么接口。这一步因为涉及到双方系统的实现，我们需要邀请本司技术人员，共同参与前期的调研评审，探讨接入方式与可行性。

1）注意事项

1.关于第三方服务商

我们需要确定对方的业务对接人和技术对接人，以便在产生对接疑问时，可以快速找到负责人，沟通并解决问题。

在具体设计之前，一定要先通过电话或者**等方式，对话确认自身的业务需求能否满足，避免在开发人员进行对接的过程中，才发现无法很好实现，那么一切的努力都将成为白费。

进行业务方案的可行性确认前，你还可以先问下对方的典型案例和场景是什么样的，通过了解不同的业务需求，还能帮助你拓展思维，思考后期的需求。

在对接较为复杂，或者沟通不清楚时，可联系上门演示，缩短沟通周期。

2.关于业务定制方

这里说的业务定制方，指的是定制项目或SaaS软件的业务方。当帮他们实现新服务需求时，请务必提前了解并确定对方想要实现的业务范围，同时每次的沟通结果都做留档确认，避免在前期的业务需求确认上，出现不必要的异议。

阶段二：设计中

初步方案通过后，我们就要做具体的产品设计了，这里简单聊下，设计时应该注意的4个小点：

1. 接入第三方的业务流程梳理

为了避免复杂的开发，并降低沟通成本，可在流程图中注明与三方的接口动作，在哪些环节做什么判断。同时还有异常情况的处理方式，比如在对接第三方支付中，支付失败有哪些原因，拿到不同的结果该怎么处理，等等。

2. 新业务对原业务的影响

新服务接入到业务系统后，需确定并说明是否为默认开通，且不开通时，是否要对原业务做设计调整，和对旧数据进行处理。

3. 设计上对C端用户的无差异感知

如无必要，无需让用户直接感受到产品加入的第三方。

依旧以上述的三方支付项目为例，当时我们有个环节是，个人分销商要进行佣金提现，需要在成为分销商前，就在三方账户体系中进行账户新建，即**要求个人提前在前端产品进行认证签约。

此时，我们无需让用户在签约过程中，直接感知第三方的账户资料建立（签约协议中**有说明），只需在后台直接让三方的虚拟账户体系，映射平台账户，一一对应，用户无感，也减少认知负担。

4. 接口文档上的数据项是否有遗漏

接口文档的作用，就是让我们知道，在哪个环节需要提供哪些内容给对方，对方才可以有效的处理并返回给我们需要的结果。

比如在后台实现在线下单的功能，就只需要我们传给对方，收寄件人的姓名手机和地址信息即可，然后对方再返回快递单号。

仔细看接口文档，除了避免遗漏必填项外，还要留意各个环节的选填项是否要在本次设计中加入。比如，在后台在线下单时，可考虑是否让用户可以选择通知快递员上门揽件。

5. 注意事项

在完全实现业务需求之前，我们往往先采取最小可行性方案，即先跑通核心业务为主。在第一次对接时，最好逻辑不要过于复杂，如果开发评审后，评估的研发周期较长，你就需要反思下，自己是不是一次性做的需求太多了。

同时，完整的设计方案产出后，在进行开发之前，还应与业务方再次沟通，并输出最终业务流程图进行确认。

阶段三：上线后

测试完成，上线之后，我们还要做两件事：

1. 风控与三方能力评估

上线后对三方服务的风控依旧不能松懈，由于第三方是我们无法把控的部分，因此我们不能确定上线后是否**出现什么问题，所以在必要时，要能做到即时关闭该服务。

同时，还需要在运行一段时间后，对三方的稳定性和拓展性两方面进行评估，若没达到要求，则需要考虑后期是否更换服务商。

2. 项目复**

项目复**，即反思从项目开始到正式上线，自己做了什么事情，产品方案的落地效果如何，对已达成的结果和预期成果之间所产生偏差进行评估，是否优于预期，有做错了什么。通过在反思中获得进步，进而提高自身的生产效率。

特别是，我们做的产品方案，在评审时如果不是一次过，更要多反思那时修改了什么，在哪方面思考不足，并检查是否有遗漏的异常流，对其他模块的影响是否有照顾到，将在复**过程中发现的待完善内容，列入到接下来的迭代规划当中。

结语

每次对接新的第三方类型时，我们经常**像面对一个全新的困难一样，充满着太多的未知，容易一头雾水。

但作为一个研究型的职业，产品就是这样经常要做探索。既然选择了产品这条路，便只能风雨兼程，让我们知难而不畏难，在一个又一个的项目中，继续不断深入思考、磨炼自己。

本文由 @陈星 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。