AI客服系统多少钱一个月？拆解按月计费的构成与投入区间

客服系统销售报出来的月费，往往只是整笔支出的一部分：坐席数、对话条数、知识库维护、人工兜底、接口调用可能分开算。这篇不报具体数字，只给一套拆解顺序——先分清哪些项按月固定、哪些随量浮动，再去站内对照表核当时的单价，这样询价时不容易被话术牵着走。

客服系统销售报出来的月费，往往只是整笔支出的一部分：坐席数、对话条数、知识库维护、人工兜底、接口调用可能分开算，有的还把模型调用单列一行。这篇不报具体数字，只给一套拆解顺序——先分清哪些项按月固定、哪些随量浮动，再拿去站内核对当时的口径。

这样做的价值在于：询价时你能主动问「这条按什么计量」「超量怎么处理」，而不是等对方报完一个总数再猜里面装了什么。同一句「一个月多少钱」，在不同厂商那里可能是账号费、会话费或者解决量费，含义完全不一样。

先分清月费里到底有哪几块

拿到一份报价，先把里面的条目按「固定」和「浮动」贴标签。固定项通常跟着账号数或并发数走，用不用都付；浮动项跟着实际业务量走，量小的时候便宜，量一上来就不可控。这两类别混在一张表里看，很容易把某个浮动项当成固定成本来做预算。

坐席/账号费

按开通的客服账号收，注意问是绑定账号数还是绑定并发数，坐席闲置时要不要照样付

对话或会话量费

按消息条数、会话轮次或解决量收，同一句咨询在这三种口径下计出来的量差别很大

平台与实施维护费

一次性开通费之外，可能还有按月收取的系统维护、版本更新或专属部署费用

模型调用费

有的打包进月费，有的按 token 单独结算，要问清是含在套餐里还是另外出账

哪些项会随业务量一起涨

客服业务的量不是平的，促销、故障、上新那几天咨询会集中爆发。做预算时用月度平均值去估浮动项，大概率会低估。更稳的做法是拿近几个月的峰值当基数，先看峰值下的账单会变成什么样子。

• 对话量：这是最直接的浮动项，问清超量后是降速、加价还是直接停服，三种处理方式的预算风险差得远
• 模型调用：如果按 token 单算，长对话、带附件、反复追问都会把用量推上去
• 知识库文档数：部分方案按文档条数或向量库容量分档，文档多了会往上跳一档
• 人工接管时长：AI 处理不了的转人工部分，可能按人工坐席工时另行计费

这四项里，最容易被忽略的是人工接管和知识库容量，因为它们不在「AI 系统」的名目下，但账最后都算在客服部门头上。询价时可以直接问：超量之后你们默认怎么处理，账单会在哪个环节跳档。

人工兜底和知识库维护别漏算

AI 答不准的时候要转人工，这个比例直接决定你还要养多少坐席。如果系统宣传的自动解决率很高，但你的业务里政策解释、退换货判定这类问题占比大，实际接管比例可能明显高于演示环境。估预算时先按偏保守的比例算，跑顺了再往下调。

知识库也不是导入一次就完事。政策改了、话术换了、商品下架了，文档都要跟着更新，还要有人定期抽检回答质量。这部分是持续的人工工时，不会体现在系统的月费账单上，但在排人力时要算进去。

估自己投入区间的四步顺序

不要一上来就问总价，先把自家的情况框出来，再拿框好的参数去对照报价。这样对方报出来的数字你才知道它对应的是哪个量级，也方便横向比几家。

1. 定场景先明确是售前咨询、售后工单还是内部支持。场景不同，计费口径差别大：售前偏会话量，售后偏工单解决量，内部支持可能按账号数。验证方式是把最近一个月的真实咨询类型分个类，看哪类占大头。
2. 定对话量拉近三个月的真实工单或咨询记录做基数，别拿销售说的「大概多少」。如果历史数据不全，就用客服系统里的会话导出功能先导一份出来。
3. 定兜底比例先按偏保守的人工接管比例算人力，比如假设只有一部分问题能被 AI 独立解决。跑一两个月真实数据后，再拿实际接管率回来修正。
4. 去站内比一遍单价类数字到 /official-api 和 /price-watch 核对当时的报价口径，厂商方案和信誉情况到 /sites 对照。比的时候看计量单位是否一致，口径不同的数字直接比会失真。