比來，我一直想整理一款互聯網消費金融平臺的產品的后臺及web設計分享。雖然之前前臺app（包孕安卓、ios）都是我設計的，但是后來還是主要做后臺及web。

設計產品的大體流程（因人而異）

1、了解業務流程（了解的對象也就是你的用戶）并整理出來大體的流程

前臺用戶操作層面只是整個產品的冰山一角，尤其對于to B產品來講后臺及商戶web乃是企之重器。接下來，我以本身在消費金融里面的產品經驗做一個后臺設計的分享。

首先我們要熟悉整個消費分期流程里面一套完整的流程，用戶注冊登錄后完善信息，提交訂單，審核結果，還款，逾期通知。商戶入駐、初審訂單（是否有權限）、查看用戶審核狀況、財務。后臺初審、復審、用戶辦理、商戶入駐審核、財務。以上都是比較簡單的講，再之后我們要考慮到我們對接的人有，用戶端、銀行或者消費金融公司、B端、財務結算。我們的用戶有商戶，內部運營人員（初審、復審、bd、老板）、財務、B端操作人員（老板還有員工等）。在之后我們需要把所有人員進行內部協同作戰，所謂最強也就是一個人對所有的流程節點都非常了解，也非常熟悉操作，這就是一個相當于流水線，當所有人步調一致時效率是最高的，我們如何來把控流水線的步調呢，那就是把所有角色溶于一個人身上，這樣整個產品的效率是最高的、而且各個流水線都需要有必然的數據進行衡量其品質。

產品泳道圖（簡版）

2. 繪制出主流程

各個產品中訂單和賬單是串聯整個系統的核心，訂單的狀態前臺全部、審核中、已通過、已打回、已取消、已拒絕、還款中、已完成。用戶下單的基本流程

用戶下單主流程

3、按照主流程，我們來繪制后臺的大體框架，而且創建后臺任務體系

后臺用戶的角色有

初審員：初審員主要的工作是審核圖片是否清晰，信息是否正確 ?便利審核，便利查找復審員：通過征信信息看是否給該人員放款、電話詢問查看情況 ?便利審核，便利查找運營人員：回答用戶問題，而且與商戶溝通回款情況商戶審核，商戶協調，商品上架審核

商戶端添加分支機構審核

初審QA：質量審核，跟進各個審核員的情況復審QA：質量審核，跟進各個審核員的情況

Bd:給商戶演示商戶后臺的操作以及訂單審核的大體流程，商品上架等。

我們在把基礎結構梳理出來包孕商戶的、商品和用戶。

用戶的基本信息整理出來

之后提交訂單時后臺需要對訂單進行處理，分配給各個初審、復審，而且需要提高審核效率。

所以后臺設計的時候需要有辦理系統的系統辦理、訂單辦理、用戶辦理、商戶辦理、賬單辦理、初審、復審、商戶辦理、商品辦理、數據統計、辦單員辦理、財務辦理、優惠券

由上述過程大體的流程已經出來，我們接下來整理大體的細節部分而且繪制一個人完成整個流程的流程圖，先做加法之后做減法。

4、一個人完成整個下單到審核流程的流程圖

中間你會充當很多的角色，但是這樣會對你整個系統的協調統一性有很大的作用。

一個人的流程（雖然孤獨，但是整個流程你更加清晰了）

接下來補齊其中缺乏的分支流程（為什么不在整個大的流程里補齊呢？因為直接補齊的話，整個系統的復雜度會讓你無所適從，拆分流程可以讓復雜度降低，我只拆分一個流程）

信審初審、復審走同一個分配訂單的流程即可，因為都相同嘛，分配訂單問題也適用于其他的有訂單的這樣的流程。（信審流程與主流程差別需要考慮到使用場景，例如工作時間、審核轉單等等）

審核時間為每天：9:00：00-20：30：00，周一到周五時所有人在線值班,周六到周天是只有部分人值班，而且需要考慮到特殊好比放假等，還可能出現轉單的情況、離職情況的考慮。每個信審人員分配的訂單量應該大體一致（打回再提交的訂單的分配）

考慮到上述情況我們現在開始設計排班，因為可能會有昨天20:30:00到第二天早上9點的訂單。我們有兩種策略，第一設置時間段值班的方式，即由信審負責人設置值班情況 ，第二種登錄分配模式 即你登錄即會分配? 第三種兩種結合。因為前兩種的漏洞會比較多，我們用第三種方式。可能以后審核還有機構限制，即相關信審人員只能審核相關的機構來的訂單，所以這些我們都需要事先留好框架。

信審訂單分配流程（適用于初審和復審）

還有其他的分支流程由于過多，暫時就不在文章中表現了。所有分支流程的設計都可根據信審邏輯進行規劃。

標簽：烏魯木齊 東營 林芝 鹽城 九江