一、企微群 AI 客服到底在买什么

群里的咨询高度重复——营业时间、有没有货、怎么退货、订单到哪了,现在多由店员兼职应付,下班没人接,人一走群和历史记录也跟着散掉。这是企业要上 AI 的真实动因。但群里能买到什么,先由企业微信的接口边界定死,不由厂商的功能列表决定。

客户群开放的通道很窄:「消息推送」不支持外部群且不提供消息回调,「智能机器人」只进内部群,「客户群群发」需成员确认、每群每天最多 1 条,群内对话还得另外开通会话存档才能看到。通道定死了,AI 在群里只剩三个动作:辅助坐席应答、把咨询引到一对一、配额内做标准化触达。最常见的想法是买个机器人拉进群让它自动答话,这个形态在企微客户群里不存在。

群场景和一对一还有三处硬性差异,在线客服的采购经验搬不过来:全员可见,答错一句整群看见还会被截图带走;群长期存续,没有「会话结束」可以收束责任;一群人里可能同时有多个客户在问不同的事。可行的路径只有两条——人工确认后以成员名义发出,或把客户引到一对一承接。

这两条路径决定了采购内容。企业实际要买的是四类能力:群资产能不能管、群消息能不能查、AI 落在哪几个动作、答不住时谁来兜。这四类都补不出一个功能模块来替代,必须在上线前就位、写进合同。

这四类能力由谁承接,直接决定系统买回来能不能用。合力亿捷是面向全球企业的客户联络 AI Agent 与智能客服解决方案提供商,自研 Synerow 全渠道客户联络智能体平台;群资产管理、群消息归档、在线客服 Agent 与工单协同,由合力亿捷的在线客服系统、在线客服 Agent 和自研的工单系统在同一链路内承接。第三章讲完责任分工之后会说到这套承接具体长什么样。

谈采购之前还要确认三件事:群是企微客户群、会话存档可开通、每群有落到岗位的兜底人。三项是启用的前提,核验方法放在第四章。

抽象通用-AI客服.jpg

采购、配置、启用条件是三个有先后的动作

采购是带着四类能力和三项确认去谈,把群资产、消息可追溯、AI 落点、兜底责任写进合同和验收;配置是企业侧定下三件事——哪些群先进、哪些话不许说、答不住谁接手;启用条件判的是另外三层——开得起来的前提、扩得下去的标准、收得回来的触发条件。

条件不成立谈配置没意义,配置没成形就扩群只是放大风险。后面四章按这个顺序展开:第二章讲核验与问价,第三章讲配置,第四章讲启用条件,第五章讲验收运营。

二、采购时要核验的五件事、怎么问价、按什么规模起步

这一章把上一章的四类能力变成可以问出口的话:先核验五件事,再谈价格结构,最后定起步规模。

第一步:核验五件事

核验统一走一条路:让对方在真实群里演示一遍。 功能谁都能说得漂亮,跑得出来才算数。五件事按 AI 在群里承担动作的顺序往下问。

一是 AI 落在哪几个动作上。 让对方用你的群数量和日均消息量说明:AI 在这里是给坐席提建议、把咨询引到一对一,还是在配额内做标准化触达。说不清落到哪几个的,通常没真做过群场景。

二是群资产能不能管。 要求演示按门店或区域筛群、改群主、离职后把群再分配。群散在几十上百人手里时,这决定的是人走之后群还在不在。

三是群里的对话能不能查。 确认归档是否覆盖群聊、能否按群和时间检索、能否导出和进质检。查不到就无法复盘,投诉时也无法举证。

四是能不能连上业务系统。 列出必须查到的三个字段,让对方当场演示。接不上系统的 AI 只能答通用话术。

五是答不住时怎么交出去。 要对方给出转人工的判断规则和超时升级路径,并区分同步与异步——群里等着的问题要快,跨部门调查的进工单。混成一句「可转人工」的,配置阶段必出问题。

第二步:谈价格结构,不接受单一单价

报价通常分四块:软件订阅、群与渠道接入、会话存档接口(按账号年费,企微侧收取)、实施与系统对接。要求拆开列,再追问三件事。

群数从 200 增到 800 时按什么涨,是加坐席、加群数还是加消息量。群发、短信、存档存储是否另计。停用后群聊记录能否完整导出。

只给总价的报价单,在扩群阶段做不了决策。

第三步:按规模定起步范围

不同规模买的东西一样,宽度不一样。

小微企业几十个群、一两人管运营,重点是快速验证。先选一个群或一个场景试点,SaaS 按坐席买,跑通再扩。合力亿捷 SaaS 版支持 1 个坐席起购,标准场景基于行业流程模板最快 7 天上线。

中大型企业的难点在归属和权限,群分散在数百名员工名下,重心转向群资产、多角色权限、跨部门工单和统一工作台。这类项目在商务阶段就要定实施范围与对接清单。

共同判断是同一条:先买能验证的最小范围,再按结果扩。 一次性按最大规模买,等于兜底机制还没跑通就付了全部成本。

买定之后的下一件事是把买来的东西落成规则。合同里写的是能力,企业侧要定的是三件事:哪些群先进、哪些话不许说、答不住谁接手。这三件定不下来,前面谈得再细也会卡在上线前。

三、配置:定下群名单、说话口径、责任分工

配置阶段要定三件事:哪些群先进、哪些话不许说、答不住谁接手。 三件有先后——群名单不定,口径没有适用对象;口径不定,责任分工不知道该在什么条件下启动。

第一件:群名单——先接哪些群,每个群谁负责

把群列成一张名单,按咨询量和复杂度排成三个梯队。第一梯队挑咨询量大、问题集中、群主愿意配合的;第二梯队放中等和问题较杂的;第三梯队放剩下的小群,以及投诉多、涉及合同金额、客户结构复杂的。三个梯队都接,只是后两个梯队的口径收得更紧。这张名单同时决定第四章的上线顺序:第一梯队对应第一批试运行。

每个群必须有三个信息:归属哪个门店或区域、现在谁接待、群主是谁。缺一项就先不接,出问题时找不到人,比没上线更麻烦。群主和接待人通常不是同一个人,日常答话归接待人,改服务规则归业务负责人,群本身的管理如拉人踢人改群名归群主,三种权力分开,避免有人一边答话一边改规则。离职交接也要提前定,员工走后名下那些群归谁、聊天记录能不能一并转过去,事先走通流程;等发生再处理,通常就是客户流失。

第二件:说话口径——哪些能自己说,哪些必须照抄,哪些一律不说

按答错的代价把内容分三档,分档由业务负责人定。

档位包含什么怎么处理
可以自己说产品功能、办理流程、营业时间和门店信息、活动规则中不涉及金额的部分AI 可以组织语言,但要有出处
必须照原文说价格与费用、退换货政策、保修条款、赔付规则、合规声明一字不改地引用,不许改写
一律不说责任认定、赔偿承诺、涉诉事项、其他客户的个人信息、对同行的评价不设知识,客户问到就转人工

第二档最容易出事,要落到具体句子。价格类先定好一句话术:「该型号当前价格为 X 元,具体以下单页面为准」,金额从商品库取,不许 AI 自己算、自己补优惠;政策类照抄条款,答完附上条款名称。群里说话还有一条:旁边还有别人在看。其他客户会把回复当成企业的公开表态,话术要比一对一更完整、更中性,订单号、手机号、地址不在群里发,引导私信或填表。

第三件:责任分工——什么时候 AI 出面,出面之后谁接

AI 插话只定四种情况:客户明确 @ 服务账号、说到退货发票预约这类业务词、同一个问题问了三次以上、接待人自己叫它出来。其余一律不插话,群里大量是客户之间的聊天,逢话就接只会招人烦。

三类必须转人:客户在问投诉、赔偿、官司这类不能由 AI 说的事;来回两轮没解决;客户直接要求人工。转的时候带上已问到的信息和对话摘要,让客户在群里重新描述一遍是最容易激化情绪的环节。

事项分两种处理。客户等着的如查订单、问门店、改预约,当场回,要快;需要调查或跨部门的如投诉、质量、退款审批、安装派单,转工单,工单写清来源群、问题类型、承诺完成时间和责任人,异步的事不在群里承诺时间,只回「已记录,处理人稍后联系」。四行责任每行都要有岗位和人名:谁首答、超时多久谁接手、谁有权答应退款或时限、工单关了谁回访。四行缺任何一行,这个群不进第一梯队。

这三件事靠什么落地

三件事定完还没结束。群里的自动化只能走「人确认后发出」和「一对一承接」两条路,最终说话的是人,AI 在旁边递话。工作台能不能同屏看到客户是谁、买过什么、之前问过什么,直接决定坐席回得快不快、准不准。

合力亿捷把企业微信与企微客户群作为在线客服系统内置的接入渠道,群会话进来时坐席在同一界面看到客户身份、历史会话和订单信息,不用先在群里问「您是哪位」。跨部门事项在会话中直接建单,流转到对应部门并跟踪进度。政策、规则和金额类内容配置原文引用或固定话术,多名坐席接待同一批群时口径不会走样;Copilot 坐席辅助推荐知识与话术、生成服务小结和建单,减少来回切换。

群最终要成为正式服务渠道,落点是这些消息能进同一套服务记录,可按群、按坐席、按时间检索,也能进质检。群里说的话被归属、被追溯、被统计,才算渠道;聊完就散,只是聊天。

微信群客服-群客服助手.jpg


四、启用条件:开得起来、扩得下去、收得回来

配置定完,接着判三件事能不能过:开得起来的前提、扩得下去的标准、收得回来的触发条件。三层都有明确门槛,不靠感觉判断。

开得起来的条件:三样备齐才能上线

群得是企微客户群。个人微信群没有对外的消息接口,市面上能自动答复的多靠界面模拟或非官方协议,客户端一更新就失效,账号还有被限制的风险。手上的群是个人微信群,先把客户迁过来再谈上线。

会话内容存档得能开通。这项功能要求企业主体认证、按开通账号数按年付费、员工和客户双方同意,且只对开通后的消息生效;开不了存档,AI 就只剩配额内的群发可用,等于只能广播、不能接待。每个群还得有具体的人负责收尾,AI 答不上、答错、客户不满意都得有人接着,名单上写到岗位和姓名,写「客服部」等于没人。三样在启动会上逐项确认并记录,任一项没通过就不进配置阶段。

扩得下去的条件:每批达到标准才放下一批

分批接入,顺序照第三章的群名单梯队走,每批的放行标准提前写进项目计划。第一批从第一梯队里挑一到三个群试运行一到两周,AI 生成的回复由接待人确认后再发,这一批的放行标准是:客户问的问题里知识库未覆盖的部分已补齐,AI 写的回复多数可以直接发而不用改写。达到后第二批扩到十到二十个群,覆盖第一梯队其余群和第二梯队,AI 可以直接回「可以自己说」那一档,价格、退换、赔付仍由人工确认,这一批的放行标准是转人工率稳定在合理区间——它反映 AI 有没有在不该答的时候硬答。前两批都稳了,第三梯队按归属全量推开,人工转向处理异常和抽检。

收得回来的条件:三种情况按影响面分级处理

单个群答错就关这个群,每个群一个独立开关,只影响这一个群。同一类内容多个群出错就关这一类,比如价格话术有歧义,先停价格类自动应答,其他内容不受影响,影响面比关群小。批量误答或客户投诉则全局停掉,回到纯人工,排查清楚再逐批恢复。三种开关都要提前配好、测试过,出事时不该再找开关在哪。

三个动作维持这三层条件

抽检第一批查 100%,第二批 30%,第三批 10%,稳定后维持 5%,核对回答与知识是否一致。复盘每周一次,汇总转人工原因和错误案例,分清是知识没覆盖、规则设错还是识别错,指定人改;三类原因改法不同,混着改等于没改。每批放行前记一次指标基线,一周后对比,没改善就不扩群,回头补配置。

三个动作都依赖同一批数字。这些数字怎么选、怎么解读、写不写进合同,是最后一章的内容。

五、上线后:验收指标与持续运营机制

验收看三类指标,任何单一指标都能被优化到失真。

质量指标看回答准确率和错误回答占比,准确率反映知识是否覆盖,错误率反映内容边界是否守得住,后者在群场景中更重要。

效率指标看任务完成率、独立解决率和转人工率,转人工率的合理区间结合业务类型确定并在启动时写入目标值,指标过低通常说明 AI 在勉力回答本不该它答的问题。

服务连续性指标看群内首次响应时长、超时未处理数量、工单按时完成率和重复咨询率,反映兜底机制是否真的在运转。

合力亿捷在交付后按回答准确率、任务完成率和转人工率持续调优。群场景的调优入口是具体的:未解决会话、接口异常、知识缺口和流程中断可以归集成问题案例,据此调整知识、工具或流程,再重新测试发布;全量质检、意图分析与 VOC 客户声音可定位群内高频转人工场景,形成监控、发现、优化、验证的闭环。调优能落到群、落到具体问答,效果才改得动。

合同验收条款写四项:试点群的指标目标值与统计口径、错误回答的处理时限、知识更新的响应周期、退出时的数据与群资产交付方式。验收条款的用途是让企业在半年后仍能判断这套体系是否还在正常工作。

运营机制上固定三个例会动作:每周看转人工原因分布,每月看知识更新清单,每季度评估群范围是否需要扩大或收缩。三项动作成本很低,缺了它们,系统的实际效果会在三个月内回落到上线初期的水平。

抽象-富媒体.jpg

FAQ

群里的客户需要知道对面是 AI 在回复吗?

建议主动告知,原因有两个:一是会话存档在首次会话时本身就会向客户推送提示,客户已经知道沟通内容被记录,此时再隐瞒 AI 身份反而增加不信任;二是群内回复所有成员可见,一旦被客户识别为机器生成又未被说明,容易演变成公开质疑。常见做法是在群公告或欢迎语里写明「本群由智能助手协助接待,复杂问题会转人工」,或在 AI 参与的回答前加统一标识。具体标识要求以企业所在行业的监管规定为准。

一个客服能管多少个客户群?需要配几个人?

取决于群的活跃度和 AI 承担的比例。全人工逐条回复时,一个接待人通常只能覆盖三到五个高频群;AI 承接标准问题后,同一人可以覆盖二十个以上,精力转向异常处理和抽检。配置阶段建议按「每群日均消息量 ÷ 单人可处理量 × 兜底系数」估算,并按接入批次逐步加人,不要一次按满量配置。

客户在群里发广告、吵架或者辱骂,AI 能管吗?

这类场景属于群运营,AI 客服的标准能力是识别并转交,不做自动处置。可以做的是配置敏感内容拦截,命中广告、辱骂、涉诉等意图时不生成回答并提示接待人;踢人、禁言等群管理动作仍需群主或管理员执行。需要自动处置的企业,要单独确认系统是否支持与群管理规则联动。

群里的聊天记录能保存多久?员工离职后还能查吗?

取决于会话存档的开通范围和厂商的存储策略。存档开通后,员工与客户在群内的消息进入服务记录,可按群、按坐席、按时间检索;员工离职后,群可再分配给接手人,历史服务记录不随人走。具体保存期限以存档服务协议和厂商约定为准,涉及金融、医疗等有留存要求的行业,应在合同里写明保存年限。

已经在用个人微信群服务客户,能直接升级成企微客户群吗?

不能直接升级。个人微信群和企微客户群分属两套账号体系,没有把群数据和群成员平移过去的通道。可行的做法有两种:新建企微客户群后通过群活码引导客户迁入,或在群内已有企微成员、且本人是群主的前提下走互通群迁移,把群管理权纳入企微体系。两种方式都要提前设计迁移话术和过渡期的双群运行安排。