生成式程序是灵活的对话工作流程,使用专员人工智能来指导人工智能专员在与客户对话期间的响应和操作。

我的服务模式是什么?
所有 Suite: Team、Growth、Professional、Enterprise 或 Enterprise Plus
Support Team、Professional 或 Enterprise

生成式程序是灵活的对话工作流程,在与客户对话期间,使用代理式人工智能来指导人工智能专员的响应和操作。

本文章提供了一些编写和优化程序的最佳实践。创建生成式程序时,请记住这些最佳实践。遵循这些指南有助于您编写更有效的程序。

本文章包含以下主题:

  • 使用清晰、特定的语言
  • 分解复杂的任务
  • 按逻辑顺序显示步骤
  • 定义明确的条件和操作
  • 保持术语一致
  • 避免在一个步骤中组合多个操作
  • 在执行有条件的步骤之前包括反馈请求
  • 请提供有帮助的示例
  • 预测并处理错误
  • 突出显示关键步骤
  • 使用命令式、直接的写作风格
  • 测试、迭代并定期更新

相关文章:

  • 人工智能专员的生成式程序示例
  • 管理生成式程序

使用清晰、特定的语言

用简单、直接的自然语言撰写每个步骤。避免含糊不清的术语、行话、源代码和复杂的句子,以确保人工智能正确解释指令。确切说明需要哪些信息,以避免误解。

此外,用英语写作有助于优化工作流程。但是,所有主要语言的性能仍然相同。

  • 好:“让客户提供 10 位数的帐号。”
  • 不好:“向用户请求帐户信息。” (如果没有更多背景信息,“帐户信息”的含义就不明确。)

分解复杂的任务

将复杂的流程分解为更小、更有针对性的步骤。每个步骤都应代表一个易于管理的操作,以提高透明度和执行力。

  • 好:
    1. “验证客户身份。
    2. 检查帐户余额。
    3. 处理支付。”
  • 不好:“验证身份,查看余额,一步完成支付。”

按逻辑顺序显示步骤

按人工智能应执行的顺序排列指令,反映实际的工作流程。使用编号或结构清晰的列表。

  • 好:步骤如下:问候 → 验证 → 诊断 → 解决/升级
  • 不好:“上报问题后验证身份。”

定义明确的条件和操作

使用明确的“如果……则……”语句,为每个条件以及由此产生的操作或下一步提供精确的说明。这样可以减少歧义,指导决策。

  • 好:“如果支付无法处理,则告诉用户支付出现问题,并要求他们提供其他支付方式。”
  • 不好:“如果支付出现问题,请进行相应处理。”

保持术语一致

在整个程序中,始终对实体(例如服务模式、政策或帐单结算类型)使用完全相同的名称,以避免混淆或误解。一致的命名可防止人工智能混淆术语。要查看已创建的实体,请输入正斜杠 (/) 或单击程序编辑器中的加号图标 (+)。

  • 好:在讨论服务级别时,请务必提及“Premium 服务模式”。
  • 不好:在“Premium 服务模式”、“黄金服务模式”和“顶级订阅”之间切换。

避免在一个步骤中组合多个操作

如果一个步骤涉及多个主要任务,请将其拆分为多个单独的步骤,确保说明清晰明确。这样可以防止跳过任务或误解任务。

  • 好:
    • 第 1 步:确认客户报告的问题。
    • 第 2 步:根据问题类型提供故障排除步骤。
  • 不好:“确认客户的问题,然后提供故障排除,如果未解决则上报。”

在执行有条件的步骤之前包括反馈请求

当您在程序中包含有条件的步骤时,人工智能专员应先问客户一个问题,以确保有条件的步骤可供评估。这有助于防止人工智能专员将相同的回复发送两次。

换言之:告诉 → 询问 → 有条件,而不是告诉 → 有条件。

  • 好:“这是政策。您还需要什么吗?或者,“这回答了您的问题吗?”或者,“如果您对此有任何疑问,请告诉我。”

    这样,有条件的分支仅在用户回复后触发,从而消除了潜在的重复回复。

  • 不好:
    • 第 1 步:人工智能专员会告诉用户一些信息,但不会问用户说明问题。
    • 第 2 步:一个条件分支,仅在用户稍后询问非常具体的跟进时运行。

      由于人工智能专员没有被告知在第 1 步和第 2 步之间等待,它会立即评估含糊条件,找不到可匹配的内容,然后重新发送最后一条消息。

请提供有帮助的示例

包括常见场景的上下文示例,以阐明预期结果并减少歧义。示例指导人工智能的语气和内容。

  • 好:“如果客户说‘我的帐单过高’,回复:“我看到您的费用包括本月的额外数据使用量。”
  • 不好:未提供范例,导致人工智能不确定如何回复。

预测并处理错误

包括错误处理说明,例如数据缺失、不完整或矛盾时该怎么做,以确保稳健性和可靠性。

  • 好:“如果 API 返回“超时”,则最多重试 2 次。如果仍然失败,则升级请求。”
  • 不好:“如果 API 调用失败,请重试。” (没有重试限制或回退。)

突出显示关键步骤

使用大写字母或其他格式技术强调程序中的重要或强制步骤,降低合规或操作错误的风险。

  • 好:“在披露帐户信息之前,请先验证客户身份。”
  • 不好:不强调身份验证步骤。

使用命令式、直接的写作风格

将步骤编写为命令或指令(例如,“检查是否……”、“询问客户……”或“升级请求,如果……”),以避免不确定性和含糊不清。

  • 好:“询问客户的最后付款日期。”
  • 不好:“您可以询问他们最后一次付款是什么时候。”

测试、迭代并定期更新

通过真实互动不断测试程序,收集反馈,并根据政策或客户需求的变化修订步骤,以保持准确性和客户满意度。

  • 好:每月审查程序,并根据客户反馈或政策更改调整步骤。
  • 不好:编写一次,无需修改。

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

由 Zendesk 提供技术支持