談及賬號及權限的問題，更多人一開始會直接想到的是登錄注冊的交互體驗及安全性，但對于B2B電商平臺來說，會遇到更多的場景，對于功能的要求也比較重視。本文主要從B2B電商的角度，講述賬號及權限設計的問題，以及我所踩過的那些坑。

一、賬號體系

B2B電商平臺的交易角色由采購商，供應商和平臺三方構成。

在項目初期，由于產品未參與數據庫設計的過程，所以數據庫設計者更多的是憑借已知的需求及經驗進行數據庫的設計，采購商的賬號方面主要是由兩個表組成：賬號表和采購商信息表；賬號與采購商信息之間的關系為1：n的關系。

但是隨著項目的上線及推廣，該套賬號體系被證明不能滿足業務部門的需求。在我們原來的認知中，一個采購商（即一個企業）作為一個購買單位，如果有多個人負責采購的情況下，多個賬號共享一個采購商的信息即可。但是后來我們的采購商出現的連鎖店，而且連鎖店處于采購成本和管理的因素，更多的是由專門的采購人員或老板進行統一的采購，因此賬號與采購商的關系變成了n：n的關系

因此衍生出如下幾個問題：

1. 數據庫的設計

根據需求一個采購商可能會存在多個采購人員，同一個采購可能需要同時負責多家店的采購，因而賬號和采購商的關系變為多對多的關系；

實際上由于前期設計錯誤，導致重新進行數據庫的設計不再可能，只能基于之前的數據結構進行修改，這里我們將原來的一對多關系的兩個表整體看做一個采購商表，新增一個賬號表和一個關系表即可完成設計

另外，其他業務模塊對于賬號/采購商的引用需要進行重新的檢查，在業務邏輯上，一個采購實體的性質是采購商而不是賬號。所以和采購業務相關的業務模塊如：訂單、優惠券、文章消息、購物車商品等均與采購商id關聯，而與賬號相關的業務需要與賬號Id關聯（與新的賬號表中的id關聯），如：昵稱、登錄賬號、密碼等。

2. 業務流程設計

由于多個賬號共用一個采購商，在有員工離職或其他情況下，必須對于采購商的某個賬號進行關系的解綁，所以必須有一個賬號能夠管理該企業的其他賬號。所以對于直接創建新企業的賬號，將這個賬號賦予一定的權限，將其定義為管理員賬號。

對于非管理員賬號，可以由管理員賬號直接添加，這樣可以省去注冊的麻煩也可用于批量注冊賬號。同時業務設計中也需要考慮登錄同一個賬號后，在多個采購商之間進行切換使用的問題。

（1）新增賬號并綁定企業

注冊新賬號之后，可以直接繼續創建新的企業，創建新企業后，該賬號將自動成為企業的管理員。同時也可直接進入頁面瀏覽之后，再創建新的企業。另外，也可直接由企業管理員添加進入該企業（有點類似于社交中群成員和群主的概念）。

（2）老賬號綁定企業

已注冊的賬號，可以選擇創建新企業或由管理員添加進入已存在的企業。

經驗教訓總結：在需求的初期，一定得做好需求的邏輯模型的設計，梳理其中的角色（實體），屬性及實體之間的關系，以供數據庫設計人員進行物理模型的設計，否則在后期會花費更多的成本進行修改。

二、權限設計

現在市面上大多數電商網站對于權限的設計已日趨完善，尤其是在商品瀏覽方面，登錄與不登錄沒有什么區別，甚至在下單支付環節大多數電商網站已經可以做到不用登錄即可下單，這方面不做過多說明

但是在to B端的電商網站中，由于對于不同地區，不同用戶等級的采購商來說，看到的價格是不一樣的。甚至有些電商網站為了保證自家商品的隱私性（是否有該商品，商品的價格是否有優勢），在不登錄的情況下都不可以瀏覽商品。另外對于不同的行業，to B端的電商上的采購商必須提交相應的資質給平臺進行審核才能進行采購。

因此，to B端的電商網站需要在用戶的體驗和業務需求上進行一些權衡，什么情況下能瀏覽？什么情況下能看到價格？什么情況下能進行下單支付？

在我們前期的系統設計中，索性直接一刀切，用戶打開APP直接進入登錄頁面，在未登錄且關聯采購商資質審核通過前不能進行進入商城主頁面。但隨著業務的發展，在APP的推廣過程中，如果用戶看不到商城的商品，采購商不太愿意注冊一個不了解的產品。

因為這中間涉及資質的審核，需要填寫企業資料、上傳證件，會比較麻煩，所以這種矛盾變得越來越激烈。因此，在后期我們對于用戶的權限進行的重新的調整。

權限設計邏輯如下：

根據登錄狀態和采購商狀態，將權限分為以下幾層：

1. 未登錄賬號的權限；
2. 已登錄賬號，但未綁定采購商的權限；
3. 已登錄賬號且已綁定采購商，但是采購商未審核通過；
4. 已登錄賬號且已綁定采購商，采購商資質審核已通過。

對于不同的權限等級，將頁面內容按照不同權限等級進行歸類：

1. 不需登錄即可看到的內容，主要是商品列表中的商品，注冊相關頁面等；
2. 需登錄但是不需要采購商信息的內容，如：賬號名，昵稱等；
3. 需要登錄且需要采購商信息，但采購商為未審核通過的狀態所看到的內容；
4. 需要登錄且需要賬號信息才能看到的內容，如：商品價格，購物車等。

按照以上邏輯對于權限進行劃分之后，就可對各個頁面進行整體的設計了。在我們的實際開發過程中，由于之前是只有已登錄且關聯采購商審核通過才可進入商城主頁面。所以若需要對權限邏輯進行從新設計，那么各個頁面調取接口的邏輯必須修改（這部分地方值得深入思考）。

所以最后我們對于未登錄，采購商資質未審核通過權限涉及的相關頁面重新設計了一套（頁面的復制粘貼，調取獨立的接口），但這樣的弊端是后續有一部分頁面的修改迭代都必須同時改兩處地方，而且頁面的體驗也會損失很大一部分。

經驗教訓總結：由于前面直接在登錄頁面進行一刀切，在后期對權限邏輯進行調整的時候，導致涉及的東西太多而不敢直接在已有的基礎上進行修改。所以我們在做權限架構設計的時候，就算當初的需求是這樣要求的，也需要考慮后續需求修改的拓展性。

三、前端展示頁面相關設計

1. 登錄注冊流程：與C端的電商的登錄注冊模塊不同，除了賬號的申請之外還要考慮采購商企業資料的提交（也提供跳出路程的出口）。
2. 賬號的管理：上文說到的每個采購商的管理員需要管理子賬號，所以提供添加子賬號的頁面（不存在的子賬號則直接先生成一條賬號信息），并可將該賬號從采購商中刪除。
3. 創建新采購商：提供兩條路徑：一個是在注冊時，一并完成新采購商的創建，一個是登錄后，專門提供一個入口創建新采購商。
4. 切換所屬的企業：采購商可以切換當前所屬的企業，以方面單獨為每個企業進行采購。

本文由 @?不橈 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議