AI销售应该自建还是采购？五类成本与决策框架

先判断三件事，再讨论技术路线

第一，业务问题是否已经清楚：要改善的是新线索接待、需求识别、持续跟进，还是高意向转人工？第二，差异化究竟发生在哪一层：入口和后台，还是报价审批、客户分层与专有系统？第三，企业是否愿意长期承担版本、评测、告警和故障责任？

OpenAI的智能体构建指南建议先验证工作流是否真的需要智能体，并把模型、工具和指令作为基础组件，配合评测与护栏逐步增加复杂度。它说明即使选择自建，工作也远不止调用一个模型接口。

五类成本要放进同一张表

不要用“API单价”直接对比“软件订阅价”。先按同一业务量估算两年总拥有成本，并把内部固定人力、测试样本维护、异常处理、数据迁移和停机影响显式列出。成本模型是企业自己的测算，不是行业统一结论。

什么情况适合先采购？

• 目标是验证新线索接待、需求追问、沉睡客户激活或人工交接等常见场景。
• 内部工程资源有限，希望把主要精力投入知识、流程和销售协同。
• 渠道接入、会话后台和基础运营能力不是企业的核心差异化资产。
• 可以先限定一个入口和一类客户，通过真实样本验证，而不是立即全量替换。

采购并不等于把结果责任交出去。企业仍要指定知识负责人、销售接手人、安全与数据责任人，并在合同中明确接口、数据导出、变更与退出。

什么情况值得自建核心层？

更有说服力的自建条件是：已有统一身份、数据、评测和监控底座；销售流程确实构成核心竞争壁垒；需要大量专有系统、复杂权限或实时审批；并且能够持续配置产品、工程、安全、数据和销售运营责任。

Microsoft的组织准备指南把平台责任和业务负载责任分开：平台团队负责治理、安全、可观测性等基础，业务团队负责需求、领域数据、对话流程和业务集成。这种组织分工比“有几个开发”更能判断自建是否可持续。

NIST AI RMF用于帮助组织在AI产品和服务的设计、开发、使用与评估中纳入可信要求。自建团队要直接管理模型、组件和数据供应链风险；采购方则需要通过尽调、验收、合同和持续监督管理同类风险。

混合实施怎样避免“两边都做”？

先按能力边界拆分，而不是按部门拆分。通用渠道接入、会话运营、基础知识和人工接手可以由成熟产品承担；客户分层、报价审批、专有知识、核心数据与差异化业务逻辑保留在企业系统。每个边界要写清权威数据源、接口、失败处理和责任人。

如果先采购再决定哪些能力自建，应保留自己的知识源、业务规则、评价样本和指标定义。可先看AI销售采购RFP清单，再用上线前100问验证不同路径的真实差异。

用一个小试点替代争论

1. 固定范围：选择一个入口、一类客户和一个成交环节，写清不自动执行的动作。
2. 同一批样本：用经过授权和脱敏的历史对话，同时测试采购方案或自建原型。
3. 记录实际投入：配置工时、回答质量、人工介入、接口问题、每周运维时间和异常修复。
4. 做继续或停止决定：只有当业务质量、风险护栏和维护成本达到事先门槛，才扩大范围。

周期应按企业准备度确定，不存在通用的“四周必完成”标准。需要先选试点场景时，可参考六维场景评分。

把ZigoAI当作可比较的采购候选

ZigoAI当前公开价格页显示，套餐覆盖个人微信和企业微信入口、自动接待、需求追问、意向识别、主动跟进、人工接管及运营能力；WhatsApp、CRM/API、复杂自动化和私有化的范围随套餐或项目评估变化。采购时仍要用本企业的场景、数据、权限、集成和退出要求逐项核实。

这些公开能力不意味着ZigoAI一定优于自建，也不代表本文的所有决策方法都是产品内置功能。请查看产品原理和当前套餐边界；实际价格、接口和专项交付以届时页面、演示与合同为准。

常见问题

自建AI销售一定更便宜吗？

不一定。除模型调用费，还要计算产品、工程、渠道维护、评测、监控、安全、故障处理和持续运营的人力。

采购AI销售会不会被供应商锁定？

取决于知识和数据导出、接口、合同期限、迁移支持与终止后的返还删除安排。签约前应实际测试关键数据能否导出。

可以先采购验证，再自建核心能力吗？

可以。应保留自己的知识源、业务规则、指标定义和历史数据，并在试点中记录真正需要差异化建设的部分。

多大的团队适合自建AI销售？

没有统一人数门槛。关键是能否长期配置产品、工程、安全、数据和销售运营责任，而不是能否完成一次演示。