学校无线计费招标，需求书怎么写，基本决定了后面顺不顺利。我们看过不少需求书，要么写得过于笼统被厂商随意填坑，要么堆了一堆用不上的功能显得专业，真正关键的反而漏了。招标前把需求想透，比评标时纠结谁家便宜重要得多。下面几个坑，踩过的学校不在少数。
坑一：把计费和认证混为一谈
很多需求书把无线认证和计费写成一块，结果厂商拿认证的方案来充计费，或者反过来。两者确实相关，但关注点不同：认证管你是谁、能不能进；计费管你用了多少、怎么收。我们建议需求里把两块拆开写，各自的功能点列清。混着写，评标时根本比不出真假，最后买到的可能是半套。
坑二：只写功能不写边界场景
需求书写了一堆功能列表，却没写边界场景：晚高峰并发多少、假期怎么处理、欠费停机分几档。厂商按最低标准实现，上线后发现关键场景全没覆盖。我们帮学校改需求时，会补一章边界场景清单，把并发峰值、特殊时期、异常流量都写进去。功能清单是骨架，场景才是血肉。
坑三：忽视一卡通对接要求
前面说过一卡通对接多关键，但很多需求书压根没提，或者只写一句支持对接。等中标了才发现厂商接口能力薄弱，对接做不动。我们建议需求里明确一卡通对接的层数：身份、钱包、停机联动，以及要求厂商说明现有接口能力。把对接写实，后面才不卡。
坑四：账务合规一笔带过
涉及向学生收费，账务合规是硬要求：账目独立、可对平、可审计、有发票路径。不少需求书只字不提，上线后财务发现对不上、查不清，项目卡在财务关。我们建议把合规要求单列，明确账目隔离、定期对账、审计导出格式。合规不是可选项，是能不能收钱的前提。
坑五：性能指标没有压测口径
需求写支持高并发，但没给具体数字和压测方式，厂商说自己支持就算支持。我们见过写支持五千并发，实际两千就崩。我们建议需求里写清压测标准：按真实峰值二到三倍、模拟哪些计费事件、允许的差异率多少。把压测口径钉死，评标才有共同尺度。
坑六：运维和培训被当成赠品
很多学校把运维和培训当厂商附赠，需求里不写清楚，结果上线后没人会调规则、没人会对账。我们建议需求明确运维边界：规则调整响应时间、对账支持方式、管理员培训内容。计费系统是要长期调的，没人会调，买来也是摆设。
坑七：验收只看功能清单
验收时对着需求一条条勾功能，勾完就付尾款，结果真实场景一跑全露馅。我们建议验收加一场真实场景演练：晚高峰模拟、欠费停机、充值复通、一卡通联动，学生实测走一遍。功能勾完了不算完，场景跑通了才算。
给我们的总结
招标需求写得好，后面省一半力。我们做咨询时常说，需求书是学校的第一道防线，写得含糊就等于把解释权交给厂商。把认证和计费拆开、把场景写细、把对接和合规写实、把压测口径钉死，这几个坑避开，评标和上线都会顺很多。
评标别只比价格
需求写好之后，评标如果只看谁便宜，前面功夫就白费了。我们建议评标按需求逐条核对，功能、场景、对接、合规、压测口径各有权重，价格只占一部分。低价中标最后交付缩水的例子太多了。把评标标准写进招标文件，厂商才不敢在关键处偷工。
留一段试运行再付尾款
前面说验收要跑真实场景，落实上我们建议留一笔尾款绑定试运行。系统跑满一个完整学期，账单稳、对账清、学生没大投诉，再付尾款。这样学校手里始终有筹码，厂商不敢交付完就消失。试运行不是不信任，是给双方都留个缓冲。
需求文档要存档可追溯
招标需求定完要归档，谁提的、为什么这么写，留痕可查。我们见过几年后系统要升级，没人说得清当初需求依据，又得从头想。文档留痕，是学校的长期资产。
别怕在招标阶段多花时间
招标前把需求磨细，看起来慢，其实最省时间。我们见过学校急着招完标，结果实施阶段反复改，总工期反而更长。前面慢一点，后面才快。
把坑讲给下一波人听
招标踩过的坑，是最贵的经验。我们建议每所学校把本次招标的得失写成一份短备忘，留给下一轮采购参考。很多学校同样类型的坑反复踩，就是因为没有把教训留下来。坑不可怕，可怕的是踩完就忘。
评标专家要懂业务
评标不能只靠懂技术的专家，最好有熟悉学校运营和财务流程的人一起。我们见过纯技术专家评出来的方案，功能漂亮但落地处处碰壁。业务视角进场，才能看出需求到底有没有被满足。