构建美甲沙龙 Web 应用：预约、支付与客户历史

定义目标、用户与范围

在选择工具或设计界面之前，先明确沙龙要解决的问题。大多数美甲沙龙并不需要在第一天把“所有功能”都做全——他们需要一个能消除日常摩擦的系统。

从要解决的问题开始

把团队经常抱怨的重复问题写下来，并把它们转成目标。常见问题包括：

• 重复预订（double-bookings） 来自纸质便签、私信和电话的混乱
• 支付错漏或不匹配（现金 vs 卡、小费未记录、押金忘记）
• 客户备注丢失（过敏、偏好形状、“别安排我找 X” 等）

越具体越好：用“停止重复预订”比“改进排期”更明确。

确认用户（以及他们各自需要什么）

一个美甲沙龙 Web 应用通常服务四类人：

• 店主/经理： 需要可见性（销售、爽约、员工表现）和控制权（定价、政策）
• 前台： 需要快速预订、简便改期和清晰的日历视图
• 美甲师： 需要自己的日程和客户备注——但不应能访问敏感的管理设置
• 客户： 希望自助预约、收到确认和便捷的复约方式

以最忙的时刻来设计：比如一位到店客户 + 两个电话同时响 + 结账的高峰场景。

定义范围：必须有 vs 可择期

首个版本优先：

• 服务菜单 + 时长 + 定价
• 预约预订/改期 + 爽约政策设置
• 支付基础（可选押金）+ 收据
• 客户资料 + 服务历史 CRM 备注

后续可以再考虑：会员制、库存管理、多门店、进阶营销自动化。

选择要跟踪的成功指标

选取可衡量的结果，比如：

• 降低爽约率（例如在加入押金/提醒后下降 20%）
• 加快结账速度（例如平均低于 60 秒）
• 提高复约率（例如 30 天内“再次预订”的比例上升）

这些指标能让开发更有焦点，并帮助决定下一步要改善的点。

为美甲沙龙绘制核心功能图谱

在写第一行代码之前，把沙龙在第一天必须支持的功能和可以后续添加的功能列出来。这样能保持预约系统简单、减少培训时间，并避免功能膨胀拖延上线。

1）预约（在线预约的核心）

从一个同时适合客户与前台的流程开始：

• 在线预约： 选择服务 → 选择技师（可选）→ 选择时间 → 确认
• 到店客人（Walk-ins）： 用最少字段快速新增（姓名 + 服务 + 技师 + 开始时间）
• 改期与取消： 一键更改、自动状态更新，并保留是谁修改的记录
• 爽约政策设置： 是否需要押金、取消窗口、是否对重复爽约者人工审批

确保预订能防止重复预订，并考虑服务时长与缓冲时间（例如客户间清理 10 分钟）。

2）支付（简单且能追踪的支付体系）

支付不必复杂，但要一致：

• 跟踪 刷卡与现金 每笔预约的支付
• 支持 押金（长时服务尤其需要），并在结账时抵扣
• 把 小费 与服务收入分开记录，便于清晰报表
• 生成 收据与发票（邮件与可打印）
• 可选：礼品卡（发放、兑换、余额）

即便之后接入支付供应商，也要让每个预约能被标记为“已付”、“部分支付”或“未支付”。

3）客户历史 CRM（留客引擎）

轻量的客户历史 CRM 应一目了然地显示：

• 访问时间线（日期、服务、技师）
• 偏好（形状、颜色备注、过敏/敏感）
• 常选附加项与重复购买记录
• 可选：照片附件（前/后或灵感参考）

4）运营（店主每天真正用到的）

补全核心功能：服务菜单与定价编辑、基础 员工排班 和内部备注。库存可选但保持轻量，除非你要做完整的进销存管理。

设计简单的数据模型（需要存储什么）

美甲沙龙应用的成败在于信息的存储是否整洁。如果数据模型简单且一致，预约、支付与客户历史会更容易实现且更值得信赖。

必要的核心实体（表）

先从必需项开始，仅在真实痛点出现时再添加：

• Customers（客户）
• Staff（员工）
• Services（服务）
• Appointments（预约）
• Payments（支付）
• Locations（可选）：适用于多门店或多个房间的场景

防止日常混乱的关键字段

少量字段承担大部分运营价值：

• Service（服务）： name、price、duration_minutes，以及 buffer time（缓冲）（例如清理 10 分钟）。缓冲时间能让日历更真实。
• Appointment（预约）： start_time、end_time（或根据时长 + 缓冲计算）、status（booked/checked-in/completed/no-show/canceled）、customer_id、staff_id、location_id。
• Payment（支付）： amount、type（deposit/final/tip/refund）、method（card/cash），以及税费、折扣和与预约的关联。

关联记录：模拟真实行为

要允许一个预约有多条支付记录。例如：线上 $20 押金、到店 $45 结账、$10 小费 —— 如有变动还可能有退款。

因此 Payments 表应允许多条 appointment_id 对应的记录，而不是在预约上只有一个“支付状态”字段。

审计记录基础（以便问责）

即便在小店，也要知道是谁修改了什么。

至少在 Appointments 上存 updated_at 与 updated_by。若需更强的审计能力，可添加 AppointmentChanges 日志：appointment_id、changed_by、changed_at 和简短的 change_summary（例如“时间从 2:00 → 2:30”）。这有助于解决关于爽约、押金与临时修改的争议。

构建预约与日历流程

你的预约流程是美甲沙龙 Web 应用的核心：它应该把“我想做美甲”变成无需反复沟通的已确认时段。

先定义清晰的预约规则

在设计界面前，先确定日历必须强制执行的规则：

• 服务时长： 每项服务需默认时长，附加项可以延长时长。
• 技师技能匹配： 只展示能执行所选服务的技师。
• 营业时间与休息： 阻止午休、清洁时间与非工作日的时段显示。
• 缓冲时间： 可配置的缓冲（例如 10 分钟）用于客户间的清理与准备。

在高并发点击下防止冲突

冲突预防应在两处发生：

1. 浏览时： 仅显示不与现有预约重叠并满足缓冲的开始时间
2. 确认时： 在保存前再次检查可用性。若两人选中同一时段，服务器应干净利落地拒绝第二个请求并提示用户选择其他时间。

面向客户的预约流程

保持流程简单且可预期：

选择服务 → 选择时间 → 选择技师（可选）→ 确认。

如果客户不在意技师，默认“任意可用技师（Any available tech）”以展示更多可选时间。

员工日历流程

员工需要高效。提供日/周视图，让他们能：

• 用几次点击创建预约（服务 + 客户 + 时间）
• 拖拽改期（沿用冲突规则）
• 快速编辑（备注、加项、押金状态）

后续可接入集成（参见 /blog/integrations-calendar-messaging-payments），但先把核心流程做稳。