很多企业向三家供应商询价，却只发一句“我们要做一个高端官网，请提供方案和报价”。不同公司会自行假设页面、内容、后台、语言、动效和交付范围，最终收到的三份报价并不是同一个项目：一家只含UI，一家含前端，一家把CMS、文案和维护全部计入。此时价格无法横向比较，后续也容易因为“我以为包含”发生争议。
RFP（Request for Proposal，方案征询文件）的作用，是建立共同问题和统一回答框架。它不需要把所有设计答案提前写死，但必须让供应商理解业务目标、范围边界、技术条件和评审方式，并公开需要他们提出判断的部分。
01 先区分RFP、需求书、报价单和合同
文件 | 主要作用 | 应该回答什么 |
|---|---|---|
RFP/方案征询文件 | 邀请供应商提出方法与报价 | 为什么做、要解决什么、如何评审 |
项目需求书 | 明确页面、功能、内容和技术要求 | 做什么、哪些包含、哪些排除 |
供应商提案 | 回应理解、方法、团队、周期、费用和风险 | 准备如何完成、需要什么条件 |
报价单 | 明确费用、计价单位和假设 | 每项服务多少钱、何时支付 |
合同与附件 | 形成法律责任与变更规则 | 双方权利、交付、验收、版权和争议 |
小型项目可以把RFP和需求书合并，但不能把合同完全替代为聊天记录。大型采购还可能涉及正式招投标流程，应遵循企业制度和适用法律。
02 RFP第一部分：项目背景和业务目标
不要从“需要几个页面”开始。先让供应商理解项目为什么存在。
建议内容
- 企业、品牌和主要业务简介；
- 当前产品、网站或设计系统现状；
- 发起项目的原因和触发事件；
- 主要用户、市场和采购场景；
- 本次希望改善的业务问题；
- 不能改变的品牌、技术或合规限制；
- 与其他项目、系统或发布时间的关系。
目标应尽量可判断
不够明确：
> 建设一个国际化、高端、有科技感的网站。
更可执行：
> 让海外制造业采购和工程师在三步内找到产品系列、比较关键参数、下载数据表并提交包含型号的询盘；同时保留旧站有搜索价值的URL。
目标不一定全部量化，但必须能指导范围和验收。
03 第二部分：用户、任务和成功标准
列出最重要的用户群，不要只写“企业客户”。例如：潜在采购、技术工程师、渠道伙伴、现有客户、求职者和媒体。
用户 | 核心任务 | 当前问题 | 成功表现 |
|---|---|---|---|
潜在客户 | 理解服务并判断是否适合 | 首页抽象、案例证据少 | 能进入相关服务和案例，并提交明确需求 |
工程师 | 查找型号、参数和文档 | PDF分散、搜索困难 | 能筛选、比较并下载正确资料 |
市场团队 | 发布内容和更新案例 | 依赖开发、模板不统一 | 可在CMS中安全维护内容 |
销售团队 | 获取有上下文的询盘 | 表单信息不足 | 线索包含来源、页面、产品与需求 |
成功标准可以覆盖：任务完成、内容可维护、移动体验、表单质量、性能、索引保留和项目按期交付。不要只写访问量增长，除非企业已经有稳定基线和渠道投入。
04 第三部分：项目范围与页面清单
页面范围要同时统计“页面模板”和“内容数量”。例如新闻详情只有一个模板，但可能需要迁移200篇内容；产品详情可能存在三个完全不同模板。
页面清单建议字段
页面/模块 | 模板数量 | 内容数量 | 语言 | 主要功能 | 内容责任 | 优先级 |
|---|---|---|---|---|---|---|
首页 | 1 | 1 | 中/英 | 导航、CTA、案例 | 双方协作 | P0 |
服务页 | 2 | 6 | 中/英 | 表单、案例关联 | 甲方初稿，乙方编辑 | P0 |
产品目录 | 3 | 120 | 中/英 | 搜索、筛选、下载 | 甲方产品团队 | P0 |
案例 | 1 | 20 | 中/英 | 分类、相关服务 | 双方协作 | P1 |
资讯 | 2 | 80 | 中文 | CMS、标签 | 甲方迁移 | P1 |
联系 | 1 | 1 | 中/英 | 表单、地区分配 | 甲方确认 | P0 |
如果页面清单尚未确定，可以给出范围区间并要求供应商在发现阶段确认，例如“预计12–16个模板、40–60个静态内容页”。
明确排除项
例如：
- 品牌战略和Logo重设；
- 摄影、视频、3D和插画制作；
- 全量中文文案撰写；
- 专业法律与隐私咨询；
- CRM或ERP本体开发；
- 历史数据清洗；
- 域名、服务器和第三方订阅费用；
- 持续SEO运营与外链建设。
排除项不是推卸责任，而是防止供应商用不同假设报价。
05 第四部分：功能与业务规则
不要只列“搜索、表单、会员”。每项功能至少说明用户、输入、结果、异常和后台责任。
功能描述模板
字段 | 示例：项目咨询表单 |
|---|---|
使用者 | 潜在客户 |
入口 | 服务页、案例页、联系页 |
必填信息 | 姓名、公司邮箱、公司、服务类型、项目描述 |
自动信息 | 着陆页、当前URL、来源、语言、时间 |
处理结果 | 发送到CRM并通知对应销售 |
用户反馈 | 成功页、确认邮件、预计响应时间 |
异常 | 验证失败、重复提交、接口不可用、垃圾信息 |
隐私 | 同意文本、保存期限、删除流程 |
复杂功能可附流程图或现有系统截图。无法确定的规则应标注“由供应商在发现阶段共同定义”，并说明预留范围。
06 第五部分：内容、品牌和素材责任
设计项目延期常来自内容。RFP应说明：
- 是否已有品牌规范、字体授权和设计资产；
- 中文、英文和其他语言由谁撰写、翻译和审核；
- 产品、案例、团队、资质和法律文本由谁提供；
- 图片、视频、图标和插画是使用现有素材、图库还是原创；
- 需要迁移多少历史页面、文章、产品和文件；
- 供应商是否负责内容策略、编辑、录入和校对；
- 内容冻结、更新和最终确认时间。
内容类型 | 甲方责任 | 供应商责任 | 验收方式 |
|---|---|---|---|
公司事实 | 提供和审核 | 结构与编辑建议 | 甲方书面确认 |
服务文案 | 提供专业信息 | 信息架构与文案优化 | 页面评审 |
产品参数 | 提供准确数据 | 数据模板与展示 | 产品团队核验 |
案例 | 授权与事实 | 采访、结构、编辑 | 双方确认 |
法律文本 | 专业审核 | 按确认文本实现 | 法务确认 |
图片素材 | 提供现有资产 | 选图、处理或另行制作 | 授权与画面确认 |
07 第六部分：技术与非功能要求
技术要求不应只写“响应式、速度快、SEO友好”。应说明目标环境和可验证标准。
建议覆盖
- 现有域名、服务器、云平台和技术栈；
- 是否指定CMS、前端框架或必须兼容的系统；
- 浏览器、设备、屏幕和地区；
- 内容角色、权限、版本、审核与回滚；
- 表单、CRM、邮件、分析、地图、视频等集成；
- 性能、缓存、图片、CDN和监测；
- 可访问性目标和测试范围；
- 安全、隐私、日志、备份和恢复；
- 测试环境、正式环境、部署和代码仓库；
- 未来多语言、多区域和系统扩展。
不要指定没有理由的技术
如果企业没有内部维护要求，RFP不必强制某个前端框架。可以描述“需要源代码、组件化、可部署到现有环境、内部团队能继续维护”，让供应商解释方案与取舍。
08 第七部分：SEO和网站迁移要求
若是旧站改版，SEO不能只写“提交搜索引擎”。至少包括：
- 保留现有高价值URL、标题和内容信号；
- 提供旧URL到新URL映射和永久重定向；
- 规范URL、站点地图、robots和索引设置；
- 每个页面可编辑Title、Description、H1和社交标签；
- 多语言独立URL与语言关系；
- 结构化数据与页面真实内容一致；
- 页面性能、移动体验和图片规范；
- Search Console、分析和转化配置；
- 上线前后抓取、404、重定向和索引监测；
- 明确基础SEO设置与持续SEO运营的边界。
RFP还应提供现有自然流量、重要页面和已知SEO问题，便于供应商评估迁移风险。
09 第八部分：交付物与知识产权
“交付网站”过于模糊。建议逐项列出：
交付类别 | 可能包含的文件或资产 |
|---|---|
研究与策略 | 需求记录、用户、信息架构、内容模型 |
UX | 用户流程、线框图、可点击原型、状态说明 |
UI | 桌面/移动设计稿、组件、动效说明、素材 |
设计系统 | Token、组件、模式、文档和使用规范 |
开发 | 前端/后端源码、依赖、构建和部署文件 |
CMS | 内容模型、账号权限、使用说明和培训 |
SEO | URL映射、重定向、元数据、站点地图和检查表 |
测试 | 测试范围、问题清单、修复记录和验收结果 |
上线 | 环境、备份、监测、回滚和账号交接 |
维护 | 服务期限、响应、Bug边界和新增需求方式 |
知识产权部分要区分最终方案、未采用方案、第三方字体、图片、模板、插件、开源代码和供应商已有工具。合同应写明权利在何时、以何种范围转移，以及源文件和代码在尾款后的交付。
10 第九部分：周期、里程碑和双方责任
RFP可以给出目标上线日期，但应允许供应商说明依赖和风险。
候选里程碑
- 项目启动与资料到位；
- 需求和页面范围确认；
- 信息架构与原型确认；
- 视觉方向确认；
- 全量设计确认；
- 开发版本评审；
- 内容迁移与测试；
- 上线与稳定观察；
- 源文件、代码和账号交接。
同时说明甲方反馈时限、最终决策人、内容提交和技术接口责任。若甲方资料延迟或新增范围，周期如何顺延也应写清。
11 第十部分：预算和报价格式
公开预算区间通常能减少不匹配供应商，也能让方案更现实。若企业不便公开，至少要求统一报价拆分。
供应商报价表建议
工作包 | 固定费用/估算 | 包含范围 | 主要假设 | 超范围计价 |
|---|---|---|---|---|
发现与需求 | ||||
信息架构与UX | ||||
UI与设计系统 | ||||
前端与CMS | ||||
内容与迁移 | ||||
测试与上线 | ||||
维护与支持 | ||||
第三方成本 |
要求说明税费、付款节点、差旅、字体、图库、云服务、插件和持续订阅。不要只比较总价，应比较范围、团队、责任和长期成本。
12 第十一部分：要求供应商按统一格式响应
供应商提案至少回答：
- 对项目目标、用户和主要风险的理解；
- 推荐方法、阶段与关键决策；
- 项目团队、角色、投入和实际参与人；
- 2–3个相关案例及真实服务范围；
- 页面、功能、内容和技术方案；
- 里程碑、工期与客户配合要求；
- 交付物、验收与质量保障；
- 报价拆分、假设与变更计价；
- 第三方依赖、知识产权和维护；
- 主要风险、待确认问题和替代建议。
若每家提案结构完全不同，评审人会被漂亮排版影响，忽略范围差异。统一回答框架可以保留创意空间，同时提高可比性。
13 第十二部分：100分供应商评审表
评审维度 | 权重 | 重点判断 |
|---|---|---|
业务与用户理解 | 15 | 是否指出真实问题与优先级 |
方法与策略 | 15 | 阶段是否合理，是否处理不确定性 |
相关案例 | 12 | 实际范围、团队和结果是否可核验 |
团队与协作 | 12 | 提案人是否实际参与，沟通机制是否清楚 |
设计与内容能力 | 12 | 能否同时处理结构、视觉、内容和多端 |
技术与质量 | 12 | 架构、CMS、性能、安全、SEO和测试 |
交付与风险 | 10 | 验收、知识产权、维护和退出机制 |
价格与价值 | 12 | 范围是否完整，总拥有成本是否合理 |
总分 | 100 | 先淘汰红线，再比较总分 |
建议淘汰红线
- 不能说明实际项目团队；
- 案例无法核验服务范围；
- 不提供源文件或代码边界不清；
- 使用第三方资产却不说明授权；
- 保证Google固定排名或无法说明SEO方法；
- 报价不列假设与排除项；
- 无测试、上线、备份和交接方案；
- 关键数据或账号必须由供应商永久控制。
14 第十三部分：沟通、问答与提案流程
建议流程：
- 发布RFP并开放统一提问窗口；
- 将关键答复同步给所有候选供应商；
- 允许供应商提出澄清和替代方案；
- 先评书面响应，再安排短名单提案；
- 提案会要求实际项目团队参加；
- 进行案例核验和客户参考；
- 对范围、价格和合同进行最终澄清；
- 通知结果并进入入场计划。
不要要求大量供应商免费完成完整设计方案。对高风险项目，可以安排有偿发现、工作坊或概念验证，用真实协作表现代替一次性比稿。
15 可复制的RFP目录模板
- 项目名称与文件版本；
- 公司和业务背景；
- 项目原因与目标；
- 用户、市场与关键任务；
- 当前网站、系统和已知问题；
- 页面、模板、内容和语言范围；
- 功能与业务规则；
- 品牌、文案、图片和资料责任；
- 技术、CMS、集成和环境；
- SEO、迁移、性能和可访问性；
- 隐私、安全与行业要求；
- 交付物、源文件、代码和知识产权；
- 项目周期、里程碑和反馈机制；
- 预算、付款与报价格式；
- 供应商资格和响应格式；
- 评审标准、流程和关键日期；
- 合同、维护、退出与保密；
- 附件：页面清单、流程、品牌规范、数据和现有报告。
16 RFP发布前的自检问题
- 一个陌生供应商能否用一句话说清项目为什么做？
- 页面数、模板数、内容数和语言是否区分？
- 功能是否包含输入、结果、异常和后台责任？
- 文案、翻译、素材和迁移由谁负责？
- 技术指定是因为真实约束，还是个人偏好？
- SEO、隐私、性能和可访问性是否可验证？
- 交付物、账号、源文件和代码是否明确？
- 预算是否能覆盖期望范围？
- 反馈人、决策人和验收人是否确认？
- 供应商是否按照统一格式报价和回答？
- 评分权重是否与业务目标一致？
- 哪些问题允许供应商提出更好的替代方案？
常见问题
1. 小型网站项目也需要RFP吗？
不一定需要正式长文档，但至少应有一页项目Brief、页面清单、功能、交付、周期和预算。项目越小，沟通成本越应控制。
2. RFP应该公开预算吗？
有明确预算区间时建议公开，可减少无效提案。若暂不公开，应要求不同范围选项和统一拆分，避免只收到一个总价。
3. 是否应该要求供应商免费设计首页？
通常不建议把完整免费比稿作为主要判断。案例、方法、团队、工作坊和有偿概念验证更能反映真实合作质量。
4. 页面清单还不确定怎么办？
可以给候选范围、现有内容和业务目标，要求供应商在发现阶段确认，并在报价中列出容量、假设和调整机制。
5. 如何避免中标后不断加价？
先明确范围、计数方式、修改轮次、排除项和变更单价；要求报价写明假设。新增范围应书面确认费用和周期。
6. RFP和最终合同是否可以完全一致？
RFP是采购输入，供应商提案和澄清会改变细节。最终应把确认范围、报价、交付、周期和责任转化为合同附件。
结论：RFP的价值是减少隐藏假设
设计与网站项目中，最大的采购风险往往不是供应商报价高低，而是双方理解的项目根本不同。清晰RFP能够让供应商在同一目标和边界下提出方案，评审团队也能比较真实价值，而不是只比较作品和总价。
把业务目标、用户任务、范围、技术、内容、交付、预算、时间和评审标准写清，同时允许供应商提出专业取舍，这才是一份成熟的方案征询文件。
