以电商和医疗行业为例，看B端工作台和消息系统的设计

工作台和消息系统是B端产品的2大必备，但又不是核心功能点，所以常常得不到重视。

工作台的主要目的是针对一些重要数据、重要业务的概览；而消息系统是提醒业务消息、系统消息等重要消息的。在不同的应用场景下，两者的功能可能完全不同，当然也可能高度重合，如何更合理的设计这两个系统呢？既能满足用户使用，又能节省开发成本。

本文以电商和医疗行业为例，除了从功能层面来讨论，还会带大家了解技术方案，以便选择更合理的实现方式。

一、工作台和消息系统的区别和联系

1. 常见功能

（1）工作台

工作台在有的系统中会被称为首页、概述。进入系统时一般首先跳转到的就是这页，这个页面是一个大集合，用户可以在这页上看到很多重要的信息概览。

下面是一些电商的首页，我们可以看到，这些页面上内容较多，有这些常见的功能模块：

• 重要及待办事项提醒：待付款、待发货、待退款售后、待处理工单等；
• 经营数据统计：支付订单数、支付金额、累计客户等；
• 常用功能快链：发布商品、订单查询等；
• 官方运营：头条新闻、活动报名等；
• 帮助服务：经营建议，交流学习等。

可以说卖家关心的，以及平台想推广的，在这个上面都能一览无余。但电商的业务处理场景比较简单，主要是订单处理这条主线，而营销又是他们的刚需，所以他们的首页大部分是平台的推广。

订单处理路径：

在医疗系统中，我们会发现，工作台以待办事项、业务数据、常用功能快链为主，基本不会出现平台的营销推广。

待办事项的表现形式又有所差异，不仅仅是一个总量的统计，还会具体到每个事项的详情。比如说待分诊、待接诊、待回访客户的信息，以及对应的快捷操作按钮。

（2）消息系统

消息系统主要是这三方面的重要消息的提醒和存储：

• 业务提醒：和业务流程相关的提醒，比如说待发货，待评价；
• 普通提醒：和业务主流程无关，但有重要支撑作用的，比如说库存预警，效期预警，客户生日提醒；
• 系统公告：一般用来发布系统更新、平台活动等通知。

从展现形式来看，一般会有一个独立于页面的悬浮消息列表，如下图。这样可以在不打断用户操作的情况下，实时查看重要消息。

如果消息内容比较多，有的系统还会再增加一个专门的页面，来承载所有的历史消息。

我们从上面的功能对比中发现，工作台重要及待办事项提醒中的内容，如果提醒的细致一点的话，可能就和消息系统中的内容重合了，甚至是高度的重合。这种时候还需要做2套吗？是否可以共用一套方案？我们先来了解下技术方案。

2. 技术方案

（1）总量统计

我们在上面图中看到的，工作台上面的数量总计，比如说待发货数量3，待评论数量5，其实背后有一个统计中心。

如果增加了一条待办，统计中心对应业务的数量就会加1。反之，处理了，状态改变了，数量就会减1。比如说一个订单从待付款状态变成了待发货，前者加1，后者减1。

工作台都是以一个页面的形式来呈现的，所以在进入这个页面时，会去实时获取最新的数据。这时只需要从统计中心把值取出来就行，不需要实时去查询每个业务的状态，然后做汇总计算。因为实时的查询非常损耗性能，这个页面可能就加载不出来了。

（2）实时查询

如果想要在工作台上面显示具体的信息，就需要在进入工作台时实时的查询，比如下图的排班信息，这个功能数据比较少，只需要直接在排班功能下查到当前账号的信息，然后回显出来就行，不影响性能。

但我们看上面的我的待办里面的信息，涵盖了系统的所有业务流程，还有很多预警型的通知，如果每个信息都去实时的查询，那每个业务都需要一个查询接口，当这个页面上有20个业务类型时，接口就多的要卡死了，严重影响性能。