每天一个问题解决功能设计（1）

v1.0 打算做个记录 每天将生活中遇见的app中存在的各种边界情况记录一下 就当同时尝试一些新功能的设计，是以记

day1

app名称 回家吃饭 相关功能 用户退款

1.大致描述。 首先明确的是，在什么情况下需要进行这样一种退款操作呢？从订单流程上来看，前置状态为用户已支付状态，同时在用户端上看，只能对已支付且未完成下的订单进行退款申请。

在进入退款申请页面后，给出的信息提示是及时联系商家；同时需填写具体的申请理由；并且返还金额的方式目前认定为原路径。那么这里涉及的功能大致就可以着手设计了：1.需要对应的账户余额系统对于还款金额进行支持，而相应的功能推导上，商家方一定具备一个提现功能。那么这样来看，未提现的金额实际上都还是存储在平台上。关联的功能模块是优惠券的使用，对于使用了优惠券的订单应按照具体的约定条款折扣退款返还，而优惠券是否返还？优惠券返还又牵涉到的是优惠券的使用期限问题，是按照原优惠券的使用日期返还还是按照新的有效期限返还？这个地方就牵涉到，如果按照原日期，按照官方3-10日的退款时间，优惠券很有可能已经失效，那么如果返还优惠券的前提成立，很可能是返还一张全新的。当然这也是对于用户友好的一个体现。

2.优惠券及返还款细节。相关的退款申请审核，平台的后台操作上一定涉及到退款申请审核，这里可能涉及的是商家实收金额是按照订单总额计算还是订单实付金额计算？比如订单总价30，用户使用5元优惠券，实际支付25元，那么商家实收金额应为25还是30呢？作为一个平台的初期阶段，给予商家的应该是按照30元计算，那么当退款发生时，商家首先支付到平台的应为30元，而平台方这时候具有的是30元现金，而最初用户支付的则是25元加5元优惠券。这个地方如果反推下可能会很有意思：如果便利于商家，为了拓展商家，那么此时应让商家仅归还25元，5元直接补贴商家；而返还用户的则是25元现金加上5元优惠券。（这里可能涉及到套现风险，不过需要运营风控具体审核case了）

3. 扯回退款主流程，用户发起退款申请后，又有个和场景相关的问题，谁来主动打电话呢？按照普通的流程来，用户发起请求，最后的请求终点应该在商家上，即商家确认退款申请。那么这个电话拨打方一般是在用户这里了。

不过这里的一个设计重点其实不在于流程，而是在于：平台应侧重于谁？用户还是商家呢？这个估计就涉及到平台的生命线了：在当前阶段平台已经走到了哪一步？不同阶段有不同的侧重点才是应该的。

之后再改改，先吃饭