编辑导语：为了提升企业效率，服务于企业的B端产品也需要进行提效改良。其中，工作台代办是一种常见方法，结合工作台代办，企业员工可以更快速地安排工作，进而提升业务处理速度。本篇文章里，作者结合实际经验，总结了工作台代办的意义与设计流程，一起来看一下。

B端产品服务于企业，产品效率直接影响企业效率，所以提效对于B端产品来说是核心价值。典型的提效方法，比如工作台待办，就是一种较常用的方法。今天关于待办这个话题，十年老产品与您分享一二。

一、首先，工作台是什么？

企业为了满足运营需要、为企业员工搭建统一的操作平台，并提供系统工具，使大家通力协作支撑企业的正常运转。常见的工作台有商家工作台、办公协作工作台、运输管理工作台、课程管理工作台等等。

待办是工作台重要的组成部分，但待办不完全依附于工作台，工作台只是待办流程的对外载体。

二、其次，为什么要做待办？

工作台服务于企业，企业里的员工千差万别，工作能力强的员工可以高效有条理地完成工作，相反工作能力弱的员工则会拖延工作甚至出错，比如体现在时间的管理和工作优先级排序上，能力强员工和能力弱员工的差别较大。

针对这个问题，我们希望通过一种方法来帮助员工进行高效工作，将工作能力强的员工技能通过系统手段复制给他人，比如可以用系统手段来替代员工记忆工作事项并排定工作优先级，为了满足这个目标，待办应运而生。

从功能角度来说，待办是一种用系统代替人脑来记忆和合理安排工作的方法。

三、那么，待办怎么做？

本文仅提供一些待办的底层设计思路，并不包含表现层设计，具体的待办交互形态和通知提醒等大家可根据所在企业的诉求进行具体的产品设计。

1. 概述

• 待办是什么：顾名思义，等待办理的事项。
• 核心目标：提高个人单位时间的工作处理量。
• 建设思路：弱化个人差异，由待办任务驱动工作流转，从人找事到事找人，基于业务场景构建工作闭环。
• 待办服务：打破业务筒仓，基于业务场景打造统一的待办服务。

2. 待办类型

按待办类型分，审批都是待办，但待办不都是审批，主要分为业务类待办和备忘类待办。

• 业务类待办：一般由系统自主发起，业务数据命中待办规则引擎而触发自动化待办流程，比如待审批、待分配、待验货、待发货、待盘点、超时预警、待拜访等。
• 备忘类待办：可以由他人或自己来自主发起，支持自定义待办内容并指派处理人，信息穿透直达处理人，相比于口口相传，可以大幅提高信息传递的成功率和准确率，待办处理过程可溯源。

3. 待办角色

待办角色：发起者、接收者。

待办角色按工作流向分为发起者和接收者，待办发起者可以是system、管理者和普通员工，执行者可以是普通员工和管理者。

4. 分配原则

1）唯一责任人原则

原则上一条待办需指定唯一负责人，避免多负责人引起的职责划分不清等内耗问题。

但如果企业内部存在多人同时负责相同业务的情况，责任边界并未划分清楚，这种情况下需要考虑责任到人的落地情况，需进一步论证方案的可行性，产品打造的永远是当前条件下的最优解，而不是理论上的最优解。

2）最优匹配原则

待办结果好不好，跟分配的人对不对有很大关系，所以尽可能地按待办内容分配给对应的人很关键。

但能这么做的前提是需要维护人和待办内容或类型的映射关系，但是与唯一责任人原则遇到的问题一样，如果线下运营未精细化，那么系统也无据可依，系统无法知晓谁是这条待办的最佳处理人，那最差的结果就是全局广播，所有人都能看到然后自行识别是否能处理。可以说系统层面待办的匹配效率与线下运营的成熟度成正相关。

5. 待办的处理方式

待办处理方式：线上、线下、线上+线下。

根据业务流程的线上化程度，待办的处理方式可以分为线上和线下两种。

假设某业务流程的线上化程度是100%，那么理论上可以实现待办的自动化生成、分发、处理和完成，比如签单照片的审核，这类待办是纯线上的处理方式，这种方式可以对整个待办的处理过程进行监控并做事后分析。

假设某业务流程的线上化程度是0%，那么待办的生成、分发、处理和完成均由人工完成，这是纯线下的处理方式，只能实现粗颗粒度的过程监控。

线上化程度介于上限和下限之间，则需要结合线上和线下两种处理方式。

6. 待办的完成方式

待办的完成方式：自动、手动。

与待办处理方式相呼应的，已线上化的业务流可以自动完成待办，如审核类待办，在审核完成节点触发待办完成逻辑，无需用户手动操作待办完成，而未线上化的业务流则需用户手动完成待办。

7. 待办流程

• 待办动作：生成、分配、查看、转移、完成。
• 待办状态：待分配、待处理、处理中、已完成。

8. 关于父任务和子任务

在处理一些复杂的业务场景时，我们可能会遇到多人协作完成一件事的情况，这个时候需要将一条待办任务拆分为多个子任务。比如公司的费用报销审批，需要一级领导、二级领导、三级领导的层层审批。

那么父任务和子任务的关系是什么呢？子任务由父任务拆解而来，并且父任务的完成状态依赖于子任务的完成状态，一个简单的逻辑是只有子任务全部完成，父任务才算完成。

在产品设计时，从产品的可拓展性考虑，可将待办任务进行组件化抽象，并支持多个待办任务的自由组装。

技术实现上，子任务可以继承父任务的基础属性和方法，并支持任务的多层拆解和拼接，最终可实现多任务并行或串行的推进形式，一种较复杂的待办流程示意图如下：

这种设计方式一劳永逸但成本相对较高，需要结合企业所处阶段和业务模式对待办的依赖程度，来决定最终的实现方案，毕竟产品经理是需要权衡产品价值和实现成本的。

9. 关于待办带来的效率提升如何度量

产品方案从前期调研，设计方案，最后实现上线，那么上线后的效果如何？这是产品经理需要重点思考的问题，因为产品经理不是干的一锤子买卖，上线后的监控复盘与前期工作一样重要，为后续产品的规划迭代提供经验支撑。

那么待办对工作效率的提升该如何衡量呢？

思路：工作效率=工作量/工作时间。

根据除法公式，假设工作量是一定的，如果想要提高工作效率，理论上需要缩短工作时间，更具体地说，需要缩短完成一次业务流程闭环的平均时间。

可执行的产品方法有：更短的信息链条（待办、快捷入口、全局搜索）、更快的处理速度（工作台移动化、主动提醒）、更少的处理量（批量操作）等等。

举个例子，假设工作量=1，工作效率=E，工作时间=T。

没有工作台时，完成一次揽收派车任务，操作如下：

找到并打开派车单调度页面（5s）→录入运单号（3S）→核对并勾选运单（5s）→填写车辆信息（30s）→核对并点击保存（3s），那么工作时间T1=46s，工作效率E1=1/46。

有工作台时，完成一次揽收派车任务，操作如下：

收到一条自带运单号的揽收调度待办任务→点击待办任务（1s）→填写车辆信息（30s）→核对并点击保存（3s），那么工作时间T2=34s，工作效率E2=1/34。

所以，工作台对揽收派车这个业务场景的效率提升是（E2-E1）/E1≈0.35，效率提升了35%，这是一个可以量化的效果。运用这个思路可以度量待办对工作效率的提升效果，除此之外，还可以通过业务完成率等指标来衡量。

四、结语

待办很常见，但如何设计好待办产品功能，需要产品经理细心深入琢磨。同样都是待办，可能对效率的提升差别很大，考验的是产品经理的对业务的理解和对产品的理解，小功能也可以有大门道。