RFQ 询盘表单只应强制填写“销售无法开始判断或报价就缺不了”的信息:产品或应用、数量、交付国家或地区、期望时间、需求说明,以及可正常回复的联系人和公司邮箱。图纸、材料、标准、包装、贸易条款是否必填,取决于产品;职位、详细地址、年度采购额等信息通常可以后补。

先按报价依赖程度分层,再决定哪些字段出现在第一步。
先确定这张表单要完成哪一种任务
网站上的“联系我们”和“获取报价”不是同一张表。通用联系表承接合作、售后、招聘等多种消息;RFQ 表单的任务是形成一条销售可以处理的报价请求。
上线前先写清三件事:
- 这张表单服务标准品、定制品,还是两者都服务;
- 首次回复是直接报价、补充技术问题,还是安排沟通;
- 哪些输入决定价格、能否生产和由谁跟进。
如果销售拿到表单后仍要重新问“什么产品、多少数量、发到哪里、什么时候要”,字段设计就没有完成任务。反过来,如果买家必须填写一套接近供应商注册表的信息才能发送初步需求,表单又承担了过多工作。
需要先梳理网站转化路径,可参考外贸询盘型网站建设。
RFQ 必填字段:没有它就不能开始判断
以下字段适合作为大多数外贸 RFQ 的起点,但仍应按产品调整。
| 字段 | 建议状态 | 为什么要问 | 设计方式 |
|---|---|---|---|
| 产品、型号或应用 | 必填 | 确认由谁处理、是否在供应范围 | 产品页自动带入,并允许修改 |
| 数量与单位 | 条件必填 | 影响工艺、价格、MOQ 和交期 | 数量与单位分开,允许“待确认” |
| 目的国家或地区 | 必填 | 影响运输、合规、语言和分流 | 国家下拉;城市或港口可选 |
| 期望交期或项目阶段 | 必填 | 判断紧急度与产能可行性 | 日期或阶段选择,避免强迫猜日期 |
| 需求说明 | 必填 | 容纳未被结构化字段覆盖的信息 | 给出提示,避免只写“Message” |
| 姓名、公司、工作邮箱 | 必填 | 完成身份判断与回复 | 公司邮箱优先,但不要屏蔽所有公共邮箱 |
| 电话或即时通信 | 选填 | 紧急项目或地区习惯下有用 | 标明国家区号,说明用途 |
| 文件上传 | 条件必填 | 定制件、BOM、图纸或规格书可能决定可报价性 | 明示格式、大小和保密处理 |
“数量”不一定总能必填。研发阶段的采购商可能只知道样品需求,还不知道量产数。可以增加“Prototype / First order / Annual estimate / Not decided”这类阶段选项,比要求填写一个虚假数字更有用。
定制产品应使用条件字段,不要把所有问题一次展开
标准件通常只需型号、数量、目的地和联系方式。定制加工、设备、包装或配方产品可能还需要材料、尺寸、公差、表面处理、应用条件、标准和图纸。
这时应使用条件逻辑:
- 买家先选产品类型或“标准 / 定制”;
- 标准品显示型号、数量和交付信息;
- 定制品再显示对应的材料、工艺、文件和应用条件;
- 不适用的字段不出现;
- 无法确定时允许选择“需要建议”。

同一入口可以分流,但每条路径只显示与当前报价有关的字段。
分步表单不是越多步越好。若总共只有六七项,单页通常更清楚;字段多且存在分支时,再使用两到三步。每一步应说明任务,例如“1. 产品需求”“2. 交付信息”“3. 联系方式”,并允许返回修改。
文件上传要让图纸真正到达销售和工程
文件上传对制造类 RFQ 很重要,但也是最容易“表面可用、后台丢失”的环节。上线前应验证:
- 支持的格式与单文件、总文件大小;
- 文件名含中文、空格或特殊字符时能否处理;
- 多文件上传是否完整;
- 手机能否从文件或相册选择;
- 邮件通知是否只发安全链接,而非超大附件;
- 销售与工程是否有访问权限;
- 恶意文件扫描、保留期限和删除机制;
- 页面是否说明保密政策或 NDA 路径。
不要要求买家把商业机密直接发到一个用途不明的公开表单。若项目敏感,可先收联系人和项目摘要,再由销售提供受控上传入口或 NDA 流程。
联系信息既要能回复,也不要误伤真实买家
工作邮箱有助于判断公司身份,但强制封禁 Gmail、Outlook 等公共邮箱可能误伤小企业、初创项目和处于出差状态的采购人员。更稳妥的做法是把邮箱域名作为评分信号,而不是一票否决。
电话号码不应在所有场景下强制。若销售确实会电话确认,字段旁应写明用途和时区偏好。若从不打电话,要求填写号码只会增加阻力和虚假数据。
公司名称可以必填,因为它有助于路由和查重;完整街道地址通常等到报价、样品或合同阶段再收集。
表单旁边要告诉买家提交后会发生什么
买家不仅在衡量要填多少,也在衡量是否值得填。表单附近应清楚说明:
- 接受哪些产品或项目;
- 最低起订或样品政策;
- 需要准备哪些文件;
- 回复渠道和正常处理时间;
- 敏感项目如何处理;
- 提交后是收到正式报价,还是先做技术确认。
处理时间只能写团队可以兑现的范围。若不同地区、产品线和节假日差异明显,应写条件,不要一律承诺“24 小时报价”。
页面需要与产品、能力和案例形成完整路径时,可查看网站建设与内容架构服务。
提交成功必须有确认、编号和明确下一步
成功状态至少包含:
- 清楚的成功提示,不让买家猜是否提交;
- RFQ 编号或可追踪的参考信息;
- 提交内容摘要或确认邮件;
- 预计由哪个团队、通过什么方式回复;
- 允许补充文件或更正信息的渠道。
不要在点击按钮后只显示一个旋转图标,也不要把所有提交都跳回首页。重复点击应避免产生多条记录,但不能在失败时假装成功。
表单邮件不是完整的线索系统。至少要把提交写入可查记录,并保存来源页面、产品、时间和分配状态。邮件丢失、进入垃圾箱或人员休假时,团队仍能找回请求。
用一个字段决策表删掉无效问题
下面的 12 项评审表用于内部取舍,不是固定行业标准。每个候选字段逐项判断,只有对“报价、可行性或路由”至少一项有直接作用,才进入首轮表单。
| 编号 | 判断问题 | 是 | 否 |
|---|---|---|---|
| 1 | 缺少它就无法识别产品或应用吗 | 保留或条件显示 | 继续判断 |
| 2 | 它直接改变价格、MOQ 或工艺吗 | 保留 | 继续判断 |
| 3 | 它直接改变交付、合规或分配团队吗 | 保留 | 继续判断 |
| 4 | 买家在首次联系时通常能准确回答吗 | 可放首轮 | 改为选填或后补 |
| 5 | 页面已有答案,能自动带入吗 | 自动填充 | 不要求重复输入 |
| 6 | 销售在首次回复前真的会使用吗 | 保留 | 删除 |
| 7 | 它只是为了完善 CRM 档案吗 | 后补 | 继续判断 |
| 8 | 它能用条件逻辑只给相关买家吗 | 条件显示 | 避免全员展示 |
| 9 | 买家若不知道,是否可选择“待确认” | 提供该选项 | 不应强制猜测 |
| 10 | 涉及敏感或个人信息吗 | 说明用途并最小化 | 正常处理 |
| 11 | 字段错误会阻断有效买家吗 | 改验证规则 | 保持 |
| 12 | 可通过来源页、URL 或系统自动获取吗 | 自动记录 | 不让买家填写 |
评审后还应由销售拿最近一批真实询盘回放:哪些字段曾改变报价,哪些从未使用,哪些问题总在第一封回复中补问。用实际流程决定,而不是照搬别人的表单长度。
反垃圾设计不要把验证成本全部交给客户
可以组合使用蜜罐字段、提交频率限制、服务端验证、域名与内容风险评分,以及在高风险时触发的验证码。不要只靠前端必填,也不要让每个买家都完成多轮图片验证。
常见高风险信号包括同一来源短时间重复提交、链接密集、内容与产品无关、字段值机械重复和临时邮箱。它们应触发分流或二次验证,不必全部直接删除。误判记录要保留,便于调整规则。
涉及 WordPress 表单与站点技术配置,可由WordPress SEO 与技术优化一起检查表单脚本、索引与性能影响。
GA4 要区分开始填写、真正成功和销售有效
Google Analytics 4 的增强型衡量可记录 form_start 和 form_submit,但不同表单技术可能产生漏报或误报。正式使用前应在浏览器调试、GA4 DebugView 和实时报告中验证。
至少设计四层事件:
| 阶段 | 示例事件 | 成功条件 |
|---|---|---|
| 开始 | form_start | 用户首次真实交互 |
| 尝试 | rfq_submit_attempt | 点击提交且前端校验开始 |
| 成功 | generate_lead 或 rfq_submit_success | 服务端已接收并返回成功 |
| 质量 | CRM qualified_lead | 销售完成有效性判断 |
不要只跟踪按钮点击,因为校验失败、网络错误和接口错误都会制造假转化。也不要把字段里的姓名、邮箱、电话或需求正文发给 GA4;事件只传非个人化的表单 ID、产品类别、页面类型和成功状态。
网页提交只是中间节点,销售有效性才决定字段是否有用。
FAQ
RFQ 表单到底应该有几个必填字段?
没有统一数字。以销售能开始判断的最小信息集为准。标准品可能只需产品、数量、目的地、需求和联系人;定制项目则可能必须有图纸或应用条件。
是否应该把预算设为必填?
只有预算会直接决定方案或供应范围,且目标买家在此阶段通常知道预算时才考虑必填。否则可选填,或改问数量、目标规格和项目阶段。
电话号码要不要必填?
若首次跟进确实依赖电话,并能说明用途,可以必填;以邮件为主的跨时区业务通常更适合选填。不要收了号码却不使用。
文件上传失败时怎么办?
保留表单其他内容,显示明确错误,并提供受控的补传入口或回复确认邮件的方式。不能因为一个附件失败,让买家重新填写全部字段。
RFQ 提交后多久回复合适?
以团队可稳定执行的服务标准为准,并按产品复杂度说明“确认收到”和“正式报价”是两个时间节点。不要承诺无法兑现的统一时限。
通用联系表能替代 RFQ 表单吗?
简单产品或初期网站可以暂时共用,但至少要识别产品、数量和来源页。产品线、分配规则或报价输入变复杂后,应拆分 RFQ 路径。
下一步
让销售拿最近 20 条真实询盘逐条判断:第一次回复前缺了什么、哪些字段从未使用、哪些真实买家被验证拦住。先据此完成字段分层,再让工程验证提交、附件、通知和 CRM 入库,最后上线追踪有效询盘率。

