团餐 SaaS 的复杂性不在功能数量，而在于它连接了甲方、运营商、食堂经理、财务和消费者等多重角色。本文从角色关系切入，剖析每个角色的核心诉求与协作断点，并引入服务蓝图方法，为设计跨角色流程提供新视角。

在上一篇笔记中，我从行业规模、经营模式和业务流程入手，去梳理这个行业的画像，以便能够快速理解这个行业。

随着研究深入，我发现团餐 SaaS 比普通点餐产品更难理解的地方，并不只是功能数量，而是它同时连接了许多不同的组织与岗位。一个看似简单的员工用餐行为，背后可能涉及企业后勤、团餐运营商、食堂经理、收银人员和财务人员。他们参与同一件事，却各自关心不同的结果。

为什么团餐 SaaS 的用户关系这么复杂？

在普通餐饮场景中，顾客通常自己选餐、付款和消费，服务关系相对直接。但在团餐场景中，采购餐饮服务的组织、经营食堂的公司、操作管理系统的员工，以及最终吃饭的人，往往不是同一方。

这里需要区分三个概念：客户是采购或付费的组织，用户是实际操作系统的人，消费者则是最终接受餐饮服务的人。三者可能重叠，也可能完全分离。

假设一家大型国企通过招标引入团餐公司经营员工食堂。企业后勤负责监督服务和制定餐补规则，团餐公司负责经营，食堂经理协调现场，收银员处理消费，财务人员负责对账，员工则只希望方便地吃上一顿饭。

对于同一笔午餐订单，员工关心是否扣款成功，食堂关心是否完成交易，甲方关心补贴是否符合规定，财务还要确认资金是否准确结算。

这些角色并不是简单的上下级关系，而是通过合同、服务、资金、权限和数据连接在一起。因此，研究团餐用户不能只按岗位罗列需求，还要理解每个角色在业务链条中的责任，以及他们与其他角色如何协作。

甲方管理者：不一定经营食堂，却要对服务结果负责

学校后勤、医院总务、企业行政或集团后勤部门，通常代表团餐服务的甲方。他们未必每天参与采购和备餐，却需要确保食堂持续提供安全、稳定且符合预算的服务。

对这类管理者而言，重要的问题不是今天卖出了多少份宫保鸡丁，而是服务是否达到合同标准、餐补有没有超出预算、投诉是否得到处理，以及食品安全问题能否追溯。

以一家拥有多个园区的企业为例，如果各园区食堂的消费、补贴和服务评价数据分别保存在不同系统中，总部就很难快速掌握整体情况。遇到员工反映餐补异常时，后勤人员可能还需要联系食堂、财务甚至支付服务方才能查清原因。

这样的协作方式不一定出现在所有企业，但它揭示了一个值得研究的问题：管理者需要的是对服务结果的可见性，而不是大量与自身职责无关的操作入口。

团餐运营商：从管理一家食堂，到管理几十个项目

如果说甲方关注服务结果，那么团餐运营商更关心经营本身。一家公司只经营单个食堂时，很多问题可以通过现场观察和日常沟通解决；但当它同时承接几十家学校、医院和企业食堂时，管理复杂度就会迅速上升。

集团管理者需要知道哪些项目盈利、哪些项目成本异常；区域负责人需要协调不同食堂的人力和物资；项目经理则需要保证每天的供餐稳定运行。

如果不同项目采用不同的数据口径，总部即使拿到了大量报表，也未必能直接比较经营表现。比如某食堂的食材成本率连续上涨，仅知道这个数字并不足以做出判断，还需要结合采购价格、库存损耗、就餐人数和菜品销量进一步分析。

食堂经理：每天都在处理不同类型的任务

在团餐经营中，食堂经理是一个值得重点研究的角色。这个岗位既要协调厨房、采购、仓库和收银，也要面对甲方的服务要求和员工的现场反馈。

早上可能在确认采购到货，中午忙着处理排队和菜品供应，下午又要查看营业数据、安排人员和准备第二天的菜单。这些工作并不天然按照软件的功能模块发生，现实中的一件事往往要跨越多个模块才能完成。

例如，某道菜临时停售，可能涉及菜单调整、前台展示、订餐订单和厨房备餐。如果系统只提供彼此独立的“菜品管理”“订单管理”和“厨房管理”，经理就可能需要反复切换页面，还要在线下通知其他岗位。

因此，我更关注食堂经理的每日任务流：营业前需要确认什么，营业中需要监控什么，营业后需要核对什么。对于这类用户，一个能够聚合待办、异常和经营信息的工作台，可能比继续增加功能菜单更有价值。当然，这仍然是一种待验证的设计方向，而不是对现有系统的直接判断。

一线执行人员：关注的是把事情做对

采购、仓库、厨房和收银都参与食堂经营，但他们的工作环境和任务并不相同。

采购人员需要根据菜单、预计人数和库存确定采购数量，并处理供应商价格或交货变化；仓库人员需要在现场验收、盘点和记录食材批次；厨房人员关注今天做什么、做多少、什么时候完成；收银人员则必须在就餐高峰期快速、准确地完成交易。

这些岗位的体验问题也往往十分具体：采购计划与菜单变化不同步，可能造成重复采购；仓库验收反复手动输入，会增加现场负担；厨房临时收到变更通知，可能影响备餐；收银设备在支付结果不明确时缺少反馈，则可能引发重复操作和人工核对。

不同岗位需要遵循一致的业务规则，但不一定需要长得一样的操作界面。

财务人员：一笔消费背后，可能有多条资金记录

团餐财务之所以复杂，是因为消费者支付的金额与餐食总价未必相同。假设一份午餐售价 20 元，企业补贴 12 元，员工支付 8 元，系统不仅要记录一笔消费，还需要按照合同和账户规则处理补贴扣减、个人支付、退款以及后续结算。

如果订单发生退款，财务人员需要确认的不只是“20 元退没退”，还可能包括个人支付是否原路退回、补贴是否恢复、支付渠道流水是否一致，以及对应结算记录是否需要调整。不同客户的补贴规则和结算周期又可能不同，这让对账工作具有很强的业务属性。

因此，财务系统不能只追求页面整洁或操作步骤少，更重要的是让每笔交易的资金构成、业务状态和处理记录能够被准确追溯。比如出现对账差异时，系统应帮助用户找到对应订单、差异金额和相关流水，而不是只给出一个笼统的“对账失败”。

对财务人员来说，好的体验不是省掉必要的审核，而是减少重复核对和不确定性。

最终消费者：只关心能否顺利吃饭

与管理角色相比，员工、学生、医护人员等最终消费者的诉求更加直接：今天有什么菜、是否需要排队、怎么付款、补贴还有多少、发生扣款异常后去哪里处理。

但不同场景的需求也不能一概而论。学校可能涉及学生身份和家长参与，医院可能涉及患者营养餐与病房配送，大型国企则可能涉及跨园区就餐、多班次餐标和员工补贴。看似都是“点餐—支付—取餐”，实际业务规则却可能差异很大。

对于消费者端，我更倾向于从完整的就餐旅程理解体验：从查看菜单、选择餐食，到支付、取餐、查询记录和反馈问题。每一个环节都应该回答用户当下最关心的问题，而不是把后台复杂的业务规则直接暴露给消费者。

真正值得关注的，是角色之间如何协作

梳理这些角色后，我发现一个比“每个岗位需要什么功能”更重要的问题：团餐 SaaS 的体验往往发生在角色之间，而不只是某个页面之内。

以一次普通的采购为例，食堂经理可能提出需求，采购人员下单，供应商配送，仓库管理员验收，财务人员完成结算，集团管理者查看成本。同一件事经过多个岗位，每个人只处理其中一部分。如果状态不同步、责任不明确或信息需要重复录入，哪怕每个页面都设计得很好，整体体验仍然可能很差。

这让我想到服务蓝图（Service Blueprint）。相比只关注某个用户如何操作界面，服务蓝图能够把前台行为、后台工作、跨岗位协作和系统支撑放在同一张图中。对于团餐这种多组织、多角色的业务，我认为它尤其适合用来分析采购、餐补、退款、对账等跨角色流程。

具体来说，一条流程通常可以拆成几层来看：

用户行为：现场的人实际做了什么，比如刷卡、付款、询问补贴余额。

前台接触点：他们直接看到的界面、设备或人员，比如收银机的支付提示、订餐小程序里的订单状态。

后台工作：用户看不见但必须发生的动作，比如补贴扣减、库存扣减、订单状态同步。

支持流程与系统：让后台工作能够成立的条件，比如餐补规则配置、支付渠道回调、各系统之间的数据口径。

我们再以退款为例，如果按这几层展开，就会发现真正需要设计的并不只是“退款”这个按钮。员工提交申请之后，食堂需要确认订单，财务需要判断个人支付和补贴分别怎么处理，支付渠道需要返回结果，结算记录还要同步调整。任何一环缺少明确的状态和反馈，用户在界面上看到的就只是一句“处理中”。

这种视角也会改变需求优先级的判断方式。一个功能好不好用，不再只取决于它自己的页面是否完整，而取决于它是否让上下游的人少问一次、少核对一次。如果只按岗位罗列功能，很容易得到一张很长的清单，却回答不了“这件事究竟卡在哪一步”。

思考与总结

通过这一轮研究，我对团餐 SaaS 的用户角色渐渐有了更清晰的认识：甲方管理者关心服务质量和风险，团餐运营商关心经营效率与利润，食堂经理需要协调日常运营，一线人员关注任务能否准确完成，消费者则希望方便、安全地吃上一顿饭。表面上，他们使用的是同一套团餐服务体系，实际上却站在不同的业务位置，承担着不同的责任。

如此多的角色和各不相同的需求，也让我意识到这次项目的挑战：在时间紧迫的情况下，我不仅要尽快理解业务，还要产出方案并进行验证。这也给了我一个重要的提醒：不能一看到大量功能，就急着按角色拆分系统或重新规划菜单。

更重要的是先弄清楚谁在使用、为什么使用、需要完成什么任务，以及任务如何跨越组织和岗位。只有理解这些关系，才能判断哪些能力应该统一，哪些工作空间需要差异化，哪些流程值得优先优化。

另外，还有一个不容忽视的用户特征：在项目接触到的用户中，部分人年龄偏大，对数字化产品可能不够熟悉。这并不意味着可以简单地用年龄判断用户能力，而是提醒我们在设计时，需要结合实际使用情况，关注信息是否容易理解、操作步骤是否清晰、关键反馈是否明确。好的体验不只是视觉上的更新，更要让不同岗位的用户都能顺利完成工作。

最后，我们借助 KANO 模型，把团餐行业各类用户角色的需求进行归类和总结，区分哪些属于基本型需求、期望型需求和魅力型需求，从而为后续的优先级判断提供参考。

感谢阅读，我们下篇再见！