營運門戶

營運門戶是一個需要登入的網站，客戶、合作夥伴、代理或員工可以透過它自行提交事務，並一直追蹤至完成。事務可以是申請、訂單、報告，或索取文件的要求。門戶建立在公司現有系統之上：從CRM，即銷售系統，讀取客戶數據；從ERP，即結算和倉庫系統，讀取訂單狀態。已提交的事務會寫入客戶服務部本來處理它的地方，因此不會在現有客戶資料庫之外另起一個資料庫。

帳戶和權限：誰可以登入、可以看到甚麼；客戶看到自己的事務，代理看到其客戶的事務，客戶服務部看到全部。事務表格：輸入時即時檢查欄位，避免沒有附件或號碼錯誤的申請送到公司。狀態和記錄：每一步都連同日期和經手人記錄下來，雙方都能看到，狀態改變時以電郵或短訊通知。文件：發票、合約和確認書由公司系統中的數據生成，無需詢問員工即可下載。

在公司這方，我們建立客戶服務部的管理介面：事務清單，誰在等候、卡在誰手上、等了多久，以及分配給個別同事和回覆，全部集中在一處。部門可以為致電的客戶代為建立事務，讓電話和門戶的事務都記錄在同一個登記冊中。每次登入、提交事務、狀態變更和文件下載，都會寫入事件日誌，即記錄誰在何時做了甚麼，以便處理投訴和接受審查時使用。

如果公司的系統之間尚未交換數據，連接這些系統屬另一個範圍。如果事務背後沒有任何系統支撐，就要先建構定制系統，這同樣屬另一個範圍。由於個人資料會經過門戶，我們在建構前確定門戶會記錄哪些數據、存放在哪裏、誰可以存取。

1. 我們整理各類事務。我們與客戶服務部面談，並查看每宗事務最終在系統中的哪裏完結。成果：事務圖，以及事務納入門戶的次序，由最常佔用部門時間的事務開始。
2. 我們設計門戶。我們確定角色、每類事務的流程、通知，以及從公司系統讀取數據的方式。成果：經將來的使用者檢視過的畫面和流程設計。
3. 我們逐類事務上線。第一類事務先向選定的一組客戶、合作夥伴或一個部門開放，收集意見後再加入其他類別。成果：事務在門戶中處理，電話和電郵只保留給尚未納入門戶的事務。
4. 我們移交門戶。我們培訓客戶服務部和管理員，並移交文件。成果：門戶由您的團隊營運；上線後的維護與持續開發屬另一個範圍。

1. 客戶的事務在等待決定時，客戶會看到甚麼：階段、經手人、最後更新日期？
2. 門戶從哪裏取得客戶和訂單數據：從我們的系統，還是從自己的副本？兩者不一致時會怎樣？
3. 合作夥伴的員工離職時，由誰撤銷其權限？需要多長時間？
4. 門戶會保存提交者的個人資料多久？我們這方由誰可以刪除這些資料？
5. 如何新增事務類型：透過我們的管理員可用的設定，還是要委託承辦商處理？
6. 當客戶聲稱已提交申請，而公司卻看不到時，事件日誌會顯示甚麼？

哪些事務會納入門戶的第一個版本、門戶要與哪些系統連接，由流程分析確定，我們也由此開始。