加购、升级和附件不能混在一起，销售 Agent 怎样整理相关产品建议

销售 Agent 整理相关产品建议时，应先说明建议意味着增加一项、讨论升级，还是补充附件。再看客户已经选择什么，排除重复行。相关产品推荐 Agent 定制的结果是一组可解释候选，客户确认后才能进入后续商务处理；推荐本身不说明技术兼容，也不构成价格或交付承诺。

关系类型比相似名称重要

产品A和B外观相似，不表示B就是升级版；目录把D列在A旁边，也不表示两者能配合工作。先由产品与销售窗口提供正式关系，包括起点产品、终点产品、类型、方向、适用条件和批准记录。没有明确关系，只能保留待确认线索，不能让模型根据语义临时造一条。

微软的相关产品关系文档区分加购、升级、附件等类型，并允许单向或双向关系。本文只借鉴商业建议的数据表达；真实选用要核对客户自己的获批目录，不能把厂商关系名称当成通用配置标准。

加购通常保留原选择并讨论增加，升级则可能涉及替换原选择。附件建议要说明相应主产品，而不是孤立展示一个产品名。输出统一写“推荐购买”会让用户不知道选择后发生什么，因此候选卡应直说建议动作及尚需确认的条件。

附件第一条是A关联B加购，但客户已经选了B。系统应说明已在当前选择中，保留关系以供回查，不再追加第二行。判断必须按产品身份和具体配置，而不是名称是否相同；否则名称稍有区别就会重复推荐。

第二条A到C为升级，只能标记替换讨论，不能将A与C直接同时放入订单。第三条从D反查A没有依据，因为演示关系仅A到D单向。第四条A到D可以展示附件候选，但客户尚未确认，不计入已购。这些输入都在合成关系与选择核对表中，可填写实际显示、错误类型和审核人。

客户同时查看两份目录时，应明确已有选择取自当前哪一份，不把历史订单的同名产品当作本次已选。历史拥有是否影响建议，由业务另定规则；本篇没有维护客户资产或库存，不能据“以前买过”就自动删除本次合理需求。

有些附件本来就在套装里。先看套装确认表确定哪些已包含，再产生增补候选，避免把必带件再次当作可选购买。若套装版本尚未确定，卡片写需要核对包含范围，不要给出确定的重复或不重复结论。

建议来源还需要适合当前销售渠道。产品关系存在，不表示当前渠道资料已可对客使用；可通过渠道资料齐备核对确认候选描述是否具备必要内容。资料缺失时仍可内部登记关系，但不能生成一张内容完整却没有出处的对客推荐卡。

对升级建议，可并列原选择、候选和需要客户确认的改变，例如是否替换原行、是否仍需原附件。不能根据“更高级”承诺更适合业务，也不把销售关系当作工程替代授权。专业使用条件由相应人员解释。

候选卡至少给出来源、类型、方向、当前已选状态和下一步。客户选择C后，先生成变更预览，而不是直接增加数量；客户忽略D时，保留未决定，不写成明确拒绝。这样销售接手时能区别没有展示、展示未选与已确认新增。

同一客户说“按上次建议办”也要定位具体建议版本。若关系后来撤销，旧卡片应提示复核；若只是描述改字，不应自动重建订单。关系维护人员能够找到哪些候选引用了这条记录，才能解释修改影响，而不必反查所有聊天。

验收请销售按附件逐条指出会留下哪些订单行，再检查系统预览是否相同。重点看重复B、升级C与反向A三个容易误判的位置，不能只看生成推荐文字是否流畅。所有实际选择和发送仍在独立业务流程中完成。

推荐卡的排序也需要说明来源。首期可以按获批目录原序呈现，不把模型认为更吸引人的商品排到前面；业务若已有明确优先级，再把规则列为独立输入。关系类型、排序与客户确认分别记录，才不会把一次展示误认为已经完成销售选择。

验收展示页时应同时检查原产品行是否仍在。A升级C的样例尤其要让销售指出最终可能保留哪一项，确认系统没有用加购的交互处理升级。这比单看候选名称和文案相同更能暴露实际风险。

工程备件的条件替代另见替代件范围，本题只做商业相关产品建议。更多任务见知识库专题。在定制咨询提供脱敏关联目录、当前选购清单和升级确认方式，便可讨论候选卡、去重与销售接手范围。