餐饮预订流程：从咨询到确认预订

餐饮询盘为什么会卡住（以及这有多重要）

大部分餐饮项目不是因为食物不好而失败，而是在第一条消息和确认日期之间卡住。有人问“你有档期吗？”，接下来的几天就变成了断断续续的回复、缺失的细节和最后时刻的澄清。

卡点通常很无聊而且可预测：

• 询盘通过私信、语音和邮件到来，却没人接手。
• 关键细节缺失，于是有人猜测并开出并不真实的报价。
• 客户以为“已经预订”，但定金和条款从未达成一致。
• 菜单变更在私下对话中发生，导致最新版本不清楚。
• 状态模糊（“处理中”），跟进迟到或重复。

当细节缺失时，报价会很冒险。如果你不知道人数、服务形式、送达时间窗口、饮食需求或场地规则，你要么低报价然后临时手忙脚乱，要么报价偏高而丢单。随后会出现各种意外：额外人手、缺少设备、比预期更短的布置时间，或某道菜无法按规模制作。

一个简单的餐饮预订流程可以把零散的信息变成一条清晰路径：抓取要点、确认档期、基于真实约束发送报价、收定金，然后用一个统一的版本锁定菜单和物流。

这对身兼多职的业主、处理大量线索的销售团队，以及需要向厨房和司机交接的协调员尤其重要。

示例：客户发邮件说“下个月 60 人的企业午餐”。在没有清晰流程的情况下，你可能会过快报价；而有了清晰流程，你会先拿到日期、楼宇通行规则、送达时间、预算区间和饮食人数，然后自信地报价，避免事后返工。

清晰的状态让团队保持一致

当每个人用不同的话来描述同一件事时，预订就显得混乱。有人把“喜欢菜单”说成“已确认”，有人把“定金未付”时说成“已预订”。清晰的状态能迅速解决这个问题。

一个大多数团队都能接受的简单状态流程：

• 新询盘（New inquiry）：收到请求但详情不完整
• 已匹配（Qualified）：日期、人数和地点符合你的承接能力
• 已发送报价（Quote sent）：实际把价格和条款发出
• 暂定保留（Tentative hold）：在截止日前为客户保留日期
• 已确认（Confirmed）：收到定金（或 PO 批准）且活动已记入日历

把规则和标签一样明确：决定谁可以更改每个状态以及触发条件。“已发送报价”不应意味着只是已经起草，而应该意味着信息确实已发出。

把两个附属状态分开以保持主流程干净：

• 支付状态：未付款、已付定金、已全额付款
• 菜单状态：草案、已批准、已更改、已锁定

示例：客户批准了报价，但想换两道配菜。根据你的定金规则，预订可以仍然保持在“暂定保留”或“已确认”，同时菜单状态从“已批准”变为“已更改”。

如果在无代码工具（例如 AppMaster）中搭建这些状态，把它们做成带权限的下拉字段，这样变更会保持一致并容易追溯。

首 10 分钟内要收集的活动详情

快速回复能赢得生意，但速度只有在你收集到能让报价准确的细节时才有用。把它当成最低限度的简要说明：足够定价、确认可交付并避免长时间邮件往返。

先抓住那些决定成本和人手的要点：人数（允许给一个范围，比如 45-55，并询问何时会最终确定）、日期、服务时间窗（布置和开始时间）、以及确切场地地址。

接着确定服务形式和饮食限制。到店配送、带服务员的自助、分盘或巡桌服务会改变人力和设备需求。询问饮食限制并确认如何标示。

一个简短的接单清单能帮助每个人收集相同的信息：

• 活动基础信息：日期、时间、场地地址、人数范围
• 服务计划：形式、期望人手、是否需要租赁设备
• 菜单需求：饮食限制、过敏原、必备菜品
• 采购联系人：决策人、最佳联系方式、批准时限
• 场地限制：停车、装卸、厨房接入、楼宇规则

两条问题能比几乎任何东西都更减少来回沟通：

• “我们该按哪个预算区间设计？”
• “哪些是必需项，哪些是可选项？”

如果客户犹豫，给出简单选项：“我们更接近每人 $25、$40 还是 $60？”

示例：客户说“60 人的午餐”。你确认实际是 50-70 人，是送餐还是自助带服务，素食和无麸质的人数，行政助理是决策人，楼宇需要 COI 和 20 分钟的装卸时段。现在你的首次报价就能一次性正确。

如何做出与你能交付相匹配的报价

一份好的报价不是一张带价格的菜单，而是在特定条件下你将提供什么、总价是多少的清晰承诺。

把活动详情拆成明细项目

把需求转化为可计费的部分，这样以后调整就无需重写整份文件。

大多数报价会包含以下几类：

• 食品和饮料
• 人工（布置、服务、清理）
• 租赁设备
• 送达与布置（或自取条款）
• 服务费与税费（如适用）

用按人定价来处理随人数变化的部分。对保持不变的项目用固定费用（例如一定半径内的送货平费、最小人手时段、特定租赁）。如果混合使用，要标明清楚，例如“每位 $28 x 60”加上“送货固定费用”。

现实检查与审批

在发送报价前，做一次快速的现实校验：

• 人力工时：多少人、工作多长时间、是否包含清理
• 交通时间：装载、行车、停车、场地接入规则
• 最低要求：食品最低消费、人手最低、周末最低
• 时间安排：能否在所需时间窗内完成送达与上菜

增加报价有效期（通常 7-14 天）并说明过期后可能变化的项，如食材成本、人手可用性和人数。然后把客户的“同意”写明：包含事件日期与时间、人数（或范围）、菜单版本、服务形式以及包含/不包含的项目。这样可以避免后续出现“我以为那包含了”的情况。

步骤拆解：从询盘到批准报价

你的目标很简单：尽快确认基础信息，准确定价，并以团队任何成员都能找到的方式记录批准。

1）在客户还记得日程时确认细节

读完询盘后，回复（或打电话）只询问缺失的部分：日期与开始时间、人数范围、地址、服务形式、饮食需求以及任何必需项。

如果客户不确定，锁定一组你可以据此报价的假设（例如，“按 35 人、送达、一次性餐具计价”）并把这些假设写下来。

2）制作易于批准的报价

当客户能在约 10 秒内看懂报价时就会更容易批准。把食品、服务、租赁、送货、税费和总价分项列出。附上简短说明，说明包含项和不包含项。

保持以下清单紧凑：

• 菜单项及数量或按人价格
• 服务与送货费用（以及哪些情况会触发变更）
• 税费与最低要求
• 关键假设（人数、时间、接入、饮食备注）
• 到期日

3）发送、安排跟进并记录批准

发送报价时，立即安排一次跟进（例如 48 小时）。如果客户回复“看起来可以”或以签字形式确认，保存该批准，以便团队任何人都能看到。

示例：一个企业午餐请求下周四到来。你确认是 12:00，40 人，送达并需要素食选项。你发送一份带 3 天有效期的分项报价，并把邮件回复记录为批准。

一旦批准，把预订移到“Pending deposit”（待定金）并立即发送定金请求。

定金与确认——不用尴尬来回

一个清晰的定金步骤能消除大部分来回。每个人都应该清楚客户同意了什么、款项是否到账以及下一步该做什么。

让定金规则可见且一致：定金金额（固定或百分比）、到期日，以及定金保留的内容。用简单语言说明："我们将在 X 天内为您保留日期和菜单。收到定金后预订即被确认。"

当收到定金时，应立即改变某些状态。一个实用的设置是：

• 新询盘
• 已发送报价
• 待定金（Pending deposit）
• 已确认（Confirmed）
• 已关闭（完成或取消）

把付款记录保存在预订记录中，而不是某人的收件箱里。记录付款方式、收据或参考号、定金金额、剩余余额以及是谁标记为已收款。

在记录定金时设定尾款到期日，并安排你会真正发送的提醒（例如活动前 7 天、3 天和当日早上）。

示例：客户同意一份 $2,000 的报价，40 人午餐，30% 定金 48 小时内到期。在这 $600 记录到账前，状态保持为 Pending deposit，日期仅被保留。一旦到账，移为 Confirmed 并把计划锁给厨房。

跟踪菜单变更，避免信息丢失

菜单变更很常见。破坏团队的是变更记录散落在五个地方（短信、电话、邮件线程）且无人能判断哪个是当前版本。

把每次重要的编辑都当作一个新版本：Menu v1、v2、v3。加上时间戳并把旧版本设为只读。这样当有人问“我们同意了什么？”你可以一句话回答：“我们现在是 v3，周二 2:10 批准。”

对每次更改都记录相同的基本信息：谁提出、为什么更改、具体更改了什么，以及对价格、人手、租赁或准备时间的影响。

当菜单变更时，立即更新报价。如果 v2 增加了一个无麸质甜点并把人数从 80 人增至 95 人，明细和总价也应随之更新。把更新后的报价标注相同的版本号，让客户能把菜单和价格一一对应。

为更改设定截止日期（例如活动前 7 天），并添加像“菜单已锁定（Menu locked）”这样的状态。截止后新增请求应作为单独订单或付费变更单，而不是随意的“再加一个”。

保持沟通与交接有序

当更新分散在邮件、短信、笔记本、某人脑子里和一堆照片文件夹时，工作流就会崩溃。选一个预订记录的“落脚点”，把所有东西放在那里：消息、笔记和文件（平面图、合同、饮食备注、灵感图片）。

让状态可见并保持最新。状态改变时，下一个接手的人不应该必须阅读全文才能理解当前状况。

防止追单的消息模板

大多数客户沟通是重复的。简短模板能让每位客户收到相同的清晰信息，也避免团队在压力下重写旧信息。

有用的模板包括：已发送报价、定金到期、菜单批准、活动周确认和最终确认。顶部加一句简单提醒：“发送前更新下面字段”，以免复用旧日期或地址。

不会丢任务的交接方式

把内部工作视为预订记录的一部分，而不是私下对话。把每次交接变成一个有负责人和截止日的任务。

保持任务清单聚焦：厨房准备计划（菜单版本、份量、过敏原）、租赁与耗材、人手安排、送货与接入说明、活动周确认事项。

示例：客户周二发来新的平面图。你把它附到预订里，更新布局状态，并把“确认装卸码头通行”分配给周四的负责人。

导致返工和客户不满的常见错误

大多数餐饮问题不是食物问题，而是工作流问题：某个细节被假设、消息被埋没、或有人过早把预订标记为“已确认”。

常见陷阱之一是没有定金就保留日期。你告诉客户档期已给他们，拒绝了其他潜在客户，然后对方就没下文。最后你日程空出一个洞，团队也按照并不存在的预订做了计划。

另一个返工工厂是未锁定基本信息就报价：人数和服务形式未定时就下报价。“50 人”可以意味着盒饭、自助带服务、分盘服务或混合含租赁的方案。每种选择都会改变人力、设备、时间和价格。若过早报价，你要么吞掉成本，要么要求额外费用，让客户感觉被诱导。

菜单变更也是容易让预订出事的地方。如果变更分散在短信和电话中，你会得到多个“最终版”。厨房按一个版本准备，客户期待另一个版本，活动当天你会手忙脚乱。

另外：支付状态和预订状态不应合并。预订可以是日期保留而支付是待定金。如果两者混在一起，员工会以为已确认，开始采购、排班，从而失去按时收取定金的筹码。

要减少错误，要求在推进前有几个检查点：

• 收到定金（或书面同意的到期日）
• 确认人数范围和服务形式
• 一份带时间戳的菜单记录
• 预订状态与支付状态分离
• 在活动前 48-72 小时再次确认物流

在标记“已确认”前的快速检查

“已确认”应意味着你的团队可以无需猜测就去执行。

先核对联系人和地点信息：正确的联系人、当天联系电话、完整地址、送达说明、停车信息和楼宇通行。如果是外场地，确认现场对接人。

接着锁定决定成本与人手的关键数字。如果人数未最终确定，记录一个清晰的范围和客户会确认的日期。服务形式也同样记录。

菜单批准需要一份干净的版本。明确说明哪一版被批准（以及何时），并告诉客户变更截止时间。例如：“Menu v3 于周二批准。允许变更至周五 17:00。”

一个简短的确认清单：

• 核验主联系人、当日联系电话与完整地点信息
• 人数与服务形式最终（或记录范围与确认截止日）
• 保存一份已批准的菜单版本，并标明变更截止时间
• 收到定金并归档支付记录
• 创建内部任务（人手、租赁、准备时间表、送货时间）

示例流程：从第一封邮件到定金到账的企业午餐

一家本地公司发邮件：“下个月 60 人的企业午餐，大约 12:30。”流程从在客户仍有参与感时抓取基础信息开始。

在第一次通话（约 10 分钟）内，你记录日期与送达时间窗、地址与接入说明、人数与饮食需求、服务形式、预算范围、决策人以及任何必需项。

状态从 New inquiry 变为 Qualified。

你在当天制作报价并列明项目：60 份盒饭（两种菜单选择）、沙拉盘、饼干、饮料、一次性餐具、送货与布置。附上实施规则（提前期、变更截止与包含/可选项）。状态变为 Quote sent。

两天后，客户回复：“可以把一半改成素食并加咖啡吗？”你更新菜单选择，加入咖啡服务，并把菜单标为 v2，同时更新报价。状态为 Quote sent（已更新）。

客户当天下午批准 v2。你立即发送 30% 的定金请求，48 小时内到期。付款到账后，预订切换为 Confirmed，厨房获得准备任务。

活动前一天，你的“一眼看清”视图应该显示：

• 预订：Confirmed
• 支付：已付定金（尾款活动时支付）
• 菜单：已锁定
• 生产：已排产
• 送货：司机已分配

在一个界面上，团队能看到活动摘要、人数、最新菜单版本、饮食人数、送货说明、联系人、支付状态和准备清单。

下一步：把流程变成团队会使用的简单系统

先把你的状态和推进一项工作所需的确切信息写下来。目标是形成一条任何团队成员都能按步骤执行、无需猜测的清晰流程。

为每个状态定义两件事：必填字段和下一步动作。“新询盘”在记录日期、人数范围、服务形式和地点之前不算完成。“已发送报价”在保存报价版本并设定到期日之前不算完成。

为重复步骤保留标准模板：接单问题、报价格式、定金请求和与特定版本绑定的菜单批准。

如果你准备把这些放到一个共享系统里，一个轻量级的内部工具能替代电子表格 + 收件箱的组合。AppMaster（appmaster.io）是一个无代码平台，你可以用它构建从询盘到确认预订的应用，带真实数据库、状态逻辑和 Stripe 定金连接，这样批准、付款和菜单版本都会绑定到同一条记录，而不会散落在消息中。