近期加班加点，关键在赶工期解决售后服务系统软件退款和退货要求。依照企业业务场景，小Q小结了退款退货的开启情景关键分成两大类：
一、顾客网上进行申请办理，服务平台审核；
二、顾客联络在线客服，由在线客服委托从后台管理进行申请办理。
另外，因为公司业务另外存有直营服务平台和三方POP店家二种运营模式，及其线上支付和到付二种付款方式的订单，小Q小结并整理出总体业务场景宏伟蓝图：
▲ 退货退款情景列举
02 退货退款系统软件步骤详细说明
依据退货退款开启的机会不一样，小Q将退货退款步骤分成订单送货前、订单发货后、订单查收后3大连接点，独立设计方案系统软件步骤。
1.订单送货前的退货退款步骤
客户提交订单之后，在商品订单未出入库以前，客户并未取得商品产品，订单也还处在顺向履行合同步骤中，还不牵涉到逆向物流情景。在这里情景下进行的退货退款，在系统软件方面实际操作为：
一、撤销订单；二、退款。
依据订单所在的履行合同连接点，系统软件解决逻辑性再细分化为3个子连接点：
（1）订单未付款：专指到付订单已提交，和线上支付订单已提交预付款的情景。 这时因为并未付款，因此 只必须撤销订单就可以，不涉及到退款；
（2）订单已支付，但并未下达仓库/店家：这时订单仍在网易大数据订单履行合同系统软件中，商品尚在仓库没动。在系统软件方面的解决为：
①撤销订单；
②线上支付的订单，由系统软件或是人力转化成退款单，审核通过后将订单券后额度原路退还客户付款帐户（到付的订单预付款，不用退款）。
（3）订单已下达仓库：这时订单已造成波次开展送货生产制造了，因此 退款以前需保证 商品产品并未真正传出，将产品还货发布。为避免 系统信息运转全过程中存有滞后效应，故在撤销订单前，最好是核查一下仓库/店家商品的具体情况。在系统软件方面的解决为：
①试着撤销订单，若产品未发货，则可撤销取得成功。不然撤销不成功，退款不成功；
②仓库将已撤销订单阻拦并还货发布；
③线上支付订单，转化成退款单，审核通过后老路退款至客户付款帐户。
▲ 订单送货前的撤销及退款步骤
2.订单拒绝接收的退货退款步骤
订单送货之后，商品早已在运送中途，但客户并未查收，这时，若客户回绝查收，则造成了拒绝接收。到付的订单，拒绝接收时仍未收费标准，也不用退款。
系统软件解决逻辑性为：
（1）在线客服核查拒绝接收缘故，若客户还想再次要，则联络货运物流公司对包囊开展再投，一切正常查收订单。此全过程仍为订单顺向步骤，未涉及到售后服务步骤。
（2）若商议愿意退货，则由在线客服进行一个退货申请办理下达至仓库（直营业务流程）或是店家端（三方POP店家业务流程），等候包囊被货运物流送到之后，核查确定准确无误后，将线上支付订单原路退款，到付订单因并未收付款，不用退款。
这里必须表明的是，直营服务平台订单，一般在仓库实际操作WMS系统软件，退货进库情况可与上下游系统软件即时相通，故在仓库退货进库之后可全自动开启退款；而店家系统软件最好是由店家确立确定接到商品之后（多了一步店家确定的姿势），再开启退款。
服务平台退款之后，与店家开展清算订单应收款时要清除已退款订单。
▲ 订单拒绝接收退货及退款步骤
3.订单查收后的退货退款步骤
LifE54。zHIli123.cOM订单查收之后进行的退款，与查收前关键有二点不一样：
（1）到付订单这时已收付款，因此 牵涉到订单退款；
（2）查收前的退货全是整单层面，查收后可适用一部分退货。
系统软件解决步骤为：
（1）客户或在线客服进行退货申请办理；
（2）服务平台或店家审批退货申请办理，愿意后，客户将包囊寄到。若为直营服务平台订单，只必须服务平台审核通过就可以寄到包囊；若为店家订单，还需店家审批愿意。
（3）仓库/店家接到寄到包囊后，转化成退款单，依照承诺途径将借款退还管理员账户。正常情况下规定按原路返回，但一部分为现金结算的到付订单，或是其他状况，能够商议其他网上退还途径。
▲ 订单查收后的退货退款步骤
03 订单、退货单与退款单
因为1张订单很有可能会造成数次退货，每一次退货会转化成1张退货单。另外，1张订单也是有很有可能开启数次退款。因此 ，小Q将退货单、退款单独立设计方案，与订单库单独存有、紧密联系。
退货单和退款单是如何的关联呢？ 小Q调查完一圈出来发觉，并并不是每一张退货单都是会转化成退款单，更并不是每一张退款单都是会有退货单，如同并并不是每一滴牛乳都叫xx苏一样，哈哈哈~比如到付的订单退货，就总是有退货单，不用退款单；有一些状况下，在线客服会对于一些订单只求顾客退款，而不用退货，比如服务承诺请求超时赔偿等。因此 ，退货单和退款单仅有在基本退货退款情景下才算是一对一的关联，在特殊的情景下并不具有强关联方交易。
▲ 订单、退货单与退款单
依据退货单的实际操作情况，小Q将退货单设计方案为待审核、待进库、进库进行、驳回申诉 4个情况：
①待审核：在订单反向全过程中，顾客或在线客服新进行退货申请办理，系统生成退货单的最初的状态；
②待进库：退货单审核通过，愿意退货的情况。这时，等候顾客包囊寄到；
③进库进行：包囊寄到库房，仓库顺利完成进库；
④驳回申诉：退货申请办理被驳回申诉的情况。
▲ 退货单状态图
LifE54。zHIli123.cOM依照退款连接点，退款单的情况设计方案为待审核、待退款、退款进行、驳回申诉 4个情况：
①待审核：退款申请办理刚递交的最初的状态；
②待退款：退款单由会计审核通过，愿意退款；
③退款进行：由会计手工制作或系统软件全自动开启退款，退款取得成功后的情况；
④驳回申诉：退款申请办理被驳回申诉的情况。
▲ 退款单状态图
04 退款额度测算
订单查收前的撤销和拒绝接收造成的退款，全是整单退货（全退）。而查收之后的退货，常常因为一部分产品难题，因此 会存有一部分退货（半退）。假如在订单提交订单时应用了优惠劵、抵税金、積分等，也必须考虑到退还管理员账户。
全退状况的退款解决非常简单，小Q得出的解决方法为：①按订单券后总额退款；②未到期的优惠劵、積分等优惠促销原路返回。
半退状况下的退款解决相对性繁杂，小Q向阿辉、老A等电子商务各位朋友逐一求教和探讨后，小结以下：
①如果没有组成优惠促销，按产品券后额度退款；
②若应用了组成优惠促销（如整单满减券），有二种流行处理方法：
a.特惠依照产品额度占比平摊，依照平摊后的券后额度退款；
b.退款时要考虑到剩下产品是不是达到特惠，重算特惠后退款。
为提升了解，举例子：
a.特惠依照产品额度占比平摊，依照平摊后的券后额度退款。(参照：淘宝网)
举例说明：某客户购买商品A\B\C各一个，应用了满150减20的优惠劵，按占比平摊后的券后额度以下:
如上，若退A，则退款90元；退B，则退款54元；退C，则退款46元。
此标准简易易完成，但存有凑强杀优惠劵的风险性。存有客户为了更好地凑单应用优惠劵，查收后又将其他不用的SKU退货的状况。一般避开计划方案为：①客户义务造成的退货运输费由客户担负；②故意刷优惠劵退货的个人行为，将客户做退级解决、或列入黑名单。
b.退款时再次测算特惠，若剩下SKU再次达到特惠，则按售价退款；不然扣减特惠后再退款，若扣退款额度尚不足特惠，则不可以独立退此产品。参照：京东商城
举例说明1：某客户购买商品A\B\C各一个，应用了满150减20的优惠劵，券后额度以下：
①若退C，则剩下A和B，原额度累计160，依然达到优惠政策，故退款40元；
②若退B，则剩下A和C，原额度累计140，不会再达到优惠政策，需扣减特惠，故退款额度=60–20=40元。
LifE54。zHIli123.cOM举例说明2：某客户购买商品A\B各一个，应用了满100减50的优惠劵，券后额度以下：
①若退A，剩下B（原额度为40），不会再达到优惠政策，需扣减特惠，可退款额度=60-50=十元
②若退B，则剩下A（原额度为60），不会再达到优惠政策，需扣减特惠，但是因为B的原额度（40）低于已特惠额度（50），故不允许独立退B。
此标准可防止刷优惠劵的状况，但标准较繁杂，表述成本费和系统软件完成成本费很大。
之上二种计划方案，小Q更趋向于计划方案a。由于在医疗行业，药物一经卖出，正常情况下没退不更换，因此 原本退货便是个低概率事件，再加上服药的独特性，为了更好地套优惠劵而凑单再退货的几率就更低了。控制系统设计时也遵照道法自然标准，服务平台在派发营销特惠时，只需确保总体上成本费能cover住，系统软件也就不用设计方案的过度繁杂了。
针对以新项目驱动器的加班加点，小Q从来不抵触。新项目赶工期期内，为了更好地在方案時间内有成效产出率，一次次同意加班加点，赶最后一班地铁站进家后再次挑灯夜读；也以前持续迎战24小时，到宾馆短暂性歇息后又主动赶赴新项目当场，总是担忧新发布新项目有一定的闪失；更有持续一个月迎战到凌晨三点，只求在他人下班了期内空出時间重装系统联调。这些日子很苦，但追忆起來全是甜，凡心所向，自驱而动，无怨也无怨无悔。
当996的分歧在互联网上升級到ICU高宽比的情况下，早已变成公司和职工中间的阶级斗争，正反方各持己见、寸步不让。针对996，小Q有自身的了解，对比从上向下传递的现行政策和由上而下解决的防范措施，小Q更为尊崇更有意义的自驱式价值观念，而不期待规章制度沦落一种自取其辱惺惺作态式的公司与职工博奕的戏楼。
纵览历史时间，一切以反人性为立足点的规章制度全是阻拦历史时间向前的拦路虎，终究会被历史时间所取代。9也罢，6也好，上班时间本应仅仅个人价值完成的一条纪录，凌晨4点的街边都不应当变成微信朋友圈显摆的资产。自然，使用价值的反映因人有所不同的，有些人为了更好地名，有些人为了更好地利，有些人为了更好地提升自己，也有些人为了更好地自我价值。最理想化的作法是公司掌握每名职工需求，给与她们要想的，激起每一个激发潜能，持续提高职工办事的高效率和资金投入度。
LifE54。zHIli123.cOM版权声明：文中內容由互联网技术客户自发性奉献，通篇见解仅代表创作者自己。本网站仅出示信息内容储存空间服务项目，不有着使用权，不担负有关法律依据。如发觉本网站有因涉嫌剽窃侵权行为/违反规定违反规定的內容， 请发邮件 检举，一经查证，本网站将马上删掉。
