客户说同行官网都有个「询价车」，非要我们也加一个，可我们产品就几十个，加了会不会成摆设？

产品只有几十个、客户多数一次只问一个型号的官网，通常不必上完整的询价车；它真正派上用场的，是多品类、客户一次要问多个型号、销售需要按清单统一报价的 B2B 场景。按 2026 年项目交付经验，询价车比普通产品页表单多出约 3-8 个工作日（经验区间）的开发量，另外还要算上后台清单处理和产品上下架的长期维护。判断依据不是同行页面上有没有这个按钮，而是最近几个月的询盘记录里，「一次问两个以上型号」的比例高不高。

询价车到底是什么，和购物车差在哪

询价车是把多个产品先放进一份清单、最后一次提交的功能，本质是「线索清单」，不是交易。它通常不显示实时价格、不扣库存、不走支付，提交后落到后台列表或销售邮箱。和购物车相比，询价车少了结算链路，多了型号、数量、规格备注这些字段；和单个产品页表单相比，它解决的是「一次问多个型号时要重复填很多遍」的麻烦。

为什么值得单独判断一次：如果客户的采购习惯是打电话或微信直接报型号，询价车很容易变成摆设；反过来，产品线长、型号多、客户常拿着一张清单来问，询价车能省掉销售来回确认型号的时间。2026 年常见做法是先在产品列表页加「加入询价」按钮，再在页头放清单入口，先不做账号体系，把线索收上来再说。

• 询价车：多选产品 → 填数量与规格 → 一次提交，不涉及支付。
• 购物车：选商品 → 算价 → 结算支付，依赖价格和库存数据。
• 产品页表单：单产品页留资，适合单品询价，维护最轻。
• 后台清单：销售能看到型号、数量、备注，便于一次报完价。

先翻询盘记录：三个信号决定要不要加

判断要不要做，别先盯着同行页面，先翻自己的询盘记录。交付时常用的是「三看一算」：先看产品结构，再看客户实际动作，再看销售能不能接住，最后算维护成本。顺序反过来，就容易做成「有功能、没人用」。

1. 看产品数量和品类跨度：产品少于 20-30 个（经验区间）、品类单一时，多选带来的价值有限。
2. 看历史询盘是否一次问多个型号：翻最近 3 个月记录，一次问两个以上型号的比例低于三成，通常先不做。
3. 看销售愿不愿意按清单报价：后台没人处理清单，提交上来也容易沉底。
4. 算维护成本：产品上下架、规格变动、清单字段调整，常见每月 0.5-1 人天（经验区间）。

这四步里第二步权重更高。询价车的价值全部来自「一次提交多个型号」，客户习惯一次只问一个产品，功能做得越完整越像摆设。第三步最容易被忽略：后台清单没有通知、没有导出，销售还是会让客户微信重发一遍，前面的开发就白做了。

适用与不适用：哪些官网加了有人用，哪些加了是摆设

适合做的情况比较具体：产品 SKU 在几十到几百之间、规格多、客户常批量比价，并且销售团队里有人专门跟清单。不适合的情况同样具体：产品少、客单价低、决策快，客户更习惯直接打电话或加微信。还有一条可以独立判断的边界——历史询盘里超过一半只问一个型号，询价车的使用率通常撑不起来。

• 适合：多品类或多规格、客户一次问多个型号、需要按清单报价、有后台跟单人员。
• 不适合：产品少于 20-30 个且品类单一、客户以电话微信询价为主、没有后台处理能力。
• 可折中：先做「产品页表单 + 备注栏可填多个型号」，观察 1-2 个月再决定要不要升级。

三种做法的可核对对比：工作量、适用对象、维护成本

交付前做方案对比，可以按开发量、适用对象、长期维护三个维度看。下面这些是常见项目的经验区间，不是固定报价，具体还要看产品数据整理到什么程度、后台清单要几个字段。

• 产品页表单：常见 1-2 个工作日（经验区间），适合单品询价，几乎不用维护，缺点是客户问三个型号要填三遍。
• 询价车（最小版）：常见 3-8 个工作日（经验区间），适合多型号询价，需要后台清单；维护常见每月 0.5-1 人天（经验区间）。
• 询价车（带账号与历史清单）：常见 10 个工作日以上（经验区间），只有当老客户反复询价、需要看到自己上次的清单时才值得，维护成本也随之上升。
• 购物车 + 在线支付：开发量再上一个台阶，涉及价格、库存、支付资质，适合标准品零售，不是 B2B 询价场景。

对比时容易漏掉的一项是「产品数据整理」。产品描述、规格、型号命名如果没有统一口径，询价车里的清单就是一堆乱码，销售拿到手还得回头问客户。这部分工作量经常不在最初报价里，属于要提前说清的口径。

真要做，交付前先把这几件事定死

询价车容易返工的地方不在前端按钮，而在字段和通知。交付前先把清单字段定下来：型号、数量、规格、备注、联系人、公司名；再定提交后的落点：后台列表、邮件通知、企业微信提醒，至少有一个能让销售当天看到。移动端步骤建议控制在 3 步以内，否则加购后的放弃比例会明显上升。

有一个项目就是这样：预算和周期都压得紧，客户坚持要询价车，产品数据只整理了一半，销售那边也没定谁跟单。做法是先上最小版——列表页加「加入询价」、页头放清单入口、一次提交、后台列表可导出，账号和价格体系全部不做；结果是按期上线，代价是后台多了一个模块要长期维护，产品下架时清单里还会残留旧型号，得另外加提示逻辑把它剔掉。上线后的实际使用率一般，属于「功能在、但没成为主路径」的状态。这类功能的真实成本不在开发那几天，而在后面每个月的维护口径上，所以维护责任要写进验收清单。

• 字段：型号、数量、规格、备注，必填项常见控制在 3 个以内。
• 通知：后台列表加邮件或企业微信，至少一条，避免提交后无人处理。
• 移动端：清单入口固定在页头或底部，步骤不超过 3 步。
• 数据：清单提交会收联系人信息，隐私政策要能打开，按平台规范和验收清单核对。
• 下架：产品下架后，清单里的旧型号要能提示或自动剔除。

做到什么算合格，看四条：提交后后台有清单、销售能导出、移动端三步内完成、产品下架有提示。四条都过再谈上线，缺一条后面多半会在验收后补工。

交付后容易返工的几个地方

把询价车做成「购物车样子」但没有结算，是误解的主要来源，访客以为能下单，点到最后发现只是留言。另一个坑是加购之后没有明显入口，用户加了两三个产品却找不到清单。还有提交后销售收不到清单、移动端按钮太小、产品下架后清单残留旧型号，这些都会在验收之后才冒出来。

• 界面上写成「购物车」却没有价格和结算，用户预期错位。
• 清单入口不明显，加购后无法继续。
• 后台没有通知或导出，销售仍让客户重发一遍。
• 移动端按钮过小、步骤过多。
• 产品下架后清单残留，提交上来的是无效型号。
• 收了联系人信息但页面没有可打开的隐私政策。

常见问题

产品只有几十个，做询价车会不会用不上？

有这个可能。产品少于 20-30 个、客户多只问一个型号时，使用率常见偏低，先做产品页表单加备注栏更稳妥，两个月后看数据再定。

询价车和购物车能不能共用一个？

不建议共用。询价车不涉及价格、库存和支付，购物车依赖这些数据，混在一起容易让访客误以为能直接下单，验收时也难界定范围。

询价车提交后，销售在后台能看到清单吗？

可以，但要在交付时定好后台列表和通知方式。只做前端提交、不做后台清单和导出，销售多数还是会让客户重发一遍，等于白做。

官网已经上线了，还能补询价车吗？

可以补，一般作为增量需求单独排期，最小版常见 3-8 个工作日（经验区间）。前提是产品型号和规格口径先整理好，否则清单字段定不下来。

做询价车要不要让访客先注册账号？

多数企业官网不必。账号会明显增加放弃率，常见做法是免注册直接提交，只有老客户反复询价、需要看历史清单时，才考虑加轻量登录。

结论落回操作层面：先翻最近 3 个月的询盘记录，统计一次问多个型号的比例。低于三成先不加，用产品页表单加备注栏过渡；高于五成可以做最小版询价车。它适合产品线长、批量询价、有人跟单的 B2B 官网，不适合单品询价为主、后台没人接的展示站。2026 年如果要评估，建议先让对方按交付清单出一版字段和通知方案，再谈开发量。