构建 Apple Messages 体验
构建客户实际使用的完整对话，从首次请求到任务完成。本指南使用虚构商店 Goldcrest，展示安排到店所需的消息、选项和员工操作。请根据您的服务和支持的语言调整措辞。
在本示例中，客服通过对话和模板执行操作。指定集成负责人，在提交前通过公共回复 API和明确的对话负责机制连接自动欢迎消息与非营业时间回复。在准备这些工作时，手动演练脚本。已保存模板存放消息内容；客服或所连接的服务决定何时发送，并执行预约操作。
1. 明确任务和完成标准
先写明结果，再撰写欢迎消息。本示例的结果为：“The customer has a confirmed store appointment, its reference, and instructions for changing it.” 选择时间只是中间步骤。预约系统必须接受预约，您才能确认。
画出正常流程：请求到店 → 选择服务 → 选择时间 → 预约 → 确认预约 → 提供更多帮助。然后补充更改选择、时间不可用、问题未获回答以及请求人工服务的路径。客户旅程规划示例说明如何为结果分配责任。
为每个步骤写明客户消息、预期回答，以及客服或所连接的服务如何处理该回答。让团队能同时查看这份脚本和已批准的消息文案。
2. 围绕客户请求撰写首次回复
先阅读客户消息以及入口提供的上下文。如果客户写道 “I'd like a styling appointment,”，就继续介绍造型服务的可预约时间。通用欢迎菜单会让客户重复您已理解的请求。
客服可以这样回复：
Hi, I'm Alex from Goldcrest. I can help arrange your styling appointment. Which store would you like to visit?
如果所连接的服务自动回答，请表明其身份：
Hi, I'm Goldcrest's automated assistant. I can help arrange a visit or answer store questions. You can ask for a person at any time.
Apple 要求在 5 秒内发送自动欢迎消息。在设备测试中，从客户发出第一条消息开始测量延迟。支持客户通过 “agent” 和 “help” 等请求获得人工帮助，通过 “menu” 返回可用选项。参阅 Apple 对话设计标准。
显示正在准备回复。 对自动回复和真人客服输入都使用输入指示器。Apple 要求消息序列中的每条消息发送前显示 1 秒指示器。Bird 在发送回复前发出输入信号，客服在对话回复框中输入时也会发出信号。在 iPhone 上演练这两条路径，包括连续发送多条回复，并确保自动欢迎消息在 5 秒内发出。按输入指示器录制步骤操作。
3. 请求不明确时提供实用菜单
对于 “Hello,” 这样的消息，创建快捷回复模板并提出以下问题：
What can we help you with today?
使用明确区分的选项：预约到店、更改预约、订单帮助、门店信息和其他事项。将最常见的请求放在前面。使用客户的语言，并用标签说明下一步会发生什么。避免使用 “Retail operations.” 这样的部门名称。
写明每个回答对应的下一步操作。预约到店询问尚未提供的门店或服务；更改预约查找现有预约；订单帮助转给服务团队；门店信息发送所询问的营业时间或地址；其他事项提供人工服务。同时接受键入的回答。如果回答不清楚，先提出一个具体问题，随后提供帮助，不要反复显示同一菜单。
选项不超过五个时使用快捷回复。如果选项较多，且需要分组、说明或图片，请使用列表选择器。例如，按城市对多家门店分组。说明客户应选择一项还是多项，并通过位置或服务区分相似选项。
4. 构建交互及其备用方式
在交互消息之前发送简短说明：
Choose a time for your styling visit. I'll check that it is still available before confirming your appointment.
根据预约系统的最新空闲时间创建时间选择器。将接收气泡设置为选择到店时间，副标题设置为选择可预约时间。回复气泡使用已选择到店时间。将 “confirmed” 留给预约成功后发送的消息。
在设备上检查可见气泡、展开的交互、已选答案以及折叠后的对话。实用的接收气泡应在客户打开前说明操作。对于带有图片字段的交互功能，在接收和回复气泡中都加入相关缩略图。确保文字可读，并将重要说明放在前一条消息中，使其持续可见。
保持快捷回复摘要简短，并在选择后检查其显示。
为每个交互准备替代方案。本示例中，客服可以发送 “I can offer Tuesday at 10:00 or Wednesday at 14:00, London time. Which works for you?”。发送时使用实际日期和最新时间。如果表单无法打开，逐一询问必要问题。对于较长流程，提供预约页面的富链接。
依赖原生功能前，检查对话中的设备能力。缺少能力信息表示支持情况未知。如果客户反馈选择器无法打开，请转用已准备的替代方案，不要让客户反复重试。
5. 需要时再询问信息
对于营业时间等一般问题，无需收集姓名、电子邮件地址或订单号即可回答。对于预约，等客户选择该任务后，再询问预约流程需要的信息。复用对话中已提供的信息。
一次提出一个清楚的问题，例如 “What is your name?”。如果将多个相关答案放在一起更便于检查，请使用表单。如果某项信息的用途不明确，请说明原因。对于常见信息，使用 “What is your email?” 这样的直接提示，方便设备提供相关建议。对于账户相关请求，在分享私人信息前遵循组织已验证的身份核实流程。
首次互动或隐私政策变更时，以带标题的富链接发送隐私政策。不要将政策正文放进对话脚本。通过富链接提供客户需要的资源，例如产品页面或 Apple Maps 位置。
6. 让人工接管成为实际可用的服务环节
当客户要求人工服务、请求超出助手职责，或操作需要员工判断时，准备转接。告诉客户下一步安排，并给出团队能够做到的预计等待时间：
I'll pass this to our store team. The current wait is about 10 minutes. You can leave Messages and return when we reply.
该等待时间只是示例，请替换为实际服务预期。如果延迟变化，请发送更新，不要让原先的承诺一直未获更正。
在对话中，将对话分配给可用客服。接手的客服应先查看请求、选择和任何失败操作，再回复。如果此前由助手回答，请在移交负责权时暂停助手。仅分配对话不会停止外部助手。
接手的客服应表明已了解上下文：
Hi, I'm Sam from the store team. I can see you chose a Wednesday styling visit. I'm checking that time now.
在非营业时间，回复应包含团队下次开始服务的时间和时区：
Our store team returns tomorrow at 09:00 London time. Send your question here and we'll reply after opening.
明确由哪位客服或哪个连接服务发送该回复。确定团队恢复服务后由谁查看等待中的对话。使用实际负责该渠道的人员测试接管。
7. 处理延迟、变更和不确定结果
客户稍后返回时，阅读已有对话，并确认原请求是否仍然有效。继续操作前刷新时效性选项。例如：“Welcome back. Would you still like a styling visit? I'll check the available times again.” 避免发送催促客户立即回答的闲置提醒。
如果已选时间不再可用，请说明结果并提供新的空闲时间：“That time has just been booked. I can check another time for you.” 保留客户已选的门店和服务，使其无需重新开始。
如果预约系统超时，提交另一请求前先检查是否已创建预约。告诉客户：“I'm checking whether that booking completed. I'll confirm the result here.” 保留预约或工单编号，让客服可以调查，而不必重复操作。
如果客户改变主意，返回相应选项。如果客户想取消现有预约，请在预约系统接受取消后再确认。一条消息回复或一次菜单选择不能证明外部操作已成功。
8. 确认结果并询问反馈
预约成功后，发送实际日期、时区、门店和编号。例如：“Your styling visit is confirmed for 8 October 2026 at 14:00 London time at Goldcrest Covent Garden. Reference GC-1042. Reply here if you need to change it.” 日期和编号均为虚构示例；请使用已完成预约的实际数据。
通过快捷回复提供更多帮助：还有问题和没有其他问题。客户选择答案后，继续相应流程。保持对话可用，以便稍后跟进。
如需收集客户满意度，创建第二个快捷回复模板：“How was your experience with our team today?” 使用满意、一般和不满意等明确选项。在服务任务完成后发送。如果客户表示体验不佳，提供能够帮助的人工服务，并允许客户自愿参与。
确定团队在哪里记录调查答案，以及投诉是否需要跟进。对话中的回答才是反馈来源；投递数量无法得出满意度分数。参阅衡量结果。
9. 审核前演练完整体验
由一人扮演客户、另一人担任客服来运行脚本。使用虚构信息和实际连接的测试商家。使用每种支持的语言重复演练，包括较长的选项标签和客户请求切换语言的情况。切换前先确认客户偏好的语言，然后从任务原位置继续。
| 场景 | 演练必须证明的内容 |
|---|---|
| 明确的请求 | 服务使用已表达的意图，避免不必要的分流。 |
| 不明确或键入的回答 | 菜单和澄清能引导至有用的下一步。 |
| 已完成的预约 | 预约确实存在，且与客户收到的确认一致。 |
| 无法使用的交互 | 文本、网页或客服替代方式能够完成任务。 |
| 任务中途请求人工服务 | 负责权得到移交，上下文得到保留，自动回复暂停。 |
| 服务时间以外的请求 | 回复给出准确的恢复服务时间，团队随后接手工作。 |
| 延迟回复或已过时的时间段 | 服务检查当前意图和可用时间。 |
| 系统超时 | 再次尝试操作前检查原操作的结果。 |
| 不满意的客户 | 反馈得到记录，且可由人工跟进。 |
录制演示前，修正含糊措辞或不通的路径。为体验审核录制客户交互、客服操作和已确认结果。