# 官网右下角挂一个售前客服组件：访客还没加企微，也能先问 AI

来源: https://www.likelic.com/blog/website-widget-pre-sales.html

货代公司的官网，经常会遇到这样一类访客。
--------------------

他还没有加销售企业微信，也没有进客户群，只是在网站上看产品、看服务，然后突然产生一个问题：

> 你们能不能做美国线？

> 这个系统适合报关公司吗？

> 怎么申请试用？

> 你们支持哪些业务类型？

如果官网上只有一个电话号码或者“联系我们”按钮，这个访客接下来可能有两个选择：

**主动加销售。**

或者：

**直接关掉网页。**

立刻智能体的网页组件，解决的就是中间这一段。

在自己的官网右下角放一个悬浮客服按钮。

访客有问题时点开，

直接和企业自己的 AI 智能体对话。

它更像官网里的第一名“售前客服”
----------------

网页组件最适合的，不是已经合作多年的老客户。

而是：

**还没有进入企业私域的访客。**

例如一个潜在客户通过搜索引擎进入货代官网。

他可能正在看：

1.  海运服务
2.  空运服务
3.  报关服务
4.  软件功能
5.  产品价格
6.  试用说明

这时候，他脑子里可能只有一个很简单的问题：

> 你们这个能不能做？

如果为了得到答案，还需要先：

**找联系电话 → 加微信 → 等销售通过 → 再重新描述一遍问题**

这个转化链条其实很长。

网页组件的作用，就是把第一轮沟通留在官网里完成。

访客不需要登录。

也不需要先成为微信好友。

点开右下角的客服入口，就可以直接提问。

访客问的，还是企业自己的智能体
---------------

网页组件本身不是另外一套独立客服系统。

它只是立刻智能体的一种接入渠道。

也就是说，企业在立刻智能体里已经维护好的：

**知识库、智能体设定以及绑定技能，**

都可以继续成为官网客服回答问题时的能力来源。

例如知识库里已经维护：

> 如何申请试用？

> 支持哪些业务类型？

> 软件如何收费？

> 系统在哪里下载？

访客在官网问到这些内容时，AI 就可以根据企业自己的资料回答。

如果当前智能体还绑定了相应技能，也可以在上线前使用真实问题进行验证。

所以企业不需要为了官网客服再重新维护另一套知识。

核心仍然是：

**同一个智能体，通过不同渠道提供服务。**

接入方式，比自己开发一套聊天窗口简单得多
--------------------

网页组件的目标，就是让企业能够比较轻量地把 AI 客服放进自己的网站。

创建好网页组件以后，将对应嵌入代码放到网站页面中。

网站上就可以出现悬浮客服入口。

例如可以把它配置成：

**官网售前客服**

访客点击以后，即可展开聊天窗口。

这种方式更适合：

**我要快速在官网放一个 AI 客服入口。**

而不是为了一个聊天窗口，再单独开发：

前端页面、会话接口、鉴权、聊天记录以及人工接待逻辑。

一个很重要的安全细节：嵌入代码里没有 API Key
--------------------------

企业在把第三方能力嵌入网站时，经常会担心一个问题：

**网页源代码里会不会暴露接口密钥？**

立刻智能体网页组件的嵌入代码：

**不包含 API Key。**

网页组件使用的是组件自己的：

`widget_token`

进行鉴权。

所以它并不是把开放 API 的密钥直接写进浏览器端代码。

这点尤其重要。

因为网页代码最终需要发送给访客浏览器。

如果把真正的 API Key 暴露在前端，本身就是非常不合理的做法。

网页组件因此采用的是自己独立的组件鉴权方式。

网页组件，也不是偷偷调用 `/api/v1/chat`
---------------------------

这一点同样容易混淆。

立刻智能体还提供开放 API。

开发者可以通过：

`/api/v1/chat`

把智能体能力集成进自己的业务系统。

但：

**网页组件不是通过这套开放 API 工作的。**

它有自己独立的接入链路。

因此系统设置里的：

**“AI 会话”开关**

以及：

**v1 API 白名单**

并不会直接影响网站上的组件访客。

简单理解：

**网页组件是一条渠道。**

**开放 API 是另一条渠道。**

不要因为两者最后都能和智能体对话，就把它们当成同一套接口。

只给组件用的 Key，不一定要进开放 API 白名单
--------------------------

有些配置场景里，某个 Key 可能只是配合网页组件完成：

**统计**

或者：

**转人工**

等相关用途。

如果这个 Key 并不用于调用开放 API，

就没有必要因为网页组件而把它加入 `/api/v1/chat` 的开放 API 白名单。

这个区别看起来比较技术化，

但对于实际部署很重要。

否则企业很容易为了“让组件能用”，把不需要开放的接口权限一起放开。

正确的理解应该是：

**组件按组件的规则配置。**

**开放 API 按开放 API 的权限控制。**

两边不要混着处理。

基础版没有网页组件
---------

网页组件并不是所有套餐都提供。

当前规则是：

**基础版：不提供网页组件**

**专业版：最多 2 个**

**旗舰版：最多 10 个**

为什么需要多个网页组件？

因为一家企业可能不止一个网站入口。

例如可能有：

**公司官网**

**产品官网**

**某个专题落地页**

甚至不同站点希望配置不同的智能体、不同的欢迎方式或者不同的人工接待策略。

专业版最多可以建立 2 个。

旗舰版最多可以建立 10 个。

具体套餐能力仍以立刻智能体控制台和帮助中心为准。

新建完以后，别忘了打开“功能开关”
-----------------

创建网页组件时，可以先填写一个便于自己识别的名称。

例如：

**官网售前客服**

或者：

**国际物流官网客服**

但创建完成，并不意味着网站上立刻开始提供服务。

还需要在对应组件配置中打开：

**功能开关。**

只有功能处于启用状态时，

网站上的组件才会正常显示和工作。

这一点很适合在上线前作为检查项。

因为有时候代码已经部署，页面上却看不到客服入口，

原因未必是网站代码错了，

也可能只是组件本身没有启用。

要不要显示“人工客服”按钮，可以自己决定
--------------------

AI 不一定需要承担所有问题。

特别是售前阶段，很多客户聊到最后会进入：

**报价**

**商务谈判**

**定制需求**

**复杂方案咨询**

这些事情最终还是可能需要销售或者客服人员参与。

因此网页组件可以配置：

**是否显示人工客服按钮。**

如果企业希望：

AI 先处理第一轮常见问题，

需要时用户再主动找人工，

就可以打开人工入口。

如果当前企业还没有安排人工坐席，

也可以暂时关闭人工按钮。

所以组件并不是强制要求：

**AI + 人工必须同时出现。**

企业可以根据自己的客服流程决定。

还可以在 AI “答不上来”时自动转人工
--------------------

比让访客自己点“人工客服”更进一步的方式，是：

**根据 AI 的回答自动判断是否应该转接。**

例如企业可以设置一类拦截短语：

> 无法回答

> 暂时没有找到相关信息

> 建议咨询人工客服

当 AI 的回答中出现这些指定短语时，

组件可以触发自动转人工。

这样就形成一个比较自然的流程：

**AI 能回答 → AI 继续处理**

**AI 无法可靠回答 → 转人工**

而不是要求访客自己发现：

“这个机器人已经答不上来了，我是不是应该再找个人？”

拦截短语也可以自己配置
-----------

不同企业设计智能体提示词的方式不一样。

有人可能要求 AI 在没有知识时回答：

> 暂无相关资料。

有人可能写成：

> 当前知识库无法确认。

也有人统一要求：

> 建议转人工确认。

因此自动转人工的拦截短语可以自定义。

企业可以让它和自己的系统提示词配合。

例如你已经在智能体里规定：

**知识库没有可靠答案时，必须回复“建议联系人工客服确认”。**

那么就可以把相应文字配置为转人工触发条件。

这样 AI 在无法确认时：

不是继续猜，

而是把会话交给真人。

不配置拦截短语，也可以使用默认规则
-----------------

如果企业暂时不想自己设计这一套短语，

也可以留空。

留空时使用系统默认的拦截短语逻辑。

对于刚开始上线 AI 客服的企业来说，

可以先使用默认配置，

等实际积累一段时间的访客对话以后，再根据真实问法调整。

例如观察：

客户最常在哪些问题上需要人工？

AI 什么情况下容易回答不完整？

哪一种转接提示对客户最自然？

有了真实对话，再优化会比上线第一天就设计一套非常复杂的规则更实际。

转人工之后，人工在哪里接？
-------------

当网页组件开启人工客服能力以后，

需要人工处理的访客会话，可以进入：

**访客协助**

相关流程。

坐席可以在控制台接入对应会话。

这时候整个过程就从：

**AI 自动服务**

切换为：

**真人继续沟通。**

对访客来说，他不需要重新跳到另一个网站，也不需要把前面的问题全部再说一遍。

官网聊天窗口仍然是同一个入口。

这也是网页组件相比单纯放一个“添加微信”二维码更适合承接即时咨询的地方。

还可以打开“追问气泡”
-----------

很多访客进入网站以后，并不会主动点击客服。

他可能只是：

浏览页面，

停留十几秒，

然后离开。

网页组件可以配置：

**追问气泡。**

也就是通过一个更加主动的提示，引导访客开始对话。

不过这里有一个前提：

除了网页组件自己的相关设置之外，

还需要在系统设置中打开：

**全局追问。**

两边配合后，追问能力才能真正生效。

所以如果已经打开组件配置，却发现网站没有出现预期的追问提示，

也需要检查系统级开关。

对货代官网来说，追问内容最好别太“客服腔”
---------------------

例如访客正在查看货代软件介绍页。

如果突然弹出一句：

> 尊敬的客户您好，请问有什么可以帮助您的吗？

其实很容易被忽略。

更适合真实业务场景的方式可能是：

> 想了解系统是否适合你的业务？可以直接问我。

或者：

> 海运、空运、报关系统怎么选？可以直接问。

甚至：

> 想申请试用？直接告诉我你的业务类型。

核心是让访客快速知道：

**这个按钮能解决什么问题。**

而不是只告诉他：

“这里有一个客服”。

当然，具体话术仍然应根据企业自己的实际业务配置。

上线前，最好别只测试“你好”
--------------

网页组件部署完成以后，一个很常见的问题是：

技术人员点开窗口，

输入：

> 你好

机器人回复：

> 您好，请问有什么可以帮助您？

然后就宣布：

**测试通过。**

但这只能证明：

聊天窗口能打开。

并不能证明真正的售前场景可以工作。

更合理的测试方式应该使用客户真实会问的问题。

例如：

> 你们支持海运出口吗？

> 报关公司可以用吗？

> 怎么申请试用？

> 软件多少钱？

> 系统能不能管海外代理费用？

这些问题能够验证：

**知识库有没有相关内容**

**智能体有没有正确理解问题**

**回答是否符合企业口径**

**没有答案时会不会乱编**

这才是真正的上线测试。

如果智能体绑定了技能，也要顺手测试一次
-------------------

如果作为官网客服的智能体已经绑定了一些实时查询技能，

上线前最好也验证对应能力。

例如：

> 今天美元兑人民币汇率是多少？

或者：

> 不锈钢保温杯的 HS 编码是什么？

这样可以确认：

从网页组件进入的访客，

智能体是否能够正常完成技能调用和结果回复。

所以测试不能只覆盖知识库。

应该根据这个智能体实际绑定的能力来验证。

桌面端能用，不代表手机端就一定没问题
------------------

货代官网现在的访问来源，不可能全部来自电脑。

很多客户会直接通过：

微信链接、

搜索结果、

同事转发，

在手机浏览器里打开网站。

因此网页组件上线前至少应该分别检查：

**电脑端**

和：

**手机端。**

重点看几个地方：

客服悬浮按钮会不会挡住网站原有内容？

展开以后高度是否正常？

输入框能不能用？

返回、关闭是否自然？

文字会不会太小？

人工客服入口是否正常？

如果网站本身还有其他悬浮按钮，例如：

**电话**

**微信**

**返回顶部**

更要检查几个按钮之间有没有互相覆盖。

网页组件和企微机器人，解决的不是同一个入口问题
-----------------------

前面几篇文章一直在讲企业微信外部群。

那么可能有人会问：

**已经有企微机器人了，为什么还需要网页组件？**

因为两者面对的人群不一样。

企微机器人更适合：

**已经进入企业微信沟通体系的客户。**

例如客户已经在外部群里。

他要查订单、要文件、问业务规则，

直接在群里 @ 机器人最自然。

而网页组件面对的更多是：

**还没有进群的人。**

他可能甚至还不知道你们销售是谁。

所以可以简单理解成：

**官网访客 → 网页组件**

**已经进企微群的客户 → 企微机器人**

两个入口可以使用同一套智能体能力，

但服务的是客户旅程中的不同阶段。

典型的官网售前场景，可以是这样的
----------------

假设一个货代老板通过搜索进入立刻云官网。

他看了一会儿以后问：

> 你们这个系统支持空运出口吗？

网页右下角的 AI 客服根据知识库回答。

他继续问：

> 能不能申请试用？

AI 根据企业已有说明告诉他申请方式。

接着客户问：

> 我们公司业务比较特殊，还要和海外代理对账，这种能不能做？

如果知识库中已有明确答案，AI 可以继续回复。

如果无法确认，

系统根据配置识别到对应拦截短语，

自动转给人工。

于是整个过程变成：

**访客先问 AI**

↓

**标准问题自动回答**

↓

**复杂问题交给人工**

销售不用从每一句：

“你们是什么系统？”

开始重复解释。

更值得人工参与的部分，

留到客户真正产生明确需求以后再处理。

网页组件最大的价值，不是“网站多了一个聊天框”
-----------------------

如果只看表面，

网页组件不过是在官网右下角增加了一个按钮。

但真正有价值的，是这个按钮后面连接的东西。

它连接的是：

**企业自己的知识库**

**企业自己的智能体**

**已经配置好的技能**

以及：

**需要时可以接入的人工客服。**

这样官网不再只是：

**展示信息。**

而开始能够：

**回答问题。**

过去访客看完官网以后，还需要自己决定下一步去哪里找人。

现在则可以在产生问题的那个瞬间，

直接开始沟通。

不同渠道，不必重复建设一套 AI
----------------

如果企业以后同时有：

官网、

微信公众号、

企业微信、

自己的业务系统，

最麻烦的方式，是每个渠道都单独做一套机器人。

每个机器人都有自己的知识，

自己的回答规则，

自己的维护方式。

这样最终一定会出现：

官网回答 A，

企微回答 B，

公众号又回答 C。

立刻智能体更希望解决的是：

**智能能力统一维护，渠道按需要接入。**

知识库仍然是一套。

智能体仍然是一套。

只是客户从不同入口进来。

官网访客通过网页组件。

企业微信客户通过企微机器人。

自己的系统如果需要深度集成，则可以使用开放 API。

网页组件和开放 API，应该怎么选？
------------------

如果你的需求只是：

**在官网右下角快速放一个 AI 客服窗口，**

优先使用网页组件。

因为组件本身已经处理了前端交互和渠道逻辑。

而如果你的需求是：

**把智能体深度集成到自己的产品页面、业务系统或者自定义流程里，**

那更适合使用：

**开放 API。**

两种方式解决的是不同层级的问题。

可以简单记成：

**要现成客服窗口 → 网页组件**

**要自己设计交互和业务流程 → 开放 API**

最后
--

很多货代企业做官网时，重点往往都在：

页面设计得好不好看，

产品介绍够不够完整，

案例有没有放齐。

但一个潜在客户真正进入网站以后，最关键的时刻往往只有几秒钟：

**他突然有了一个问题。**

如果这个问题可以马上得到回答，

对话就可能继续。

如果必须先找联系方式、加好友、等人工，

有些访客可能就离开了。

所以网页组件看起来只是一个很小的入口。

它解决的却是官网里非常现实的一段链路：

**客户产生问题的那一刻，先把对话接住。**

能由知识库解决的，让 AI 回答。

AI 无法确认的，再转给人工。

已经进入企微群的客户，则继续在他们熟悉的群里查单、答疑。

不同渠道各自做最适合自己的事情，

背后仍然使用同一套企业智能能力。

这可能才是一个官网 AI 客服真正应该有的样子。

### 相关链接

1.  [网页组件](https://agent.likelic.com/help?a=web-component)
2.  [渠道总览](https://agent.likelic.com/help?a=channels-overview)
3.  [访客协助](https://agent.likelic.com/help?a=handoff)
4.  [开放 API](https://agent.likelic.com/help?a=api)