会员问了一句“我的订单怎么了”，客服真正要做的却不止回复一句话：认出会员、打开另一个后台、查订单、收材料、联系相关人员、等待结果，再回到聊天里说明情况。重复劳动藏在这些来回切换和等待中。

SRICH CHAT 从自有会员业务的实际服务场景出发，面向有自己网站和业务系统的 iGaming 运营商，提供独立部署的 AI Agent 客服系统。我们希望把会员沟通、业务查询、固定流程执行与人工接待放在同一条服务链路里。

运营需要解决的三种成本

反复解释。 相同规则被不同客服重复回答，内容更新后又容易出现不同口径。FAQ 保留业务方认可的答案，关键词检索可以独立工作；语义检索是可配置的增强。

反复搬运。 会员编号、订单、水单和业务结果在聊天与后台之间移动。看板把数据带到会话旁，操作把经过授权的业务动作带到工作台，专岗员工接下已有明确步骤的任务。

反复找研发。 换品牌颜色、改卡片、调整常用字段都排一次开发，会拖慢运营。页面与消息样式提供配置及 AI 辅助设计；运营预览确认后应用，变化留在客服系统这一侧。

这些成本加在一起，才是我们做专门的 AI chat 产品的原因。单独加一个聊天框，或让模型更会说话，都不能自动省掉查单和跟进这几步。

一套系统，各自负责什么

组成负责的工作运营获得的结果
实时聊天基础会员身份、消息存储、重连补齐服务记录与处理过程能接续
FAQ已确认知识与可检索问法重复咨询按统一口径回答
Runtime任务状态、步骤、能力调用和结束条件工作按已发布流程推进
AI Agent受控岗位中的具体任务收资料、查结果和固定跟进减少人工重复操作
人工客服复杂问题、判断与异常继续处理需要人的问题有人看得见、接得上

人工仍在共享会话里。系统没有把“AI 说了一句话”当成“问题已经解决”的证据；是否办成，要看对应业务结果。

怎样衡量值不值得

上线前先记录重复咨询量、任务处理量、人工介入次数、平均处理时长和每班人员配置；上线后在相近业务量与服务标准下对比。业务增长、班次覆盖和异常比例都要一并看。

产品负责人提供过另一套采用相近 Runtime 方式的实际使用反馈：人员配置约减少三分之二。这是特定场景的反馈，不是 SRICH CHAT 客户总体统计，也不是每个部署的保证。（实际需要根据自己运营需要进行配置。）

如何开始

先把会员身份与聊天接通，再按需要连接知识源、看板和操作，最后启用完成联调的专岗员工。看板、操作、知识库、事件、信息、红包、外部系统写邮箱和会员查询都涉及买方开发配合；查询复用已接好的看板。AI 服务、对象存储与 Telegram 也各有前置。

我们的目标，是让运营在自己的品牌和业务里用得起来，并且能说清自动化替谁做了哪一步。

产品与对接入口

本文为 2026-09-22 整理的公开说明；功能使用取决于已部署版本、配置和对接情况。接口实现以对应版本的帮助中心契约为准。