招标文件的写法，直接决定你招来的是什么方案

写招标文件是校园WiFi计费系统建设中最容易被低估的一环。

很多学校的做法是让供应商帮忙起草技术参数，供应商当然愿意，毕竟自己的产品参数最好看。问题是这样写出来的标书往往有两个特点：一是把供应商自己的优势写得很细，把缺点一笔带过；二是技术指标堆得很高但实际上不一定用得上，学校花了大价钱买回来的功能其实是闲置的。

自己写招标技术参数，不是因为不信任供应商，而是因为学校自己要什么只有自己最清楚。

招标前要做的事，比写标书更重要

在动笔写技术参数之前，有几件基础工作要先做：

第一，摸清现有网络架构。宿舍区用什么设备、教学区用什么设备、出口接了几家运营商的BRAS、认证计费系统现在有没有、运维团队几个人——这些情况直接影响方案选型，不了解清楚就写参数，写出来的参数大概率脱离实际。

第二，明确核心诉求和优先级。是要解决私接盗用的问题？是要对接一卡通？是要合规过检？还是就想换个新的界面更好的系统？核心诉求不同，采购的技术侧重点完全不一样。

第三，参考同类型学校的实际方案。不一定非要找一模一样规模的学校，但要看同等带宽规模、同等运维能力、同等管理模式的项目是怎么做的，走了哪些弯路。闭门造车写出来的参数，往往忽略了实施落地的现实约束。

技术参数要写什么，不写什么

招标文件中技术参数部分，有几类内容要写，也有几类内容要慎重。

一定要写清楚的：并发用户数和性能指标要有量级描述，但不要写具体数字——具体数字应该要求供应商提供实测数据，或者在POC测试阶段验证；日志留存能力要和监管部门的要求对齐，写清楚保留周期和字段完整性要求；对接标准要明确，比如是否需要支持RADIUS、LDAP，跟哪些既有系统对接；故障响应要求要写具体，比如核心时段几小时内到场，SLA违约怎么罚。

要慎写的：不要用"国内知名品牌""市场占有率前几名"这类模糊表述当门槛，这类表述往往最后变成了内定的工具；也不要过度堆砌功能指标，把"有"和"用得上"混为一谈。功能数量多不等于实用，能解决自己核心问题的功能才是应该写进去的。

POC测试这个环节，不建议省

对于规模较大的项目，建议在正式招标之前安排POC测试环节——让入围的供应商在真实网络环境里跑一段时间，用真实的学生流量数据验证方案。

POC测试能验证的东西比纸面参数多得多：并发性能是供应商说多少就是多少，还是真能在宿舍高峰期扛住；防私接准确率标得漂亮，实际误判率怎么样；日志查询界面说的"秒级响应"，真实数据量下能不能做到。这些东西看参数看不出区别，一跑就知道。

POC测试还有一个好处是把学校自己的运维人员拉进来参与评估。让他们实际用一下供应商的系统和管理界面，比听供应商讲PPT演示要有用得多。

评分规则定得不好，最容易出问题

招标评分规则一般分技术分和商务分两部分。技术分如果只看功能列表，功能多的供应商得分就高，容易诱导供应商堆砌功能而不是打磨核心能力。

建议的评分思路是：技术分重点看核心功能模块的实际能力，比如计费准确性、防私接准确率、日志留存完整性、实施保障方案这几项，而不是比谁的参数列表长。商务分看价格、售后服务、违约条款这些实质内容。

价格评分有个常见陷阱是"最低价中标"。校园WiFi计费系统不是标准化商品，价格最低不代表性价比最高，后续运维成本、实施失败风险都是代价。价格分建议设上限，不鼓励供应商恶性低价抢标。

说在最后

招标文件是整个项目的起点，起点偏了，后面修正的代价很大。在写技术参数之前多花时间做调研、多跑几个学校看现场、多让自己的运维团队参与讨论，这些投入在评标和实施阶段都会还回来。与其买回来之后不断打补丁，不如买之前多花点功夫想清楚。