自己改了预约却没收到提醒，Toast为什么仍会通知同店其他设备

前厅人员刚改过一项预约，却没有在自己的设备上看到变化提醒，未必表示Toast Tables没有记录这项变化。官方《Use Toast Tables》的应用内通知段明确说，自己作出的变更不会向自己发送通知；但同一餐厅中登录Toast Tables应用的其他设备仍会收到通知。这项例外让“谁改的”与“在哪台设备收到提示”成为理解通知记录时必须保留的条件。

这份说明针对当前班次中预约或候位组发生变化时的应用内推送，服务于前厅对新预订、取消等变化的了解。它不是发给顾客的短信说明，也没有将一条通知当成客人已经入座的证明。因此，资料交接如果写“已通知”，还应说明所说的是该应用内部哪一种变化，而不能只凭同一个词把顾客通信与员工设备提示合并。

原文列出四类事件。Bookings created涉及新预订创建或客人加入候位名单，包括线上与店内来源；Booking changes涉及人数、座位、时间或备注的更新；Large party alerts指七位及以上客人的预订；Cancellations and removals则涉及客人取消预约或自行离开候位名单。四类各有事件对象，不能把七人提示解释成餐厅安全容量，也不能把备注修改读成一份新预约。

这些类型又分别有All bookings、Reservations only和Waitlist only的适用范围。类型回答发生了什么，范围回答在预约、候位还是两者中观察。将两层关系一起写清楚，能解释为什么两个前厅提示清单包含不同事件；仅说“开了通知”仍不足以表达它们采用的内容范围。本文只说明文档语义，没有进入账号调整任何选项。

四类描述都写到within a 4-hour window，但所读连续文字没有进一步给出本文可确定的窗口起算点。于是，“四小时”应作为该文保留的窗口条件，而不能被擅自改成事件发生四小时后才推送，或未来任意日期的预约都会立即进入这一组提醒。原页另以实时通知描述其功能目标，两种文字应共同保留，不能由整理者自行发明固定延迟公式。

通知列表还提供比一声提示更多的内容：客人姓名、更新类别，以及多久以前发生。预约被编辑时，条目会说明改变了什么，例如人数变化。对前厅资料阅读者，事件类别与变更内容能帮助辨认提示的原因；而本人变更不通知本人的例外，又解释了为什么同一次修改可以在不同设备留下不同提示体验。本文没有查看真实客人资料或开展多设备测试。

来源页面标示2026年9月28日更新，首次发布日期未确认。本篇限定Manage In-App Notifications与Notification Feed及邻接，不操作权限、顾客短信、桌台安排或出菜流程。它解释的是应用内事件信息怎样被分类和分发，不据此保证现场服务速度、设备送达情况或餐厅接待结果。