科技券项目范围描述模糊，被要求澄清的改写法
科技券（Technology Vouchers Programme，简称 TVP）是很多香港中小企业第一次接触的政府资助。它的好处写得明白——每家累计最多资助港币 60 万元，项目自负三成、资助七成，做 IT 升级、做云迁移、做管理系统都行。但真正坐下来写申请，很多申请人会卡在同一个环节：「项目范围」这一栏写得太模糊。
秘书处审核员看完，往往会发出「澄清要求」（Request for Clarification，简称 RFI），轻则要求补料、重则要求改写后再交，更严重时直接以「项目范围不清晰」为由拒件。本篇文章把科技券项目范围被驳回的真实原因拆给你看，并给你一份「改写法」模板，方便你直接对照重写。
一、为什么秘书处一定要「项目范围」写得清楚？
科技券的本质是「按项目资助」——批钱只批一个有起止日期、有明确交付物、有清晰预算的特定项目，而不是模糊的「公司 IT 升级」。
秘书处需要从「项目范围」一栏判断三件事：
- 是不是一次性项目：跟日常运营开支能区分开。
- 是不是与业务相关：能解决公司某个具体痛点。
- 预算是否合理：金额能否对应到明确的范围、模块、人月。
所以「项目范围」这一栏不是「用两句话交代一下要做什么」，而是整份申请的骨架。下面是常见的「模糊写法」，几乎一定会触发澄清：
| 模糊写法 | 为什么会被要求澄清 |
|---|---|
| 「升级公司 IT 系统」 | 哪个系统？现状是什么？要升级到什么样？ |
| 「引入 ERP」 | 哪个模块？覆盖哪些部门？分几期？ |
| 「优化网络安全」 | 解决什么风险？要买设备还是订 SaaS？ |
| 「建立数据分析能力」 | 分析什么数据？输出什么报表？给谁用？ |
二、秘书处要求澄清的常见原因（按出现频率排序）
在过往的科技券申请案例中，触发「澄清要求」的原因大致有以下几类：
1. 范围使用泛词（Upgrade / Enhance / Improve）
「Upgrade」「Enhance」「Improve」「Transform」是审核员最反感的词。它们没有客观标准，写进去等于没写。
示范对比
❌「升级公司 ERP 系统」 ✅「将现有人工 Excel 排程，替换为云端 ERP 的生产排程与库存管理模块，覆盖生产线 A、B 两条产线」
2. 没有量化目标与现状
「提升效率」「降低错误率」「改善客户体验」——这些是营销话术，不是项目范围。审核员需要看到数字。
示范对比
❌「提升订单处理效率」 ✅「把订单录入时间由平均每张 8 分钟缩短至 3 分钟以内，月处理量由 1.2 万张提升至 2 万张」
3. 模块边界不清，预算无法对应
「项目范围」如果只写一段话，没有拆成模块，预算表里的每一项支出就无法回扣到具体交付物。秘书处会怀疑报价虚高或重复计价。
4. 与日常运营混淆
例如：「为公司员工提供电脑与软件订阅」——这属于日常 IT 运营开支，不属于「项目」。秘书处会要求你删去或重新定义项目边界。
5. 跨度过大
「3 个月内完成集团数字化转型」——范围大、周期短、预算不确定，秘书处几乎必然要求你拆细。
三、合格的「项目范围」必须包含的四要素
一份能被顺利接受的「项目范围」描述，建议同时包含以下四个要素，缺一不可：
要素 1：起点（Baseline）
用 1-2 句话讲清楚现在的情况。现状越具体，越能体现这个项目存在的必要性。
示例：「本公司目前使用 Excel 加人工对账，每月出错约 15 笔，客户投诉集中在月初 5 个工作日。」
要素 2：终点（Target State）
用 1-2 句话讲清楚项目完成后会变成怎样。尽量带上可量化指标。
示例：「上线云端 ERP 后，预计出错率降至每季度不超过 3 笔，月初对账周期由 5 个工作日缩短至 2 个工作日。」
要素 3：模块与交付物（Scope & Deliverables）
把项目拆成 3-6 个模块，每个模块列出交付物。模块的颗粒度要对应到预算表的科目。
示例：
- 模块 A：基础平台部署（交付物：云端 ERP 实例、用户账号 30 个）
- 模块 B：生产排程与库存模块上线（交付物：上线报告、培训 3 场）
- 模块 C：财务对账模块上线（交付物：对账自动化脚本 1 套、报表模板 5 张）
要素 4：项目期与责任边界（Timeline & Exclusions）
明确项目期、写明不包含什么。例如不包含硬件采购、不包含日后订阅费、不包含员工加班补贴。责任边界写清楚，可以大幅减少后续被质疑「超出范围」的风险。
四、改写法：把模糊描述重写成可接受的版本
下面给出一个真实场景的「前后对比」。假设你的公司是做餐饮供应链的，目前用纸本 + WhatsApp 接单，想申请科技券做订单管理系统。
改写前（容易被打回）
本公司计划引入一套订单管理系统，用于处理客户的下单、对账与配送安排，提升整体运营效率，减少人为错误。本项目预计需要港币 40 万元。
改写后（可直接放入申请书的版本）
项目范围
现状：本公司目前以纸本单据配合 WhatsApp 群组接单，日均订单约 200 张，错误率约 5%，每月因漏单、错单造成的损耗约港币 2 万元；客户对账需要 2 名员工全职耗时 3 个工作日。
目标：本项目上线一套云端订单管理系统（B2B 订单模块 + 配送调度模块），实现下单、对账、配送安排的全流程数字化。预期上线 3 个月后，订单错误率降至 1% 以下，月度对账工时由 6 个工作日缩短至 1 个工作日。
模块与交付物：
模块 主要交付物 A. 平台部署与数据迁移 云端订单系统 1 套、客户主数据迁移约 300 条 B. B2B 订单与对账模块 下单门户、自动化对账脚本、月结报表模板 C. 配送调度模块 配送排程看板、司机移动端 App D. 培训与上线支持 培训 4 场、操作手册 1 套、3 个月上线陪跑 项目期与边界：项目期 12 个月（以官方最新公布为准），起止日期见申请书 G 栏。预算涵盖软件一次性配置费、实施服务费、培训费；不包含硬件采购、员工加班补贴、后续年度订阅费、办公室网络升级等开支。
上面这段写法的关键，是把「引入一套系统」改写成场景化的、可量化、可拆模块的工程语言。预算表里每一项支出，都能在模块里找到对应位置。
五、被要求澄清时的应对步骤
万一你提交后收到秘书处的澄清信，建议按下面顺序处理：
- 先看问题清单：秘书处的澄清信通常会列出编号问题，逐条回应，不要合并作答。
- 用同一份文件标注修改：保留原文件，在项目范围段落直接用粗体或下划线标出新增内容，方便审核员对照。
- 补充量化数据：如果被要求「说明预期效益」，请尽量提供测算逻辑，而不是「提升效率 30%」这种空洞数字。
- 不要临时改方案：澄清不是改方案的机会，大方向不应改变。若澄清后改动过大，建议主动撤回并重新申请。
- 注意澄清期限：秘书处会给出回复时限，通常为数个工作日。逾期未回复可能被视为放弃申请。
六、写「项目范围」时常见的额外踩雷点
- 写得太长、没结构：超过 500 字却没有分段、没有标题，审核员抓不到重点。
- 照抄供应商提案：直接复制系统集成商的销售提案，里面满是产品型号与技术参数，反而显得「采购导向」而非「业务导向」。
- 把员工培训当作整个项目：科技券允许列培训费，但不接受「培训一个员工会用软件」作为唯一范围。
- 忽略「不包含什么」：不写排除项，秘书处会默认把含糊部分也算入项目，导致预算被质疑。
结语
科技券的申请并不复杂，但它的语言是「工程语言」，不是「营销语言」。把「项目范围」从模糊走向清晰，关键是把现状写实、把目标量化、把模块拆细、把边界写死。做到这四点，澄清信出现的概率会大幅下降。
具体申请资格、资助比例、累计上限等数字，会随政府最新公布调整，以官方最新公布为准；香港大全 会持续整理香港各项中小企业资助计划的最新政策与实务经验，更多关于高才通、专才计划、IANG 签证、税务申报、香港银行开户等香港相关指南，欢迎站内查阅。
常见问答
科技券「项目范围」到底要写多少字才够？
文章没有给出一个固定的字数标准，但强调结构比篇幅更关键：建议分成「现状—目标—模块与交付物—项目期与边界」四段写，每段 1–2 句到一小段皆可，整体控制在能让审核员快速抓到重点的范围内。如果超过 500 字却没分段没小标题，反而容易被认为「抓不到重点」而触发澄清。
收到科技券的澄清信（Request for Clarification），是不是等于被拒了？
不一定。文章将澄清要求定位为「补料、改写后再交」的中间环节，轻重程度不同：轻则要求补料，重则要求改写后再交，更严重才会以「项目范围不清晰」为由拒件。关键在于按编号问题逐条回应、补充量化数据，且不要在澄清阶段临时大改方案；若改动过大，主动撤回重申请往往比硬着头皮补料更稳妥。
「升级公司 IT 系统」「引入 ERP」这类常见写法，为什么会被打回？
文章列出了四类典型「模糊写法」，几乎都会触发澄清：只写「升级 IT 系统」会被问哪个系统、现状是什么、要升级到什么样；只写「引入 ERP」会被问哪个模块、覆盖哪些部门、分几期；「优化网络安全」会被问解决什么风险、买设备还是订 SaaS；「建立数据分析能力」会被问分析什么数据、输出什么报表、给谁用。问题的根源是这些表述没有客观标准，审核员无法对应到模块与预算。
项目范围里要不要写「不包含什么」？
建议写。文章把「不写排除项」列为常见踩雷点之一：不写明不包含的内容，秘书处会默认把含糊部分也算入项目，进而质疑预算是否合理。改写模板里专门列出了「不包含硬件采购、员工加班补贴、后续年度订阅费、办公室网络升级等开支」一类表述，责任边界越清楚，后续被质疑「超出范围」的风险就越低。
把供应商的销售提案直接复制到「项目范围」一栏，可以吗？
不建议。文章明确指出「照抄供应商提案」是常见踩雷点：销售提案里满是产品型号与技术参数，复制进申请会显得「采购导向」而非「业务导向」，反而削弱项目范围的业务相关性。正确的写法是用自己的业务语言描述现状、目标与模块，预算表的每一项支出都能在模块里找到对应位置，而不是用产品清单替代项目范围。
科技券的累计资助上限和自负比例是多少？之后会变吗？
文章给出的数字是「每家累计最多资助港币 60 万元，项目自负三成、资助七成」，但同时提示「具体申请资格、资助比例、累计上限等数字，会随政府最新公布调整，以官方最新公布为准」。准备申请前，建议直接以官方最新公布为准，避免按过时数字写预算导致后续被要求调整。