客户反复改预约时间，AI销售如何避免执行旧时间？

改期不是“把下午三点改成四点”

客户先说周六下午，随后改成周日上午，又在群里回复“还是原来吧”。如果系统只保存一个时间，销售、客户、门店和提醒任务可能各自拿着不同答案。预约应至少包含预约ID、版本、时区、开始与结束时间、地点、服务对象、所需资源、确认状态和最后更新来源。

RFC 5545定义的iCalendar格式可表示事件、待办、空闲忙碌等日历信息，并包含UID、开始与结束时间、时间戳和序列号等属性。其中序列号用于表达事件修订顺序。它不是ZigoAI的产品能力说明，也不要求企业采用某种特定日历，但说明“同一个事件持续产生版本”比不断新建无关联记录更可靠。

先区分询问、提议、待确认和已确认

客户状态与预约状态要分开。客户仍是高意向，并不代表某个新时间已经可用；可结合客户状态机安排下一步，但预约是否成立必须依据资源和确认记录。

六步改期闭环：识别、校验、复述、建版、撤销、通知

推荐确认句：“我确认一下：原预约周六14:00取消，改为周日10:30，地点仍为天河门店，对吗？”客户只回复“可以”时，当前对话中必须只有一个待确认方案；若有多个候选，就让客户明确选定具体项。

提醒、派单和会议邀请都要携带预约版本

只更新预约主表仍然不够。旧提醒可能已进入消息队列，旧派单可能已经到达执行人员，旧会议链接也可能留在客户日历中。每个下游任务都应携带预约ID与版本号，并在发送或执行前读取当前版本；发现版本不一致就停止或重新生成。

RFC 6638描述了CalDAV中的调度扩展，包括组织者、参与者、邀请、回复和更新等处理。它可作为理解调度同步的一手参考，但实际使用微信、企微、短信、门店系统或第三方日历时，仍应按各系统接口和权限设计撤销、重试与失败告警。

最终生效门同时检查五项条件

• 时间可用：开始、结束与必要缓冲没有冲突。
• 资源可用：人员、门店、设备或会议室已由可信来源确认。
• 客户已确认：确认指向唯一方案，而不是模糊的“可以”。
• 前置条件完成：必要费用、资料或资格已按实际业务核验。
• 旧版本已撤销：旧占位、提醒、派单和邀请不再可执行。

涉及库存、名额或服务容量的改期，还应参考候补与供给确认方法；支付完成也不能替代资源核验，可继续使用付款核验流程。

三类冲突应立即转人工，而不是继续自动猜测

• 客户在私聊、群聊和电话中给出了互相冲突的改期指令。
• 新时间可用，但价格、人员、门店或原权益是否保留尚未确认。
• 旧版本已进入现场执行、已产生费用或撤销失败。

交接摘要至少包含预约ID、当前版本、旧方案、新候选、客户原话、资源校验结果、已发送的承诺、撤销结果和下一责任人。不能只写“客户要改期”。可用人工接手完整度评分表检查真人是否能够直接处理。

预约记录只保存和展示完成服务所需的信息

预约通常包含联系人、地点、时间偏好和服务对象。《个人信息保护法》第六条要求处理个人信息有明确、合理目的，并采取对个人权益影响最小的方式。不要把完整手机号、家庭地址或与本次服务无关的信息放入所有参与者可见的日历标题和群消息。

跨团队同步时，应按角色显示必要字段并记录访问权限。本文提供一般流程提示，不替代具体业务的法律或安全审查。

验收重点是旧版本有没有真正失效

上线前应在验收清单中覆盖连续改期、跨渠道冲突、跨时区、撤销失败、提醒已入队、资源被抢占和客户未回复等路径。

适用条件与产品边界

本文适用于体验、到店、上门服务、设备勘察和线上会议等一般预约。多人同行、多项目或跨门店改期可能涉及资源重新定价，不能自动承诺原价格、原人员或原权益保持不变。高风险或受特别监管的预约应按对应行业规范处理。

ZigoAI公开页面介绍的是围绕客户问题进行接待、信息收集、意向识别和关键节点转交真人。本文的预约对象、版本号、外部日历、资源校验和旧任务撤销属于实施方法；是否能对接特定日历或派单系统，应以产品说明、演示、试点和合同范围为准，公开方案以当前价格页面为准。

常见问题

客户说“还是原来时间”，AI能自动恢复吗？

只有“原来”唯一指向某个旧版本，且资源重新校验可用时，才能发起恢复确认。已经取消的预约不能仅凭模糊指代表达自动复活。

客户连续发了三个时间，哪个算最终时间？

三个时间都只能先视为候选。AI应列出候选并请客户明确选择一个，再完成资源校验和确认，不能默认最后一条消息就是最终预约。

改期后旧会议链接还能保留吗？

如果链接与原预约绑定，应撤销、更新或明确标记失效；即使是长期会议室，也要同步更新邀请、提醒和执行人员看到的时间。

客户没回复，但销售口头同意了怎么办？

销售应在有权限的系统中记录确认来源、时间和预约版本。高价值、跨团队或容易争议的场景，仍应取得客户可追溯的明确确认。