B端产品经理接到客户需求时，可能会踩哪些坑
作为一名刚入门的支付产品经理，面对B端客户的需求，需要产出对应的解决方案并确保顺利上线，在这个过程中可能会踩哪些坑又应当如何绕开这些坑呢？
一、得不到完整准确的需求
对于2B支付业务的产品经理，除了开发测试同事，最经常沟通的应该就是公司内的销售了，有时还需直接和客户对话。
在这个两个过程中，可能会遇到下面的问题：
1. 销售传达的客户需求不明确
销售向产品经理传达的客户需求不明确，一般体现在业务场景、功能需求、特殊要求这三个部分上。
业务场景不明确会影响我们制定方案时对现有产品的选择与组合；功能需求不明确，我们就无法判断是否需要对现有产品做改造；客户的特殊要求将会影响我们采取哪种产品方案。
所以在销售向我们传达客户需求时，要着重关注客户的业务场景、功能需求和特殊要求。若存在不明确的部分，应当要求销售和客户确认后，再次与我们沟通。另外，产品经理可以参与到与客户的交流中，全面了解客户的需求，便于接下来的工作。
2. 与客户间的理解偏差
产品经理在和客户相关人员沟通需求时，由于双方职业属性的差异，又或是由于缺乏与对方的沟通经验，会沿用各自行业内通用的词汇或表达方式，这就会导致双方理解偏差的出现。
理解偏差会导致客户对功能的预期与产品方案最终实现的效果不一致，最终引起返工。
为了尽可能避免在沟通中出现理解偏差，可以邀请中间方参与沟通。比如客户内部的开发团队和对接客户的销售，他们的参与可以在一定程度上帮助双方理解对方的话语。
若是没有中间方可以参与沟通，则需要产品经理站在客户的角度与对方进行对话。
另外，在平常的工作中，我们也应该多积累与客户的沟通经验，或者多和销售同事交流来熟悉与客户的对话方式，尽量减少在沟通中产生的理解偏差。
二、把客户需求定位为产品方案
1. 直接从需求推导出的产品方案极有可能不合规
刚入门的支付产品经理有一个常犯的错误：就是习惯从需求直接推导出产品方案，
这样的产品方案有两个特点，
- 根据需求点对应到产品，再将产品进行简单的组合；
- 无法帮助支付公司规避客户需求可能会给我们的业务带来的监管风险。
当我们拿着这样的产品方案向合规部门报备的时候，很可能会被判定为不合规，那就不得不把方案推翻重新设计。另外，合规部门可能还会要求我们在方案中设计相关功能，要求客户向我们提供资料或异步传输信息来为我们自身规避监管风险。
所以当我们经验不足时，在产品方案设计完成后，可以将方案合规评审前置；需求评审后置，避免工作量的浪费。
在平时的工作中也要加强监管政策的学习，补充这方面的知识，在设计产品方案时自己就可以进行合规性的预判。
2. 产品业务逻辑比需求逻辑更复杂
大多数需求的实现，都不是简单的业务逻辑就可以支撑的。
需求逻辑是在描述某个场景下通过某个功能来实现特定的效果；而业务逻辑则涵盖了业务场景、底层基础产品调用逻辑、清算记账相关逻辑、逆向流程逻辑、失败流程处理机制、对线上产品的影响范围等部分，各个部分还需要前后贯通。
若简单地将业务逻辑等同于需求逻辑，则会导致产品方案出现漏洞，在后续的开发过程中不断填补漏洞，耽误工期。更严重一点，还会因为一些改动而影响线上产品。
所以当我们接到需求时，上述业务逻辑的部分都需要纳入我们的思考范围。有些细节对我们的业务能力要求比较高，可以多向开发和测试同事寻求帮助，一同寻找解决方案。
三、只关心正向流程
从支付产品大的分类上看，无非是收单和代付两类。
对于发展代付业务的客户，几乎不会出现退款的场景。而对于发展收单业务的客户，从客户的业务发展角度看，他们更关心把钱收进来的过程。
从支付公司的销售来说，先把客户接进来，客户有了走量即可；后面有什么特殊情况销售，可以再进行沟通处理。
客户和销售对逆向流程不那么关心是可以理解的，但是产品经理在需求沟通和方案确定的过程中，应该避免出现这样的问题。
1. 逆向流程与正向流程是对等的
正向流程是满足客户正向交易目的的流程，逆向流程是在正向流程完成的前提下， 对交易结果的逆向操作。
虽说逆向流程并不会在每次交易中出现，但它和正向流程 一样，是完整的交易场景中必须包含的两部分。在支付业务中，逆向流程通常指收单后的退款流程。
如果在设计产品方案的时候忽略了对逆向流程的设计，对客户来说，常规的逆向流程可能在复杂交易场景下并不适用；对第三方支付公司来说，后续为了满足客户在复杂场景下的退款需求，会需要进行人工调账。这是非常复杂的清算对账工作，人工维护成本很高。
举个例子，受疫情影响，近几个月各个旅游平台的退款率相较去年同期异常高。旅游平台作为平台商户，收单交易往往涉及多个分账方。例如机票购买的交易场景中，分账方至少是旅游平台、机票出售方、保险公司三方。若是用户的退款流程出现问题，受干扰的不止旅游平台一方。
当然，各家支付公司肯定都已经有非常严密的退款逻辑了，但是客户的需求是千变万化的，逆向流程要提前和客户确认，并且需要和相关的开发同事一起制定逆向流程方案。
2. 对账的需求根据交易场景千差万别
客户的对账需求基本体现在对账文件的功能需求，大致包含三类内容：
- 对账文件的获取方式；
- 对账文件包含的内容；
- 交易中各方的定制化需求。
对账文件的获取方式可以分为三种，
- 通过接口；
- 通过 FTP/SFTP 传输；
- 客户通过客户管理系统自行下载。
交易场景虽然并不能直接决定客户对于对账文件的获取方式，但是可以从侧面帮我们推测商户更倾向于通过哪种方式获得。比如对于交易场景比较复杂的客户，往往具有开发团队进行技术支持，他们更倾向于通过接口的途径获得。
对账文件中包含的内容会受交易场景直接影响，对账文件中各个字段以及每一行记录，需要能够还原出完整的交易资金流向。简单的收单或退款交易，可能只需要对 账文件中包含基础交易字段。但是对于有分账方参与的交易，对账文件中需增加特殊字段来还原交易。
还是举上文旅游平台的例子，旅游平台作为平台商户，收单交易涉及多个分账方，那么我们给旅游平台生成的对账文件中，每条记录中不仅要展示交易发起方产生的数据记录，还要根据实际的资金流向，来记录其他交易参与方对应的记录。
复杂的交易场景中，参与交易的各方原则上都是支付公司的入网客户，那么一旦有其参与的交易发生，我们就需要向其提供对账文件。
交易发起方和交易参与方虽会共享同一笔交易订单，但由于角色不同，在对账时，需要看到的或是能够看到的交易记录对应的具体字段也会不同。比如，一笔交易中可能包含多个分账方，每个分账方只能看到交易记录中与自己相关的字段的值。
若是在与客户沟通需求或在制定产品方案时，不询问客户具体的对账需求，可能会导致客户对接了支付产品并且开始走量之后，发现对账文件中的字段不满足其对账需求；从而引发该客户交易量的下降。
所以不论在与客户沟通需求或在制定产品方案时，都应当提前和客户沟通对账需求，或根据客户的交易场景提供对账文件模板给其提前确认；避免在线上运行时出现问题从而直接影响交易量。
四、忽略商户的潜在产品需求
客户能提出新的需求对第三方支付公司来说是好事——这意味着客户对我们很信任，后续可能会切更多交易量到我们的平台上。
客户的潜在需求会出现在交易的各个环节，对于支付公司来说，将商户需求转化到产品方案上之后。
大致可分为两类：
- 已对接功能的升级；
- 开发全新的功能。
比如，在使用APP中钱包余额支付停车费的场景下，支付订单几乎都是小额订单，客户在刚接入时只需要对接移动支付的相关产品；但是线上运行一段时间之后，很有可能由于用 户反馈而要求支付公司提供小额免密支付的功能。
对现有功能的升级，由于在最开始做相关功能的时候，没有从产品角度考虑，要求开发人员预留出足够大的修改空间；那么功能升级可能会对开发测试的工作量会产生比较大的影响。
比如开发可能需要针对某种优化对相关业务逻辑进行重构。即便是开发新的功能，也可能会因为新功能与交易环节中其他功能的出现冲突而难以实现，从而延长工期。那么客户就有可能将交易量向其他第三方支付平台切。
其实，当产品经理在规划产品功能时，可以多把自己放在实际交易场景中的用户角色上。去思考哪些支付功能是非常合理的而客户并没有提出的，尽量挖出客户的潜在需求；虽说这些潜在需求可能在当前不会作为一项开发内容，但是可以帮助开发同事选择功能实现逻辑、为未来的功能优化预留空间。
五、忽略商户测试需求
1. 产品测试方式需要提前沟通确定
大多数支付产品的测试都是在生产环境通过对真实交易的验证进行的。但是也遇到过有一些客户希望对接商测环境进行上线前预测试。如果不提前确定客户的测试需求，会影响我们提前准备测试环境等测试条件。
为了保证测试的顺利进行，还是要提前和客户对测试方式进行沟通，确定测试方案，必要时也可以由测试工程师向客户提出测试建议。
2. 特殊测试方式的可行性受渠道影响
在微信支付宝发生的支付交易比较特殊。除了主扫被扫，比较常见的微信公众号、小程序支付、支付宝的生活号、小程序支付。
在测试前需要提前准备好可供测试的公众号、小程序等，必要时可要求对接客户提供，以免耽误上线进度。
作者：今天吃洋葱；公众号：今天吃洋葱
本文作者 @今天吃洋葱
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
