HelpLook/如何将 HelpLook 与 Sendbird 配合使用:聊天 + AI 知识库

如何将 HelpLook 与 Sendbird 配合使用:聊天 + AI 知识库

将 HelpLook 与 Sendbird 连接,通过 AI 可搜索的答案支持应用内聊天和全渠道支持。包含设置步骤、工作流程、示例和常见问题解答。

A作者: Anonymous10 分钟阅读

如何将 HelpLook 与 Sendbird 配合使用:聊天 + AI 知识库

Sendbird 为您提供实时对话层:应用内聊天、短信、WhatsApp、KakaoTalk、语音、视频以及 AI 礼宾。HelpLook 为您提供答案层:一个由 AI 驱动的知识库和帮助台,具备 AI 搜索、无代码创作、SEO 就绪的帮助中心以及可嵌入的小组件。

两者结合使用,可以闭合大多数支持技术栈中未闭合的环节。客服人员和 AI 代理不再猜测,客户在已使用的渠道中获得一致的答案,您的内容团队可以看到哪些问题真正驱动了对话。本文介绍架构、设置步骤、两个实用工作流程,以及这种组合在哪些方面能带来回报——以及哪些方面不能。

为什么将 HelpLook 与 Sendbird 配对使用?

Sendbird product interface

Sendbird product interface.

Sendbird 产品界面。

Sendbird 擅长对话编排和传递。它不是知识管理系统。HelpLook 擅长结构化、可搜索、AI 辅助的内容。它不是消息平台。两者互相弥补了对方的盲点。

这种组合解决的问题:

  • 聊天中的重复问题。 客服人员每天粘贴相同的答案数十次。HelpLook 的 AI 搜索会呈现标准答案。
  • 跨渠道答案不一致。 同一个问题通过应用内聊天、短信和 WhatsApp 到达。一个 HelpLook 单一事实来源让每个渠道保持一致。
  • 客服人员入职缓慢。 Sendbird Desk 中的新客服人员缺乏产品深度。链接的 HelpLook 文章将 10 分钟的解释变成 30 秒的阅读。
  • 从对话到内容没有反馈循环。 聊天记录揭示了文档缺口。HelpLook 的分析和编辑器让您弥补这些缺口。
  • 在不失去人工交接的情况下实现问题分流。 先提供自助答案,当文章无法解决问题时升级到 Sendbird 实时客服。

两个平台如何协同工作

First viewport screenshot of Chat API pricing plans (try Chat free)

First viewport screenshot of Chat API pricing plans (try Chat free).

企业 AI 客户体验平台的首屏截图。

将技术栈视为三层:

  1. 对话层——Sendbird。 适用于 iOS、Android、JavaScript、Unity 和 .NET 的聊天 SDK,以及用于服务器端操作的聊天平台 API。这是消息、审核、翻译、推送通知和交接发生的地方。
  2. 知识层——HelpLook。 帮助中心、内部知识库、常见问题解答、产品手册和故障排除内容,全部可通过 AI 搜索进行搜索,并可通过小组件嵌入。
  3. 桥接层——您的集成。 少量胶水代码,让 Sendbird 客服和机器人可以查询 HelpLook 内容,并让 HelpLook 捕获客户实际询问的内容。

两个产品之间没有单一的官方“一键式”连接器。集成由双方文档化的原语构建:一端是 Sendbird 的平台 API 和 Webhook,另一端是 HelpLook 的已发布内容和小组件。这是好消息——这意味着您可以从小处着手。

先决条件

在连接任何东西之前,请确认您拥有:

  • 一个 Sendbird 应用,包含其 Application ID 和 API 请求 URL,可在 Sendbird 仪表板的 Settings > Application > General 下找到。
  • 用于服务器端调用的 主 API 令牌 或 辅助 API 令牌。切勿将这些令牌发送到客户端应用。
  • 一个 HelpLook 工作区,至少有一个已发布的帮助中心或知识库,并为您的文章定义了 URL 结构。
  • 一个服务器端环境(Node.js、Python 或类似环境),您可以在其中托管桥接逻辑。
  • 对范围的决策:仅客服辅助、仅机器人回答,或两者兼有。

设置:逐步连接 HelpLook 和 Sendbird

Sendbird product interface

Sendbird product interface.

Sendbird 产品界面。

第 1 步——发布并构建您的 HelpLook 内容

集成质量受内容质量限制。在接触 Sendbird 之前:

  • 按意图而非内部团队对文章进行分组。“重置密码”胜过“账户模块 v2”。
  • 每个问题写一个标准答案。重复内容会混淆 AI 搜索和客服人员。
  • 添加稳定、可预测的 slug,以便您的桥接代码能够可靠地构建文章 URL。
  • 保持标题简短且以问题形式呈现——它们同时可作为聊天中的建议回复。

第 2 步——选择您的集成模式

三种模式覆盖大多数团队:

模式 功能 工作量 最适合
客服辅助侧边栏 客服人员在 Sendbird Desk 工作区内搜索 HelpLook 低 拥有人工客服的支持团队
机器人答案查找 Sendbird 机器人查询 HelpLook 并回复文章链接或摘要 中 高容量、低复杂度问题
主动式小组件 在应用内与 Sendbird 聊天一起嵌入 HelpLook 小组件 低 对话开始前的自助服务

大多数团队从客服辅助开始,然后在内容覆盖得到验证后添加机器人查找。

第 3 步——对 Sendbird 的服务器端调用进行身份验证

所有聊天平台 API 请求都发送到如下形式的基础 URL:

https://api-{application_id}.sendbird.com/v3

每个请求需要两个标头:

Content-Type: application/json
Api-Token: {master_api_token or secondary_api_token}

日常操作使用辅助 API 令牌,将主令牌保留用于令牌管理。主令牌无法撤销或更改,因此请将其视为紧急凭证。

一个用于创建或查找用户的最小 Python 调用如下所示:

import requests

api_headers = {'Api-Token': '{secondary_api_token}'}
data = {'user_id': '{user_id}', 'nickname': '{nickname}'}
res = requests.post(
    'https://api-{application_id}.sendbird.com/v3/users',
    headers=api_headers,
    json=data,
)

对路径参数中的任何非 ASCII 或特殊字符进行 URL 编码。例如,user_id@email.com 变为 user_id%40email.com。

第 4 步——构建查找桥接

在 HelpLook 端,为您的桥接暴露一个可搜索的界面。根据您的计划和设置,这可能是一个搜索端点、一个已发布文章索引,或您维护的一个将关键词映射到文章 URL 的轻量级服务。

在 Sendbird 端,桥接做三件事:

  1. 接收入站消息或客服查询。
  2. 对 HelpLook 内容运行搜索。
  3. 返回给客服的建议回复,或包含顶部文章链接和一行摘要的机器人消息。

保持响应简短。聊天气泡不是文档页面。发送标题答案加链接,而不是 900 字的文章。

第 5 步——添加 HelpLook 小组件以实现自助服务

将 HelpLook 小组件嵌入到 Sendbird 聊天所在的同一应用或 Web 界面中。将其放置在客户可以在开始对话之前进行搜索的位置——例如,聊天启动器旁边的帮助图标上。这是您将部署的最便宜的问题分流方式。

第 6 步——对交接进行监测

明确定义升级规则。常见模式:

  • 机器人用 HelpLook 文章回答。
  • 如果客户回复“那没有帮助”,或者对话超过两轮仍未解决,则路由到 Sendbird Desk 中的人工客服。
  • 将文章 ID 和客户的原始问题传递到客服的上下文中,这样他们就不必要求客户重复。

第 7 步——闭合内容反馈循环

从 Sendbird 导出对话数据,并每周对照您的 HelpLook 分析进行审查。寻找:

  • 没有匹配文章的问题。
  • 被链接但从未解决对话的文章。
  • 发布后激增的主题。

这些都是内容任务,而不是支持任务。

实际示例:应用内订阅问题

客户打开您的移动应用并点击聊天。他们输入:“如何从月度计费切换到年度计费?”

  1. Sendbird 接收消息。
  2. 您的桥接在 HelpLook 中查询“从月度切换到年度计费”。
  3. HelpLook 返回标准文章 更改您的计费周期。
  4. 机器人回复:“您可以随时在设置 > 计费中切换。这是 60 秒的演示:[链接]。需要我为您连接人工客服吗?”
  5. 客户无需客服即可解决。如果他们点击“连接我”,Sendbird Desk 会路由到人工客服,并已附上文章。

结果:一次对话,零客服分钟,以及一个干净的数据点,表明该文章有效。

实际示例:复杂案例中的客服辅助

客户报告与第三方工具的集成失败。客服人员不了解该工具的特殊性。

  1. 客服人员使用错误代码从侧边栏搜索 HelpLook。
  2. HelpLook 的 AI 搜索返回一篇故障排除文章以及两篇相关的设置指南。
  3. 客服人员在 Sendbird 对话中分享文章链接,并引导客户完成第 4 步。

结果:客户在一轮内获得准确答案,而不是三轮,客服人员在解决案例的同时学习了产品。

每个平台应各司其职的地方

聊天 API 定价计划的首屏截图(免费试用聊天)。

任务 负责方
实时消息传递、在线状态、已读回执 Sendbird
审核、翻译、推送通知 Sendbird
跨短信、WhatsApp、KakaoTalk 的全渠道路由 Sendbird
帮助内容的创作、版本控制和结构化 HelpLook
对您自己的文档进行 AI 搜索 HelpLook
SEO 优化的公共帮助中心 HelpLook
升级规则和客服交接 Sendbird(带有 HelpLook 上下文)

不要试图让 Sendbird 成为您的 CMS,也不要试图让 HelpLook 成为您的消息传输工具。价值来自它们之间的接缝。

常见陷阱

  • 将主 API 令牌发送到客户端。 聊天平台 API 并非为客户端使用而设计。将令牌保留在服务器端。
  • 在聊天中返回完整文章。 长消息会被忽略。返回答案加链接。
  • 跳过内容清理。 在混乱文档之上的集成只会更快地呈现混乱的答案。
  • 没有升级路径。 困住客户的自助服务比没有自助服务更糟糕。
  • 忽视反馈循环。 如果对话数据从未到达您的编辑手中,同样的缺口会一个季度又一个季度地持续存在。

相关阅读

来源与进一步阅读

常见问题解答

是否有官方的 HelpLook-Sendbird 集成?

没有单一的打包连接器能端到端覆盖两个产品。您使用 Sendbird 的聊天平台 API 和 Webhook 以及您的 HelpLook 内容界面来构建桥接。设置很小——通常几百行服务器代码。

Sendbird 的 AI 礼宾能否从我的 HelpLook 内容中回答?

Sendbird 的 AI 礼宾处理全渠道自动化和交接。要将其答案建立在您的文档基础上,您需要通过桥接提供 HelpLook 内容作为检索源。礼宾处理对话;HelpLook 提供事实。

如果我只想要客服辅助,是否需要 Sendbird 聊天平台 API?

不一定。如果您的客服人员只是在浏览器标签页或侧边栏中打开 HelpLook,您可以完全跳过 API 工作。当您想要自动查找、机器人回复或将上下文传递到客服视图时,再添加 API。

日常 API 调用应使用哪个令牌?

使用辅助 API 令牌。将主 API 令牌保留用于生成、列出或撤销辅助令牌。主令牌无法撤销或更改,这使得它日常使用风险较高。

如何衡量这种组合是否有效?

跟踪三个数字:升级前的自助解决率、每个已解决对话的平均轮次,以及没有匹配 HelpLook 文章的对话数量。第三个数字是您的内容路线图。

我也可以将 HelpLook 用于内部支持吗?

可以。许多团队运行面向客户的 HelpLook 帮助中心和面向客服的内部知识库。同一个桥接可以查询两者,访问规则决定客服人员看到哪些内容。

结论

First viewport screenshot of The AI customer experience platform for enterprise

First viewport screenshot of The AI customer experience platform for enterprise.

HelpLook 和 Sendbird 解决同一问题的不同部分。Sendbird 推动对话;HelpLook 提供这些对话所需的答案。将它们连接起来需要一个已发布的知识库、一个服务器端桥接、一个辅助 API 令牌和一个明确的升级规则——没有什么奇特的。

从客服辅助模式开始,证明您的内容能回答真实问题,然后通过机器人查找自动化高容量案例。如果您仍在评估知识层本身,在构建之前比较选项是值得的:看看 HelpLook 与托管知识库软件和 Hesk 的对比,或查看我们更广泛的领域 顶级 AI 客户支持软件比较。对于偏好文档即代码上游的团队,HelpLook 和 MkDocs 工作流程 展示了如何在 Markdown 中保持创作,同时发布一个 AI 可搜索的门户。

在构建时作为参考,请保持 Sendbird 文档门户 和 聊天平台 API 准备指南 打开——其中的基础 URL、标头格式和令牌规则是您的桥接必须遵循的。