销售报价助手怎样区分参考价格和可发给客户的正式报价

销售报价 Agent 开发最需要先说清的，是“找到了一个价格”和“这份报价可以发给客户”之间的差别。资料里出现的历史成交价、公开目录价、促销价和客户专享价，适用条件不同，不能让模型看到数字就替销售承诺。

一个稳妥的首期范围，是读取已批准价目表、整理报价草案、列出缺失条件，再把折扣和对客发送交给业务规则与授权人员。下面所有产品、单价、日期与折扣都是演示假设，不是市场行情，也不构成虾虾AI或任何厂商的实际报价。

把价格记录拆成可核对的条件

例如合成产品 DEMO-S01 的目录价为每件1000个演示货币单位，仅用于某个演示有效期；客户提供数量10，但没有说明是否需要安装。Agent不能直接回答“总价一万，包含安装”。数量、计价单位、税费口径、运输、实施服务和价格有效期，任何一项缺失都可能改变实际报价范围。

不建议把价格表做成只有“名称、价格”两列。至少保存产品编码、版本、币种、单位、适用客户范围、生效与失效时间、包含项、排除项和批准记录。模型负责帮助人找到记录，服务端负责检查当前客户是否符合适用条件。

历史合同和当前价目表也应分开。旧合同可以帮助销售了解背景，却不能自动成为今天的授权售价。只有来源被业务方确认、适用日期有效、客户条件满足的记录，才进入可报价候选集合。

不要靠文件名里有“正式”两个字判断授权。后台状态、批准人和有效版本应一致。审批后再改数量、币种或服务范围，要重新判断是否仍在原授权内；不能沿用上一版审批标识而悄悄改变金额。

下载报价条件与状态样例。第一条条件完整，允许生成草案；第二条资料已过演示有效期，应暂停生成价格；第三条需要额外安装服务，应先补范围，不能默认免费包含。附件中的数值只验证计算链，不用于推断真实商业单价。

项目实施时，先让销售负责人指定唯一的价格源。若同一编码同时命中两张有效表，记录冲突并转负责人处理，而不是按最低价、最新上传时间或模型偏好随便选一条。上传时间晚不一定表示生效时间晚，文件名里的日期也不等于经过批准。

结构化输出可以要求产品编码、数量、计价单位、引用版本和状态都存在。JSON Schema的条件校验说明可用于表达“出现某字段时还必须补其他字段”的规则；这类结构约束只能检查数据形状，不能证明商业授权已经成立。

销售说“老客户照顾一下”是业务意图，不是批准凭据。系统可以提示需要负责人确认，并列出申请理由；是否批准、折扣上限及例外规则应由客户自己的流程定义。本文不提供适用于所有企业的折扣比例。

如果对接CRM，先写入可编辑草案，展示将要修改的客户、机会、金额和版本。用户确认后再提交；提交结果未知时，按报价业务编号核对，不重新生成第二份正式报价。引用的价目表更新后，旧草案应提示重新核对，而不是继续显示“可以发送”。

“这个价格保留多久”“是否含实施”“能否分批交付”往往比模型生成一段优美报价说明更重要。资料没有明确条款时，Agent应列为待确认问题，不凭常见做法补上。正式文件中的范围、有效期和价格来源，应能回到审批记录。

同样，客户上传竞品报价让系统“给出更低价”，不能成为自动修改本企业价目表的理由。可以整理差异，但不得泄露别的客户专享信息。客户身份、价格适用范围和内部权限需要一起验证。

测试至少覆盖缺数量、单位冲突、过期价目表、同编码多价格、越权折扣、修改后沿用旧审批以及发送超时。记录草案状态和阻止原因，不能只统计“生成了多少份报价”。真正需要保证的是：不完整或未经授权的信息不会被包装成可对客承诺的文件。

报价草案中的数量和单位应与原始需求一致，不能把一套设备拆成若干件后仍沿用套价。币种、税费及四舍五入口径由业务方定义，金额计算交给确定性的程序完成，模型只解释输入条件。演示时可故意加入数量为空、单位改变和小数金额样例，确认系统会先补条件，而不是用零金额生成一份看似完整的正式文件。

若先做售前知识整理，可看知识库文档准备；要接入既有CRM或审批系统，可从流程自动化梳理动作。带上一份脱敏价目表、当前审批流程和报价模板到定制咨询，先界定参考测算、草案和正式发送各做到哪一步。