大家好，今天我们来聊一聊客诉和销售退货。

客诉指的是客户对产品质量的投诉，一般来说，客诉的果，就是销售退货，而销售退货的因，是客户投诉，这两个是有关联的。所以我们在流程设计上，需要把这两者结合起来考虑。

销售交货出去后，通常有三种情况，需要把已经发出的货，再回到库存中。

第一种是做出货的人做错了，本来不应该发出的货，把它发出去了，需要再回来。这种人为失误，在SAP以前的版本中，需要做销售退货，把产品再退回到库存中。在现在的版本中，不需要再退货了，直接可以把做的销售交货单取消就可以了。

当然SAP在取消交货单的时候，会产生一张新的，叫交货抵消单的单据，把库存再收回来。这个销售交货抵消单，可以理解为一张红冲的单据。

所以SAP在单据上的逻辑始终是很严谨的，交货单一旦生成，不可以更改，如果要取消，也是用一张新的单据，占据一个新的单据号来取消、红冲原来的单据。这张交货取消单，在库存数量、财务账上的影响，和退货单是一样的。

那么它和退货单有什么区别，SAP为什么在退货单之外，又要加一张交货取消单的单据呢？最大的区别，在于对流程的管控和报表统计两个方面。先说报表统计，以前要反向冲销人为错误的时候，只能用退货单，就会影响对真实的退货业务的统计分析。

比如老板说，我想看看去年一年，客户退货了多少金额，给企业造成了多大的损失。那么你就得有个机制把这种人为错误的单据、金额排除在外。以前惯常的做法，是在退货单上加一个退货类型的标记，但这个标记是依靠人来选择的，很不严谨。

现在有了取消单，就没有这个问题了，人为做错的单据用取消单来红冲，真正退货的，才用退货单来做，报表分析更严谨。

除了报表统计，流程的管控也更容易了，取消单不需要特别的管控，因为这个是人为错误，仓库做的单，仓库直接取消重做就好了，也不需要惊动别的部门再去重做订单。而退货，则是需要在流程上进行严格控制，例如我们后面会谈到的，必需要有质量部门的判定或者走客诉处理流程等等。

这里着重说一点，有些人喜欢去控制取消单，认为做好的单据，不应当随便取消，仓库要取消自己做的交货，还得走个流程、走个审批。

这种做法我觉得没什么必要。一般提出这种要求的，他的担心无非就是两点，第一点是担心仓库老是做错，想减少人为的错误，提高做单的准确性。

如果是这种担心，只需要统计一下取消单的数量、所占的百分比是多少，用来考核仓库做单的人员就可以了，没必要人为去增加流程复杂度，加上审批，让流程反应速度变慢。还有一种担心，是仓库做错了，偷偷再把单据取消，给别的部门不能及时传递正确的信息。

比如销售员都已经凭交货去和客户对账了，仓库再取消了交货单，可能对账的信息就是错误的等等。所以想要控制取消单，目的是为了通知一下别的部门。

如果是出于这种目的，那也会有更好的方案可以选择，是没必要禁止仓库取消单据，或者为取消单据增加一个审批流的。当然这个展开来内容就会比较多，和今天我们这一讲的主题没什么关系，有兴趣的话，我们以后可以专门开一讲来聊一聊这个话题。

总之，我的观点是：通常情况下，谁做的单据，谁就有权取消，除非被下一流程环节已经引用或者已经处理，否则他就可以直接取消。

前面我们讲到的是第一种情况，就是做单的人做错了，需要回到库存，这种情况下用取消单，而不是退货单。第二种情况需要回到库存，那就是因为质量问题，客户投诉，而引起了客户的退货，这种情况需要退回仓库。

如果是这种情况的退货，我们在流程上需要严格把控：销售退货必需要有客诉的记录，如果没有，是不能允许退货的。这个流程管控，在管理上的目的主要有两个。一是任何一次销售退货，都得走专门的客诉处理流程，需要质量部门牵头进行判定，确定退货确实是因为质量问题而发生的。

第二个目的，尤其重要，那就是因为质量问题退回来的货，不是说退了就退了，退了再补给客户另一批产品就好了，而是一旦遇到这种问题，必需要有人去分析，去查找问题倒底在哪儿，是原料批次问题？是加工工艺问题？还是运输存储问题？找出原因后，再根据不同的原因，让相关部门提出改善对策，确保下一次同样的问题，不会再发生。

如果这个流程没有严格把关，最容易导致的问题就是：要么销售在接到客户退货要求的时候，很随意，客户说退就退吧，至于会给公司造成多大的损失，他并不关心，只要自己的销售业绩达成、客户满意就可以了。

要么就是退货回来后，没有人处理，放在那边，迟迟不会有人去判定，也不会有人去提出后续的处理方案，是报废呢，还是返工，返工的话，用什么方案返，工艺上要做什么调整等等。时间长了还会 忘记，因为毕竟不是正常的业务，很容易被疏漏。

在处理客诉的流程上，SAP中有专门的售后服务模块。当发生客户投诉时，由客诉工程师，或者客服人员，将客户的投诉事由，详细登记在服务呼叫中，并分配给指定的责任人进行处理。SAP中，可以通过服务模块的一些报表，例如跟踪报表、监视报表等，实时跟进问题的处理进展情况、统计责任人的响应时间等等。

在处理的过程中，还可以根据客诉的内容，将问题进行分门别类，归集到不同的问题类型、问题细分的子类型等等，并创建相应的解决方案知识库，在SAP中记录每一次问题的解决方案、相关联的产品等信息，方便事后类似问题发生的时候，可以快速查找历史的解决方案等。

另外在处理客诉问题的过程中，可以记录相关的活动，比如几月几号，开了一次什么专题会议，会议的内容、摘要是什么，哪些部门参与，并达成了什么共识，部置了什么样的后续措施等，都可以统一放在这个服务档案中，甚至还能上传大家签到的会议签到表、会议记录等附件到SAP中，以及后续更多活动的关联等等。这样以后一打开，或者查找到客户当时的投诉，就可以一目了然所有的处理活动情况。

当然最后在客诉处理完成后，还可以根据确定的处置措施，在客诉处理的这个服务档案中，添加不同的单据关联。例如我们前面讲的，如果客诉处理的结果是允许销售退货，那么就可以关联相关的销售退货单。

除了销售退货单外，还能关联销售的其它单据，例如应收贷项、退货请求等。以及关联采购的相关单据，例如为了这次投诉，重新购进了新的产品来置换，或者新的材料来生产，所以下达了新的采购订单、采购收货、应付单据等。

又或者关联库存转储单，处理技术人员到客户现场维修，所带去的新的备用配件等等。对于SAP来说，这些是服务模块和营销单据的关联，对于顾问来说，我们考虑的是流程的有效性，所以我们需要关注的，是在SAP中添加控制，例如没有处理完成的客诉单，就不可以有销售退货单等等，也是通过检查这种关联来实现我们的设计目的。

所以大家可以看到，SAP的这个模块，是相当完备并且好用的。但是这个模块经常会被人忽视，我想原因可能有这么几条：一是现在企业里面对客诉的处理，往往有自己的一套处理方法和思路，例如用8D报告来处理客诉业务。

这种方案比较常见，各部门也很熟悉了，所以要切换成SAP的服务呼叫模块来处理，会有比较大的学习切换的成本，也会增加项目的复杂度。我们的项目中，也遇到过类似的问题，所以我们也会按客户习惯的做法，在SAP中配置8D报告的流程来处理。

毕竟这个流程并不是ERP的主要流程，只要殊途同归，能实现相同的管理目标就可以了。二是这个模块，很多顾问一直认为仅适合于那种有专门的客服团队，客服接到投诉，然后分配给后台进行处理的业务。

这个我觉得是被SAP这个模块的名字：服务呼叫所误导了。其实这个模块很强大，基本适合所有企业的售后客诉处理业务，也不一定就必需要强求有售后服务合同，也不会强求必需序列号管理等。大家可以不妨一试。

第三个原因，我觉得也是比较大的一个原因，就是这个模块的流程性不够强，导致它在实际应用中发挥的作用有限。一个客诉的处理，可能会要在很多相关部门去签核、去确认等，最后再根据处理的结果，还要做相应的后续处理，例如允许销售退回，退回后要安排生产返工，返工会产生额外的成本，耗用新的原料、耗用新的人工和制造费用，最后再交货给客户等等，而SAP的服务呼叫模块，基本就是一个登记的窗口，在一个界面，由指定的操作人员，把所有过程中的业务进行登记，本身没有流程性的概念。