RightTouch股份有限公司

＜已上线服务＞

・因森特湖

RightTouch股份有限公司是一家致力于为企业客户提供AI平台、旨在推动联络中心领域变革的新锐初创企业。该公司曾面临因快速增长导致故障处理资源紧张，以及系统日益复杂导致故障原因排查耗时过长等问题。为此，该公司决定引入SIGQ的AI代理平台“Incident Lake”。通过跨越组织壁垒的信息整合与自动报告功能，旨在消除故障处理中的依赖个人因素，构建一种能够利用有限资源创造更高价值的体制。

■实施前的挑战

• 发生故障时，客户工程师在汇总技术信息的同时向客户进行汇报，这项工作耗费了大量工时

• 故障报告的质量取决于个人的技能和状态，导致报告内容的详细程度和表述方式存在差异

• 由于本公司与集团旗下各公司的基础设施和代码仓库相互交织，一旦发生故障，排查原因的工作便变得十分复杂

■对实施的预期效果

• 通过Incident Lake的信息整合与自动报告功能，减少了解读分散的技术信息及撰写报告所需的工作量，从而构建起能够专注于更高附加值业务的体制。

• 通过AI实现标准化，统一报告的格式和表述方式，从而能够快速提交高质量且不受个人因素影响的故障报告

• 通过Incident Lake的跨组织知识库，打破了信息孤岛，将复杂的系统信息进行结构化处理，从而便于排查故障原因并快速做出决策
  

在快速发展的AI客户服务背后，故障处理的工作量急剧上升

RightTouch股份有限公司是一家于2021年12月从PLAID分拆出来并成立的初创公司。该公司以网络支持平台“QANT Web”为核心，推出了一系列充分利用人工智能、旨在推动联络中心转型的产品，包括基于VoC（客户之声）优化客户服务的“QANT VoC”，以及AI语音客服“QANT Speak”等。

该公司的系统架构采用了GCP+AWS的多云架构。由于是从PLAID分拆出来的，其架构主要分为两个层。

第一点是PLAID提供的KARTE平台。在Web支持平台中，针对最终用户的Web行为追踪，我们正是利用了该KARTE平台。

第二点是RightTouch自主构建的内部平台。关于客户咨询的客服数据——例如电话客服中的VoC内容、咨询经过以及沟通详情等无法通过网络行为数据衡量的信息——均存储于此。在应用程序方面，KARTE平台上的应用程序与基于自主基础设施的应用程序并存，这也是该公司技术架构的一大特点。

此外，该公司还在AI领域持续开展前沿探索，包括将大型语言模型（LLM）整合到以Gemini为核心的产品中、将AI应用于客户声音（VoC）等数据分析，以及对新产品进行原生AI开发等。

随着业务的快速增长，该公司面临的两大挑战是：故障处理资源紧张，以及系统复杂性导致的孤岛化。

首先是故障处理资源紧张的问题。一旦发生故障，客户工程师将担任协调人，与产品团队和业务团队通力合作，共同解决故障并处理客户咨询。然而，在客户工程师人数有限的情况下，既要同时提供其他产品的支持，又要应对突发故障，这给他们带来了巨大的负担。其中尤其耗时的是：需要解读在各种渠道间流传的技术信息，在筛选出必要事实的基础上，用通俗易懂的语言向客户进行汇报。结果，由于资源紧张，导致主动式客户支持以及为业务扩展而构建交付体系等工作被搁置，从而陷入了恶性循环。

第二点是源于系统复杂性导致的“孤岛化”。如前所述，该公司的系统架构横跨多个平台，源代码仓库和Slack频道也分散在多个组织中。因此，发生故障时排查原因十分费时，如果不是既了解PLAID又熟悉该公司情况的成员，有时甚至需要花费较长时间才能解决问题。系统和组织两方面的复杂性，不仅阻碍了信息共享，还导致故障处理变得过于依赖特定人员。

鉴于这些挑战，该公司的客户工程师川下治城就应追求的运营模式发表了如下看法。

“客户工程师是连接技术与业务的稀缺人才。为了最大限度地利用有限的资源，必须通过推进运维自动化，使人员能够专注于应由人处理的领域，并致力于支持AI产品的优化及提供价值。”

汇总分散的信息，并用客户能理解的语言进行汇报

为了解决这些问题，RightTouch决定引入SIGQ的AI代理平台“Incident Lake”。

川下先生对Incident Lake的期待主要体现在以下4个方面。

• 汇总分散在各个地方和渠道的技术信息，并准确筛选出事实

• 基于这一事实，使用客户能够理解的语言进行报告

• 防止出现必须依赖特定人员才能查明原因的、依赖个人的情况

• 切实做好事后复盘，以此防止问题再次发生

“目前，我们特别是在信息汇总和向客户汇报方面花费了大量时间。从可靠性的角度来看，能够将信息发布到状态页面以及向客户进行初步联系所需的时间缩短到何种程度，以及如何确保其准确性，这一点至关重要。”（川下先生）

面对这些期待，Incident Lake将如何回应呢？

Incident Lake 具备将多个组织的数据源进行分组、设置权限后，自动收集并共享与特定事件相关信息的机制。通过这种方式，它既实现了突破组织壁垒的信息聚合，又确保了仅将必要信息传递给相关人员的权限管理。因此，即使 Slack 工作区或 GitHub 代码库在不同组织之间分散，也能强力地聚合信息，消除信息孤岛。

另一个重要特点是利用知识库对知识进行结构化整理和积累。该系统具备这样的机制：即使人类无需手动编写文档，AI也能提取个人化的隐性知识，并将其转化为显性知识。例如，可以通过Claude Code MCP直接保存知识，也可以构建通过GitHub Actions定期更新已保存知识的机制。像这样，无需人工干预即可实现知识管理的自动化，正是Incident Lake的一大优势。

该公司计划通过引入Incident Lake，分阶段推进故障响应的转型。川下先生表示，首先将输入必要的知识和过往事件信息，在不断进行调优的同时，将Incident Lake应用于实际的故障响应中。此外，该公司还计划致力于通过AI实现报告质量的标准化，并加快初期响应阶段的决策速度。

“我们的理想状态是，在整个故障处理流程中充分利用Incident Lake，无需单独查阅各处的文档，仅通过与Incident Lake的AI进行交互，即使是新加入的成员也能顺利开展故障处理工作。”（川下先生）

超越“自己动手做”的诱惑

在引入Incident Lake之前，RightTouch也曾考虑过通过自主开发来解决问题。这是因为公司内部已有数名AI工程师，并且已经通过从GitHub获取源代码并在Slack上轻松提问等机制，在推进利用AI优化业务的工作。

然而，川下先生就未选择自主开发的原因解释道：

“即使通过AI驱动开发成功自主研发了工具，如果不进行后续的持续调优，也无法投入实际应用。此外，要开发出运营一线所需的功能，实际处理故障的经验也是必不可少的。结果，这可能会占用工程师大量的工作时间。”（川下先生）

川下先生回顾道，正是基于这一判断——与其耗费时间和人力开发实用性尚待验证的工具，不如引入由具备故障应对经验的专业企业精心打磨的产品，这样性价比更高——这成为了引入Incident Lake的关键因素。

支撑精干团队的无限可扩展性

谈及该公司客户工程师的未来展望时，川下先生表示，希望专注于提供高水平的支持，以向客户传递AI产品的价值。具体而言，将由深入了解客户实际业务情况的负责人，针对每位客户进行最优化的调整，协助客户充分挖掘AI产品的价值。川下先生描绘的理想蓝图是：由此不仅能推动业务增长，还能促进产品本身的精益求精。为此，川下先生表示，公司将致力于招聘那些虽稀缺但兼具商业与技术双重造诣的高端人才。

最后，川下先生向面临类似问题的企业提出了建议。

“坦率地说，与其自己摸索运营方法，不如毫不犹豫地利用SaaS服务。我认为，事件响应的流程在各家企业中都有很多共通之处。将公司的做法与能够预期达到一定绩效的最佳实践相结合，不仅更高效，还能期待取得更好的成果。”（川下先生）

人员数量的增加与业务的增长并不一定成正比。特别是在业务呈指数级增长的初创企业中，能够提供无限可扩展性的SaaS服务，是解决人力短缺问题的有力武器。SIGQ今后也将继续通过Incident Lake，为该公司快速增长的产品提供支持。