編輯導語：產品經理接手一個新項目之后，做好業務梳理和方案規劃非常重要，這有利于更快地推進工作；并且在產品落地前，需要通過不斷的檢測，實施線下巡檢標準化等等；本文作者分享了關于復盤項目的經歷以及實踐經驗，我們一起來看一下。

從入行產品到現在的 2 年時間里，自己做過了不少項目，比如現在的：線下巡檢標準化、員工行為管理系統等等。

但一直沒有體系化的復盤這些經歷，為了能讓這些實踐成為自己的經驗，接下來決定對它們做個總結。

下面，先從線下巡檢標準化這個項目開始，希望我的思考能帶給你一些啟發。

一、什么是線下巡檢標準化

公司服務的客戶，業務上會通過線下巡檢的方式，管理旗下門店的日常運營情況；而我們是將這種業務模式產品化，幫助對方更有效率的開展工作。

這類服務模式的 SaaS 產品，屬于支持客戶業務開展的一種手段，幫助這一類存在相同痛點問題的客戶，為公司創造商業價值。

二、為什么要做線下巡檢標準化？

這是我入行產品做的第 1 個大項目，從參與到主導，雖然當時做得懵懵懂懂，但通過事后復盤，發現很多信息都藏在了日常溝通中。

后來我發現，無論是做產品規劃，還是落地項目，遵循自上而下的思考模式，能幫助我們「更有效地厘清做事的思路，避免事后返工浪費公司資源」，以我這次做的項目為例去分析：

1. 公司定位

公司提供的是視頻監控運營服務，通過接入客戶門店內的攝像頭，對監控畫面進行切片、過濾等處理方式，關注客戶指定的員工行為，定期告知客戶。

PS：不同行業的客戶，接入攝像頭的線下單位的叫法會有不同，比如餐飲、零售行業等叫做門店；消防、工地等叫做站點；學校叫做校區或幼兒園；考慮公司服務的客戶，大部分是餐飲行業，所以下面統一叫做「門店」。

1）客戶有哪些？

連鎖品牌這類 B 端客戶，以及政府、企業級的客戶。

2）要解決客戶的什么問題？

第 1 類客戶：連鎖品牌這類 B 端客戶（餐飲為主）

隨著客戶門店數量的增多，為了提高管理效率和透明度，客戶會制定員工行為巡視標準，規范管理門店，比如：員工著裝是否規范、后廚是否有人吸煙、倉庫是否有老鼠等。

客戶購買我們的服務，希望能在營業日抓拍員工行為，獲取門店日常工作開展規范情況，并輔助他們獎懲、整改門店。

第 2 類客戶：政府、企業級的客戶（餐飲和工地項目為主）

根據政府監管要求，為了避免安全事故的發生和隱患，客戶會通過場地的攝像頭進行監管。

以工地的業務場景為例，客戶購買我們的硬件盒子和算法服務，比如：未戴安全帽、渣土車密閉等，攝像頭會基于算法實時抓取特定行為；再配置專門負責監管違規的員工，處理告警反饋的違規情況。

3）解決思路

為了解決客戶的這些問題，基于客戶的特性，我們提供了兩類服務：

• 自運營：將產品（全部權限的后臺 + App）交付給客戶，由對方自行安排運營人員管理門店，以及自行推送員工行為的報告。
• 代運營：將產品（部分權限的后臺 + App）提供給客戶，由我們提供運營服務，客戶只需接收員工行為的報告推送，再確定后續的業務處理流程，看是否需要獎懲或整改。

這兩者最大的區別，在于員工行為是由我們的運營人員抓取推送給客戶（代運營），還是由客戶自己的員工抓取推送（自運營）。

至于這么做的原因，是因為大部分客戶的門店數量少，配置人員管理的成本高。

因此，對于連鎖品牌的 B 端客戶，大多是以代運營為主，少數門店多、信息化程度高的客戶，會選擇自運營。

而對于政府、企業級客戶來說，都是以自運營的硬件設備 + 軟件產品的方式提供服務。

2. 產品定位

基于公司定位，推導產品定位。

1）用戶群體有哪些？

• 外部客戶：自運營和代運營模式下的客戶，以及服務代理商。
• 內部客戶：代運營模式下的公司運營人員。

2）提供了哪些產品，產品的定位分別是什么？

• 線下巡檢產品：為客戶提供門店的線下巡檢管理工具，提供不同業務下的規范管理、任務制定等相關的運營支撐能力。
• 線上巡視產品：為客戶提供門店的線上巡視管理工具，通過人工運營服務，提供靈活的員工行為抓取，以及報告審核與推送等相關的運營支撐能力。
• 算法盒子產品：逐步支撐工地和后廚環境下的監測管理流程，為政府、項目承包方等大型客戶提供場景化告警的能力，提升處理違規的響應速度，降低事故發生的風險。

3）用產品做什么？

整理上面的信息，得到下圖：

以我的項目為來說，通過客戶類型、服務模式、用戶群體可以發現，線下巡檢產品其實屬于線上巡視產品在業務上的延伸。

要知道，公司的核心產品之一是線上巡視產品，基于銷售回訪發現客戶的續費率很低，通過調研發現客戶覺得違規行為推送服務，「只能發現問題，缺少解決問題」的手段。

PS：員工行為分正面，比如按時上下班、閑暇時間練習剪發（美容美發行業），和負面，比如后廚吸煙、收餐不及時（餐飲行業）；大多數客戶實行多罰少獎的業務模式，因此員工行為推送大多為違規行為推送。

于是，產品團隊通過調研發現，客戶會定期派人線下巡檢門店，發現違規問題會要求門店負責人改掉，但目前的業務模式會存在以下問題：

• 管理層：拿到領導制定的巡檢標準和規范，由于門店數量多、分布廣，無法合理分配巡檢資源，比如規多的門店多抽查幾次、扣分頻率高的項多關注等。
• 執行層：由于要求多、人員變動不了解業務、檢查位置不同等問題，因此容易執行錯、漏，不僅巡檢效率低，還會因巡檢問題導致門店負責人被罰錢。

因此，因為公司為了補足「解決問題」這個能力，再加上目標客戶業務上存在的問題，我們決定通過產品提供一套標準化的解決方案。

三、線下巡檢標準化的設計思路？

在理完「為什么做」之后，接下來才是思考「產品該怎么做」，同樣是按照自上而下的思維模式。

1. 產品的預期和目標

基于產品定位，推導在理想狀態下，我們需要提供什么能力，解決客戶在哪些具體場景下的哪些問題？

1）具體場景有哪些？

調研標桿客戶的線下巡檢后，梳理業務流程提煉后：巡檢跟蹤 → 違規整改 → 數據犯規 → 門店獎懲。

• 巡檢跟蹤：制定巡檢標準和規范，指派給對應角色完成線下巡檢。
• 巡檢反饋：門店負責人收到巡檢結果，對巡檢結果做整改或申訴，再由巡檢員審核結果。
• 數據反饋：展示統計結果，為客戶提供門店巡檢的決策依據。
• 門店獎懲：基于巡檢結果，客戶可對員工進行獎懲。

2）基于這些場景，我們應該提供什么樣的產品能力？

① 巡檢跟蹤：支持多業務場景下的派發任務

錄入模板：根據多個標桿客戶提供的巡檢模板，梳理歸納之后如下圖：

任務下派：根據客戶實際派發任務的場景，比如：

• 普通任務：正常派發單個任務；
• 重復性下派的任務，提供「周期性任務」自動下派的解決方式；
• 抽查巡檢的模式，提供「抽檢任務」的檢查方式；
• 任務執行：支持在 App 上完成巡檢；
• 巡檢結果查看：針對客戶領導層、管理層、執行層 3 種細分的用戶群體，支持在 PC 和 App 上查看巡檢結果。
• 巡檢結果導出：為了客戶留檔、二次數據分析等場景，需要支持客戶定期導出巡檢結果數據。
• 巡檢結果通知：為了便于及時的整改和申訴，需要在門店巡檢任務提交后，通知門店相關人。

② 巡檢反饋

巡檢項的整改 / 申訴與審核：屬于在巡檢業務上的延伸，具體來說：

• 巡檢結果無誤：門店負責人需要承認結果，并整改違規；
• 巡檢結果存疑：門店負責人可以提出申訴，反饋給巡檢員審核；
• 創建事件：支持對巡檢結果存在質疑的人發起整改、整改后提交審核、以及發起申訴的業務場景。

③ 數據反饋

巡檢結果統計：根據業務需要，在后臺系統中展示統計數據，比如：任務完成情況、得分情況、違規情況等。

④ 門店獎懲

員工行為獎懲：根據線上巡視，和線下巡檢的結果，為客戶獎懲員工提供理論支持。

2. 產品的現狀和能力

基于 01 產品的預期和目標，在希望解決的客戶問題的具體場景中，我們已經覆蓋了哪些能力？

接手這個項目時，產品流程并不符合業務流程，同時產品邏輯上也有缺失，因此需要重新規劃和設計整套系統。

3. 產品欠缺的能力

根據產品的預期和目標和產品的現狀和能力，推導產品目前還需要的能力，如下圖所示：

4. 產品的規劃和優先級

基于產品欠缺的能力，明確接下來該怎么做。

當時線下巡檢產品屬于業務探索期，從產品規劃上分為 3 個階段：

• 優先調整產品邏輯，使產品邏輯能夠符合真實的業務流程；
• 補充業務流程下的基礎功能，支持多業務場景上的使用；
• 跟線上巡視產品結合，深入到目標客戶的關鍵業務流程中；

根據產品發展方向，推導認為要做的事情，以及事情間的優先級，如下圖所示：

以上，就是我復盤這次項目帶來的經驗總結，其實都是在圍繞：要做什么？為什么要做？這兩個點去論證。

在想清楚這些之后，后面再落地產品邏輯時就是順理成章的事情。

四、線下巡檢標準化的產品邏輯？

在明確設計思路之后，剩下的就是將邏輯產品化，這里以階段1：優先調整產品邏輯為例，可以分為以下 3 個階段：

1. 巡檢前：錄入信息，下派任務

1）品牌列表

當客戶購買線下巡檢產品后，由我們負責在系統中新增對應的品牌。

2）架構設置

由客戶自己錄入自己品牌的層級架構，即品牌 → 區域（N個） → 門店的樹狀層級關系。

3）用戶列表

客戶按已建好的架構，在不同的層級下關聯人員，比如：區域關聯的人，通常為區域負責人或督導；門店關聯的人，通常為門店負責人、店員。

4）模板列表

客戶客按設計思路中模板類型，錄入巡檢的模板，同時支持兩個層級的分類。

5）任務列表

客戶針對不同的業務場景，可選擇是否使用模板，以要執行的門店為單位派發任務。

2. 巡檢中：員工執行，上傳結果

1）App接收和執行任務

到了任務開始時間，客戶的員工會在App上看到任務，按照模板執行后提交。

3. 巡檢后：展示和通知結果

1）App查看和通知結果

單條門店結果提交后，與門店關聯的人就能收到反饋通知。

五、寫在最后

現在回想起來，這個項目本身的邏輯并不難，但因為自己第 1 次逐步接觸完整的項目，再加上自己的經驗有限，所以還是做了很多“錯誤”的決策。

從這次實踐中，我總結出了幾條經驗：

1）自上而下的思考產品為什么做？要做什么？（思路參照文章的二和三）

否則直接上手，會讓我們陷入做事，但看不清效益的無用功之中。

2）B 端產品服務于業務，想不明白、做不完整是因為缺失了某些業務信息。

因此，找最懂業務的人去確認自己的理解是否準確、是否缺失，接下來再去落地產品。

#專欄作家#

空，公眾號：小木盒產品記，人人都是產品經理專欄作家。一名在迷茫道路上，成長前進的B端SaaS產品人。希望能通過不斷思考、不斷復盤，讓自己成為一個思考有深度，表達有條理的產品人。

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

題圖來自?Unsplash，基于 CC0 協議