判断首期功能，有个很直接的办法：在测试站上提交一张包含两个型号的询价，然后关掉网页。十分钟后再问，谁能找出这张询价？能不能看到客户当时选的型号、数量和规格？现在由谁处理？
如果这些问题只能靠翻公共邮箱、问同事或回忆通知消息，首期最缺的不是更漂亮的搜索框，也不是更像购物车的询价清单，而是后台承接。
这不等于搜索和清单不重要。型号成百上千，客户连产品都找不到，询价入口当然不会有用；客户每次要询五六种零部件，却只能逐个提交表单，后台收到的又会变成几条彼此割裂的消息。三项功能究竟做到什么程度，要沿着客户实际找货和企业实际接单的过程判断。
后台线索管理先做到“不丢、不错、有人接”
首期后台没有必要复制一套完整CRM。客户画像、自动评分、复杂漏斗、营销自动化和多层审批，在真实线索还没跑起来时很难一次设计准确。可后台也不能只负责把表单内容转发到邮箱。
一条询价进入后台，至少应生成唯一编号，保留提交时间、来源页面、语言站点、联系人和企业信息。更关键的是产品内容：产品ID、提交当时显示的名称和型号、数量、单位、已选规格、单项备注，都要跟着这条线索保存。
产品ID和页面快照不能互相替代。ID负责长期关联，页面快照负责还原客户提交那一刻看见的内容。半年后产品改名或型号停产，销售仍然需要知道客户当时问的究竟是哪一项。
后台状态不必很多。新线索、已分派、已联系、确认有效、已关闭或无效，通常已经够首期使用。比状态数量更要紧的是负责人和时间：谁接手，什么时候接手，最后一次跟进是什么时候，通知失败后有没有被发现。已有CRM或ERP的企业可以把这些动作放到现有系统里，网站侧只需可靠传入，并记录同步成功与否以及外部系统返回的编号。单纯发出一封邮件，不能证明线索已经入库。
询价中往往带有姓名、邮箱、电话、图纸和采购计划。字段收集、查看权限、保存期限和删除方式，要与网站隐私说明和企业实际用途一致。允许上传附件时，还要限制文件类型、大小和访问范围。首期管不好附件，宁可先收文字需求，再由负责人通过受控渠道接收文件。
客户经常一次询多项，询价清单就应进入首期
询价清单解决的不是“把网站做得像电商”，而是把多项采购要求放进同一份需求里。它不必显示实时价格，也不必进入在线支付。
工业零部件、耗材、配套设备和经销目录，常见情况是客户先挑出几个型号，再分别填写数量、单位和规格。若网站只能对每个产品提交一次表单，销售可能收到同一家企业连续发来的几封邮件，还得自己判断它们是否属于同一个项目。清单把这层关系保留下来，后台收到的是一张完整询价，而不是几段需要重新拼接的信息。
第一版清单应允许增加、删除和修改项目，返回产品页继续查找后，原有内容不会无故消失。同一产品重复加入时，要么合并数量，要么明确保留为不同规格，不能悄悄生成两条一模一样的记录。
数量旁边必须有单位。客户填写“20”，可能是20件、20箱，也可能是20套。单位应随产品给出可用选项，不能让所有产品共用一套不相干的计量方式。页面已经选过材质、尺寸或接口，加入清单时也应一并带入，客户只补充网站尚不知道的条件。
多数询价站首期不需要强制注册后才能使用清单。可以先在当前浏览器保留项目，提交时再收集完成首次联系所需的信息。账户登录、跨设备同步、历史询价和重复采购，等确有持续使用需求再做。第一次询价还没发生，就先让客户建立账户，增加的是门槛，不是有效线索。
表单字段也应按第一次分派和回复真正需要什么来定。姓名、企业、工作邮箱、国家或地区、清单项目和补充要求通常能够启动判断；电话、预算、交期、贸易条件、认证和附件是否必填，要看缺少它们是否真的无法处理。W3C的表单指南要求控件有明确标签，并用说明、校验和反馈帮助用户完成输入。落到询价清单上，就是字段名称、单位、格式、错误位置和提交结果都要说清，手机上也能修改多项产品。
型号多、叫法多，产品搜索不能等到二期
产品只有十来个，分类和页面导航已经能让人迅速看完，单独开发搜索中心未必划算。可一旦目录变大，客户习惯按型号、料号或参数找货，搜索就不再是装饰。
B2B搜索最先要解决的是“同一件产品有几种叫法”。完整型号、部分型号、带不带连字符、英文大小写、市场别名、旧型号和常用缩写，应该怎样对应现行产品，需要企业先确认。网站里同时出现 AB-120、AB120 和“120型”，却没人说得清它们的关系，再好的搜索工具也只能猜。
因此，搜索开发之前应先建立稳定的产品ID，整理对外名称、标准型号、别名、旧型号、分类和会改变选型的参数。搜索结果页再处理这些实际问题：
- 完整型号和部分型号能否找到正确产品；
- 空格、连字符和大小写差异是否影响结果；
- 结果卡片是否露出系列、型号和关键规格；
- 没有精确结果时，能否给出相近产品或可修改的条件；
- 搜索词、零结果词和最终点击是否有记录，方便补别名和修订资料。
别急着把语义搜索、个性化排序和智能推荐都塞进首期。先把客户真实使用的型号和叫法搜准，零结果时给出可以继续判断的去处，已经能解决大部分基础问题。上线后的搜索记录反而会告诉企业，客户怎样称呼产品、哪些旧型号仍在被查、哪些参数页没有写清。这些数据跑一段时间，再决定高级搜索做什么，会比项目开始时凭想象列功能更稳。
搜索功能和搜索收录是两回事
站内产品搜索服务已经进入网站的人；Google等搜索系统主要通过可以抓取的分类页、系列页、型号页、网页文字和内部链接理解网站。不能因为站内能搜到某个型号，就认为它自然会获得公开搜索收录。
产品页仍要写清名称、型号、用途、关键参数、适用条件和资料版本，重要信息不能只藏在搜索结果、图片或PDF里。Google关于实用可靠内容的现行说明强调清晰来源、专业依据、作者或发布网站背景，并把信任放在E-E-A-T的核心位置。对产品型网站来说，这些要求最后都要落在可核对的细节上：参数从哪里来，文件适用于哪个型号，谁负责确认，什么时候更新。
参数筛选还会产生大量组合网址。Google针对分面导航网址的抓取文档提醒，这类页面可能形成近乎无限的网址空间，增加服务器负担，也消耗搜索系统用于发现有用页面的时间。有独立搜索需求、内容也足够完整的分类或参数组合，可以整理成稳定落地页；其余组合留给站内查找，不必全部开放收录。
首期怎么取舍，最后看两种依赖
业务依赖和开发依赖并不完全一样。
开发时，产品数据通常排在前面。没有稳定的产品ID、型号和规格字段，搜索无法准确返回结果，询价清单也无法把产品带进后台。接下来再做搜索与清单的前台动作，最后联调提交、保存、通知和分派。
上线时则不能按开发顺序拆开验收。客户找得到产品，却不能把多项需求放在一起，路径会断；清单能提交，后台没有记录和负责人，路径还是断。适合首期的组合大致是：
- 产品少、主要按项目定制：清楚的导航、带产品背景的单项询价、最小线索后台。独立产品搜索和多产品清单可以后置。
- 型号多、客户按料号或参数找货：基础产品搜索、询价清单和最小线索后台同时上线。
- 产品不多，但经常成套采购：搜索可以简化，询价清单与后台不能简化成几封独立邮件。
- 已有CRM或ERP：不另建重复系统，首期把清单内容、来源和同步状态可靠送入现有流程。
验收时不要分别检查三个页面。给测试人员一个真实任务：用旧型号或不完整型号找到两个产品，填写不同数量和规格，加入清单，返回继续搜索，再提交。后台应只生成一条线索，两项产品和单位完整，来源可查，通知送达，负责人能接手，状态与跟进记录可以保存。
再故意制造几次不顺利：重复点击提交、邮件发送失败、手机中途返回、零结果搜索、产品刚好下架。正常流程谁都容易做得漂亮，线索真正容易丢在这些地方。
红数科技评审这类首期方案时，最后核对的是同一份信息有没有走到底。客户搜索时找到的产品，加入清单后不能换成另一套名称；进入后台后，也不能只剩一段没有型号背景的留言。搜索和清单可以按业务规模做轻，后台也可以先少做状态，但一条有效询价必须有记录、有人接、查得到处理到哪一步。
参考资料
[1]: W3C Web Accessibility Initiative, Forms Tutorial，核对日期：2026年7月22日。 [2]: Google Search Central, 创建实用、可靠、以用户为中心的内容，核对日期：2026年7月22日。 [3]: Google Search Central, Managing crawling of faceted navigation URLs，核对日期：2026年7月22日。
