通过门店预约示例区分营业时间、可选时段与预约成功，梳理智能客服接日历时的确认状态和测试方法。
“有的，周六下午两点可以来。”一句客服回复看上去像预约成功。到店后，前台一查，没有这条记录。这样的落差常发生在演示系统里：聊天助手能读到营业时间，但没有连到实际预约日历，或者读取之后一直没有写入。让访客安心，需要让同一个流程的每一步都说清状态。
营业时间、可选时段、预约成功是三件事
营业时间只是门店开着。可选时段还取决于能服务的人和场地。预约成功要有业务系统生成的确认结果。假设有两名员工，一人只能接咨询，一人能做检测。页面写“周六正常营业”，无法推出两点能做检测。让助手把它目前知道的信息说具体，例如“周六营业。检测位需要前台确认，我可以帮你提交时间意向。”
2026年乌镇峰会的智能体论坛讨论了跨系统协同。预约是个小而典型的场景。聊天、日历和到店核验各用不同系统时，谁提供有效时段、谁写入、谁确认，需要提前说好。
人工接手的设计，可以参考公开主页怎样把咨询分流。
给用户看得懂的状态反馈
产品可以设计为“可选”“已提交”“已确认”三个状态。前台核实以前，页面说明还没有保留时段，给出预计回复时间与改选入口。确认成功后显示日期、城市、服务项和预约凭据。遇到超时，提示“正在核对结果”，以同一业务编号查询，避免反复提交造成双重预订。
跨地区业务还要写清当地时区。显示“14:00”时，在预约摘要里标出是哪家门店的当地时间。改期要显示新旧时间，并等实际写入成功后再发送确认。若合作门店使用不同日历，先选一个能查询并确认结果的门店试点。
规划访客能看到哪些信息时，可以参考个人资料如何分层展示。
用访客和前台各走一遍流程
测试人员在两个手机上同时选择最后一个时段，观察是否只会确认一单。关掉日历接口再发起请求，看界面是否明确等待人工处理。最后用前台账号按预约凭据反查，核对日期和服务项。联系信息按完成预约所需范围收集，展示端避免公开整张日历上的姓名和联系方式。
小店暂时接不了日历，也可以上线“提交意向”和“人工确认”两步，承诺回复时间由门店自己定。访客知道该等谁的消息，前台知道哪一刻算成交，先把这件事做顺，再扩展自动排期。
上线后可以查看预约改期和到店失败的记录，问清访客是在聊天中看到确定语气，还是没收到确认通知。两种问题的修法不同：一个要调整状态和文案，一个要加确认凭据的查询入口。如果日历暂时不可用，页面仍可说明营业时间与人工联系方式，并提示哪一项需要前台核实。这样前台也能按状态处理同一笔请求。