消息进入消息盒子，则可被用户所查阅。此时可以根据状态将消息分为2类，即未读消息和已读消息。用户重点关注会放在未读消息上，所以优先给用户呈现新触达的未读信息。2类消息之间转换也很简单，用户点击打开即为已读；逆操作（即已读变为未读）则看具体系统定位和用户需要，一般不会设置逆操作。
至此，消息流逻辑就基本梳理完成。特别地，消息中心在设计时尽量不要融入复杂逻辑，如定时发送、重复发送等，应尽量保持逻辑简单以支持大量的消息分发和保持其作为系统底层机制的包容性；而定时发送、重复发送等逻辑应归类于业务层逻辑，应由业务侧决定。
例如，某个少儿美术在线教育公司内部CRM客户管理系统，其业务上有众多重复提醒和定时发送提醒的逻辑，如给销售人员重复提醒某个销售任务没有完成，每周二、四晚定时提醒销售人员准备跟进体验课，等等。这些逻辑均是设置在业务层，由业务层判断是否需要触发提醒，如需要则向消息中心发出请求，传入相关参数进入消息队列排队发送。这样能保证消息中心简单而高效运转，不会因为复杂逻辑产生不必要的消息流问题（如无法兼容多种重发逻辑等）；也把运维的重心都偏移在业务层，使得不同业务消息互不影响。
三、总结消息中心是B端产品系统的基本功能，一个包容性强且设计合理的消息中心，能更好地支撑系统与用户之间的对话，传达我们想要告诉用户的信息。消息中心设计之初需要先确认系统定位和功能定位，才能规范好数据范围，从而在实现产品功能价值和满足业务需求。消息流逻辑也需要尽量梳理清楚，使其成为系统基础服务，不要与业务逻辑强融合，才能保证其良好地包容性和避免返工。
以上是个人工作过程的一些经验总结和思考，仍有不足，正在努力。
本文由 @群子 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于 CC0 协议

稿源：(人人都是产品经理)

【傻大方】网址：/c/1201b0X62021.html

标题：通知|B端产品设计：消息中心数据流逻辑( 二 )