有贊技術 有贊coder
背景
有贊作為一家 SaaS 服務公司，核心價值是為商家提供産品解決方案以及服務。 B 端産品的場景通常比較複雜，通過處理客戶回報需求，一方面滿足客戶訴求，提升商家的活躍度；另一方面可以從客戶回報中提煉真實使用場景和想法，反哺産品設計進行産品疊代。商家回報的需求往往是一些經營視角的訴求，無法直接用作研發，在到研發之前，需要經過服務經理初步篩選，根據内部分工分發給對應的産品經理，産品經理對需求進行了解、合并、拆分和規劃排期，這一系列的流轉橫跨了公司的多個職能部門。
根據精益管理的理念，一切客戶不會為之買單的成本，都稱之為“浪費”。站在客戶的視角來看，他們并不會關心需求在有贊内部如何流轉，而更關注有贊響應和解決問題的時效，要提升客戶的滿意度，就要減少需求流轉過程中的不必要的“浪費”。
有贊為商家提供了 BBS 論壇、産品端回報需求入口、客滿熱線、服務經理對接等多處回報管道，讓商家能夠更友善、快捷的回報需求，但多個管道回報的商家需求如果沒有進行統一的管理，就會造成一些問題：
商家回報需求沒有統一的待辦清單，無法集中跟進、規劃、處理。
需求處理進度無法及時更新、透明，增加了很多重複溝通和跟進成本。
上下遊團隊配合缺少明确的流程與問題上升機制，導緻需求處理效率緩慢，積壓嚴重。
需求處理結果沒有及時閉環回報給商家，導緻商家再次咨詢或投訴，滿意度降低。
無法針對商家集中回報的功能子產品進行分析，驅動産品提煉更貼近商家使用場景。
效能改進與産品、服務營運等多個部門參與針對以上問題進行了分析和改進，梳理出适合跨部門多角色有效協同的方法，本篇文章大緻介紹此次改進的思路以及實踐經驗可供參考。
一、建立端到端閉環的工作流
工作流是為了把必要的人串聯起來完成某個目标，把含有多個環節或者步驟的工作，清晰地定義出每一個步驟所需要完成的事情和參與人的職責，形成共同約定和可流動的價值。一個新人加入組織，可以快速的根據工作流完成一項工作，減輕了教育訓練和學習成本。
制定過程中有三個要點：
任務流向閉環：明确任務的傳遞方向和次序，確定閉環。
任務交接：明确任務交接标準與界限
推動力量：明确内在協調與限制機制
如圖：
工作流是一個組織優秀實踐的沉澱，通過建立和不斷優化端到端閉環的工作流，商家需求響應的能力得到改善：
通過明确各環節的職責範圍，上下遊各團隊能夠持續關注、協作處理，并約定了初步的處理時效。
從需求分散各處，到統一需求待辦清單，建立了固定溝通機制和通道可以確定重要且緊急的需求優先安排研發。
明确各産品子產品需求負責人，提升了内部溝通和處理效率。
二、解決瓶頸問題，建立 SLA （Service-Level Agreement）
商家回報需求做到了【管】後，需要進一步做【理】的改進，目的在于提升價值的流動效率，而非單純提升資源效率。
【限制理論】中提到過，在一條業務鍊中，瓶頸節點的節拍決定了整條鍊的節拍，任何一個多階段生産系統，如果其中一個階段的産出取決于前面一個或幾個階段的産出，那麼産出率最低的階段決定着整個系統的生産能力。
要提升整個處理回路的效率，需要找出瓶頸環節，針對性的解決問題，疏通整個鍊路的流動。有贊處理商家需求的回路可分為兩大周期：
從商家提出需求到客滿或服務經理，服務經理對需求進行登記、收口并指給對應産品經理--産品經理收到需求評估是否是商家經營的本質訴求，并給出答複接受或無法滿足--服務經理、客滿答複商家處理結果。
産品經理對接受的商家需求進行方案設計–研發排期–研發上線–服務經理或客滿通知商家上線
我們将處理鍊路上每一個環節制定了 SLA 标準，觀察各環節的處理時效，并通過逾時上報的機制上升回報來保證需求可以被及時處理。最初的改進重點在推動産品經理及時響應，然而如果大量處理結果做不到及時的回報給商家，那麼前期的推動就産生不了價值。及時的将處理結果回報給商家的好處在于，商家得到良好的回報體驗的同時，有贊可以收到商家對新功能的體驗感受，帶來新的回報。以有贊目前的情況，每月收到商家回報的需求量達到上千條，僅是産品經理對需求了解、處理，服務經理、客滿對逐個需求的處理結果進行答複給商家，都會是很大一部分人力成本。而這部分的成本是商家不會為之買單的“不必要浪費”。
使用商家數不斷增加，商家回報需求數會跟着增多，進而需求整理、回報的人力成本增加，導緻占用了服務經理和産品經理真正投入去挖掘提煉真實需求的精力，整個産品的疊代優化速度會降低，影響商家的活躍度甚至會減少使用商家數。我們通過以下兩個方法去減少在需求整理、回報的成本。
我們通過商家畫像、商家回報數兩個次元量化優先級，提升産品經理處理需求的效率，節省人力。
影響力：經營場景和使用者角色相對複雜的行業标杆商家回報的需求更具有行業代表性，更容易抽象高層次的模型，利于産品向下相容。
影響面：營運将所有商家送出的相同需求關聯到一起，呈現同一個需求影響商家數，來解決商家普遍回報的需求。
微商城、零售産品端開放了需求回報入口，商家可以通過店鋪系統背景随時回報使用問題，同時可以随時檢視需求的處理進度，進而減少了一些對需求登記、跟進、回報的“服務人力成本”。
三、管理工具線上化
起初我們是用文檔、表格來記錄商家回報的需求，交給産品經理來評估方案、更新需求的研發進度。而需求進入研發過程是在效能平台進行流轉（自研項目管理工具），這樣一來會有很多弊端，例如，人工維護多個需求清單的資訊，會造成進度更新不及時，進而造成資訊不對稱，答複商家錯誤的進度，引起商家不滿。管理者想知道商家提的需求集中在哪幾個功能子產品？某個商家今年總共提了多少需求？我們解決了多少，多少沒有滿足？這些過程資料都需要手動梳理，耗費人力。基于以上訴求，我們把商家需求前期收集的過程也做進了效能平台，讓需求從商家提出一直到研發上線在同一個平台流轉，便于管理需求全生命周期（如下圖）。
在設計工具時需要考慮這幾件事：
明确關鍵使用者的訴求：使用該用具的人希望通過工具解決什麼問題？（業務方希望實時透明商家需求進度、産品經理希望減少處理步驟、管理者希望看到處理時效的資料）
明确想要表達的關鍵資訊：該工具想要傳遞給使用者的資訊是哪些？（需求的報告人和經辦人，需求相關的商家資訊、需求目前狀态、流轉的時間節點、優先級、需求對應的産品子產品等）
梳理使用場景：使用者會在哪些場景如何使用？（送出需求時要怎麼做、産品經理在收到需求時要怎麼做、想檢視進度時怎麼做）
管理工具線上化帶來的好處顯而易見：
降低教育訓練成本，對于新人來說，不清楚需求的如何流轉，可以按照工具的引導來完成。
需求全生命周期在同一平台流轉，減少了人工維護進度的人力成本，上下遊資訊保持實時對齊。
可擷取系統資料，可用于度量和分析，為後續優化流程和政策提供依據
從商家回報需求分析關鍵字端資料，分析集中功能子產品問題、商家行業等輔助産品優化
基于商家需求的流轉，可以提取各種資料，如各環節的處理時效，需求集中的功能子產品，從不同次元進行資料分析（如下圖），對有贊的營運計劃和管理動作起到很大的輔助作用。
總結
有贊服務着數量龐大的商家群體，微商城、零售等标準産品能滿足商家的大部分經營需求，但相對于商家回報的需求，有贊的人力是有限的。面對标準産品無法滿足的多樣化的需求，有贊雲應運而生，結合社會化的開發者夥伴生态，助力商家成功，幫助商家低成本高效率的實作個性化、多樣化的定制服務。
很多企業的經營理念都是以客戶為中心，有贊的願景是幫助每一位重視産品和服務的商家成功。這并不是一句簡單的口号，而是真正的站在商家的角度去思考如何更專業的服務，提供更好的産品。介紹了有贊在管理客戶回報需求上的「工作流」、「改進方法」、「工具」後，有幾點心得跟大家分享：
能夠長久生存發展的公司的協同工作流一定是強大的，而且必定是與時俱進的。不斷的優化工作流就像一個人需要不斷的反思自己一樣重要。
照搬别人的改進方案基本是行不通的。不同的組織都有不同的曆史背景、素質、氛圍，方案的制定一定要因地制宜。可以學習精華部分，再适配到自己的組織中。就像人可以學習其他人的優點，但是沒有辦法過和别人有同樣的人生一樣。
過程改進可以“靈活”一些，不用等到一切都無懈可擊再去推行，是一個透明-檢視-調整的過程，也是組織磨合的過程。