接手新项目，落地产品前要先能「想清楚」，才能「做明白」

从入行产品到现在的 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产品人。希望能通过不断思考、不断复盘，让自己成为一个思考有深度，表达有条理的产品人。

本文

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！