办公室预订共享座位池，得到的并非某张固定桌子

预订记录上写着某个办公区域，员工到场后却仍要选择具体桌子，这未必是预订信息漏了一项。在 Microsoft Places 的对象设计中，指定桌位与共享座位池本来就有不同含义。先看预订了哪一类对象，才能理解确认信息精确到了什么位置。

微软的 Desks 文档说明，个别桌位预订允许用户选定一张具体桌子；desk pool 则在明确区域内预留一个座位，例如某个团队区域，而不提前选择精确桌位。使用者到场后再在该区域选择位置，是文档对这种方式的描述。它不等于凭一条预订就能承诺任何时间都有自己偏好的桌子。

两种方式可以在同一组织并存。值得留意的是，文档同时限定：每一张物理桌子只能以其中一种方式配置。这里的区别不是把同一张桌子在名册中多记一次，而是确定它由哪一种预订对象来表达。两套名称相加，也不能直接当成额外增加了实体工位。

个别桌位还有四种模式。Reservable 可以提前或当场预订；Drop-in 面向当场使用，不能提前预订；Assigned 关联特定使用者，其他人不能预订；Unavailable 则因维护等原因不供预订。由此可见，出现在桌位目录中，并不意味着它当前都可进入相同的预订流程。

这些对象还处在楼宇、楼层、分区、桌位或座位池的层级中。假设一份确认只写“A区共享座位池”，另一份写“A区某编号桌位”，二者都提供位置，却处在不同精度。前者不能被随手补成一个桌号；后者也不能被改写成使用者可在整区任意选择。这个例子用于解释记录，没有查询任何公司的实际预订。

对办公空间沟通，最有用的不是把所有对象统称为“可订工位”，而是让使用者知道自己选的是区域容量还是指定位置，并保留对应模式。需求若涉及固定设备或某个具体位置，仅凭座位池名称仍不足以确认；那需要该预订实际提供的进一步信息。

本文采用所读 Microsoft Places 在线文档的对象说明，没有运行管理命令，也不判断某个组织已购买哪些许可、开放哪些入口。理解对象粒度，能够让一条预订确认保留原来的含义，而不把软件目录中的名称转换成对现场座位的额外保证。