WordPress 预约插件比较：Amelia、Bookly 与 Booking Calendar

咨询、课程和服务预约可以比较 Amelia 与 Bookly；按日期或时段展示空闲情况并接收预订请求，可以考察 Booking Calendar。比起日历外观，更应优先核对人员与资源冲突、确认和付款规则，以及免费版的实际限制。Booking Calendar 也支持时段预订，不应把它理解为只能按日期预约的工具。

联系表单什么时候不够用

联系表单可以收集希望预约的时间，却未必确认员工或房间当时是否空闲。预约插件会展示可预订的时间、日期或资源，并按预订状态更新可用情况。单人服务与允许多人参加、直到满额的课程，需要不同的容量控制。

先确定预订单位和真正受限的资源。教师的 45 分钟咨询占用人员时间，八人课程占用名额，住宿则在连续日期内占用房间。两名员工共用一间会议室时，即使个人日程互不冲突，也可能发生房间冲突。应检查人员和共享资源是否必须一起控制。

比较候选插件与版本边界

这些边界依据 Amelia、Bookly 和 Booking Calendar 的发行说明。完整产品演示中的功能，不一定包含在免费版内。每项需求都应与已安装版本和准备购买的许可对应。

短信、WhatsApp、支付处理和外部连接服务可能另行收费。Square 等支付服务商也必须支持您的经营国家、币种和业务。插件免费提供支付集成，不代表服务商免收交易手续费。

Amelia：连接员工、服务与预约表单

Amelia 快速入门指南从一名员工、一项服务和一个预约表单开始。在 Amelia > Employees 配置员工与工作时间，再创建分类和服务并分配该员工。不同文档与版本将服务管理入口称为 Catalog 或 Services，请使用安装环境中的对应区域。

1. 填写员工姓名、电子邮件、工作时间和休息日，将默认工作日时间改成真实安排。
2. 设置服务名称、分类、分配的员工、时长和价格。如果员工或服务没有出现在表单中，检查两者各自的 Show on website 开关。
3. 在预约页面添加 Amelia 区块，或当前版本支持的分步预约表单短代码。例如 [ameliastepbooking] 用于嵌入这种表单，使用前应确认版本支持。
4. 在退出登录的窗口提交测试预约，再到 Amelia > Bookings > Appointments 比较日期、员工和状态，并测试批准、修改与取消。

General 设置中的 Default time slot step 必须支持所需时长。如果只出现 30 分钟的步进，无法选择 45 分钟服务和 15 分钟缓冲，应先检查这个全局时间步长。员工独立时区与向客户显示当地时间是不同功能，适用套餐条件也可能不同。

Bookly：检查服务分配与员工日程

Bookly Free 可以作为小型预约流程的起点。需要在线付款、更多员工或服务、高级预约选项时，应比较 Pro 以及购买渠道提供的套餐或附加组件。当前套餐与单独扩展的文档同时存在，要确认自己选择的购买方案实际包含什么。

在 Bookly > Services 设置分类和服务，并分配服务人员。服务文档说明，一项服务需要分类，且至少分配一名服务人员，才会出现在预约表单中。填写价格本身不会启用在线支付，应区分现场付款与通过在线集成付款。

在 Staff Members > 对应员工 > Schedule / Days Off 检查个人可用时间。工作时间指南说明，公司 Business Hours 和 Holidays 会成为新建员工的默认值，但不会自动更改已有员工的安排。如果修改营业时间后，前台可预约时间没有变化，也要查看员工个人日程。

Booking Calendar：只展示空闲，还是接收预订

Booking Calendar Free 支持基础全天与时段预订、通知和审批。独立房间或设备日历、付款、季节性价格及容量功能，应比较相应付费版本。给两个房间设置不同颜色，本身不会建立独立的资源库存。

通过初始向导和 WP Booking Calendar > Settings 配置日期或时间选择、表单与通知，再向页面添加 Booking Calendar 区块或后台生成的短代码。嵌入指南说明，仅显示可用情况与包含预约表单是不同选项。访客看得到日历却无法提交请求时，先检查这一项。

先决定待审批请求是否占用可预约时间。官方功能列表列出 Show Pending Days as Available，即把存在待处理请求的日期仍显示为可用。这样的配置可以在批准其中一项之前收集竞争请求。若业务需要先到先确认，应使用两个会话验证实际行为。先收集再筛选请求，与防止重复预订，是不同的运营方式。

检查时区、缓冲时间与外部日历

检查 WordPress 的 Settings > General > Timezone。采用夏令时的地区，城市名称时区比固定 UTC 偏移更适合处理季节变化；UTC 是协调世界时。如果向客户显示当地时间，应比较预约页面、确认邮件和管理员日历，确保它们指向同一时刻。跨国预约对应不同日期时，要清楚标明时区。

服务时长是实际服务客户的时间，准备或清洁用的缓冲时间也会占用资源，不能被其他预约使用。下图示例从 09:00 开始，服务持续 45 分钟，随后缓冲 15 分钟，之前没有缓冲；下一笔预约从 10:00 开始。实际起始时间还取决于工作时间、时段步长和前后两种缓冲设置。应核对 Amelia 时长与缓冲功能或 Bookly 的 Padding time 所需版本。

一次性的“添加到日历”按钮、定期刷新的 iCalendar 格式 .ics 订阅源，以及会检查外部忙碌事件的同步，是不同机制。连接 .ics 订阅源，不代表立即双向更新。创建一个外部测试事件，检查对应时段何时关闭，以及取消后何时重新开放。如果多个网站同时出售同一资源，还要评估同步延迟期间的竞争预订风险。

分别测试请求、确认与付款

应在准备投入运营的网站上执行以下检查。观看产品演示，不能证明自己的配置已经通过测试。

1. 请求处理：从一项服务和一名员工或一种资源开始。尝试普通时段、休息日和临近下班的时间。客户与管理员记录的日期、时间和容量应一致。
2. 竞争请求：在两个浏览器会话打开同一时段，检查第二个请求是被拒绝、保持待处理，还是按剩余容量接受，确认符合预期规则。
3. 付款状态：使用支付服务商测试模式验证成功、失败和中途放弃。检查是否先确认再付款，以及未付款预约何时释放时段。不要默认包含或启用了自动取消。
4. 取消与改期：检查客户链接的操作截止时间、后台修改、旧时段释放与新时段占用。取消预约不一定自动退款，必须单独核对支付记录。
5. 通知：客户和服务人员应收到正确的请求、批准、改期与取消消息，并使用正确时区。即使网站流量低，也要确认定时提醒在预期时间运行。

预约已经存在但邮件没有到达时，先检查邮件发送与实际投递，不要直接要求客户再订一次。可用时间没有更新或安全检查失败时，在测试环境排查缓存与脚本优化。动态预约和结账响应不能被过期缓存取代。

采用或更新之前，准备数据库与文件备份。检查导出数据是否包括日期、时区、预约状态和付款标识符。迁移时避免新请求分散到两个系统，并将测试环境与真实客户通知、扣款隔离。还应有临时关闭预约页面的方法，能够根据已有预约名单恢复服务或联系客户。