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. 扯回退款主流程，用戶發起退款申請后，又有個和場景相關的問題，誰來主動打電話呢？按照普通的流程來，用戶發起請求，最后的請求終點應該在商家上，即商家確認退款申請。那么這個電話撥打方一般是在用戶這里了。

不過這里的一個設計重點其實不在于流程，而是在于：平臺應側重于誰？用戶還是商家呢？這個估計就涉及到平臺的生命線了：在當前階段平臺已經走到了哪一步？不同階段有不同的側重點才是應該的。

之后再改改，先吃飯