做高校信息化项目合同的时候，很多学校用的是一套通用的采购合同模板，里面有功能需求描述、付款节点、验收条款，看起来像模像样，但一旦进入实施阶段，各种没有写清楚的细节开始产生争议，学校说甲方理所当然，厂商说合同没有约定，两边都有道理，问题就悬在那儿解决不了。

校园上网计费系统因为涉及财务流水、学生账号、第三方系统对接，合同里如果有模糊地带，产生的摩擦比普通信息化项目更频繁。整理了五件必须在合同里写清楚的事，供采购方参考。

认证成功率和计费延迟的量化指标必须进合同。合同里写"系统运行稳定"是没有意义的，稳定是主观评价，争议发生的时候双方各有解释。学校认为开学第一天晚上大面积认证失败是"不稳定"，厂商说功能模块全部正常只是并发峰值超出预估，双方标准不一，扯不清楚。应该写的是量化指标：认证成功率在正常使用期间不低于99.5%，在开学高峰期（学生集中回校的前72小时）不低于98%；充值到账后上网策略刷新时间不超过30秒；计费扣费延迟不超过5分钟。还要写清楚这些指标在什么条件下测量——以系统日志为依据还是监控平台数据为依据，出现争议时以谁提供的数据为准。有了量化指标，验收时有依据，出了问题追责时有标准，厂商也会在系统设计阶段认真对待这些数字。

数据迁移的完整性验收必须单独列为一个验收节点。大多数合同的验收条款是"系统功能验收"和"试运行期验收"两个节点，数据迁移完整性没有单独列出来。这意味着数据迁移完成后，没有一个明确的时间点要求双方坐下来核对数据，如果有遗漏，可能要到学生投诉之后才被发现。建议在合同里把数据迁移完整性验收单独写成一个节点，时间节点建议在系统功能验收之前，核对内容包括：账号总数核对（旧系统账号数与迁移后新系统账号数的比对，允许差值±0）；计费记录核对（随机抽查100条历史计费记录，逐条验证金额、时间、账号是否一致）；欠费记录核对（欠费账号总数和总欠费金额，新旧系统必须完全一致）。这个节点通过之后再进行功能验收，这样即使功能验收时发现有问题，数据这边已经有了明确的确认记录，责任归属更清晰。

运营商代拨的接口和账号同步必须写明责任边界。如果学校是代拨模式，合同里需要对运营商侧的接口对接责任做明确说明，这不是一个纯粹的技术问题。厂商提供哪些技术接口和对接文档，学校负责协调哪家运营商完成哪项对接授权，运营商侧账号同步延迟超过多少分钟算作异常，异常时由厂商出排查报告还是由学校联系运营商，代拨失败时学生端提示文案由谁提供、是否需要多语言版本，这些细节如果不写进合同，实施阶段最容易出现的情况是：代拨对接卡在运营商侧接口审批上，厂商说这不是他们的责任，学校说厂商说好支持代拨，对不上，项目延期，学生开学时代拨功能还没上线。

日志留存的格式、周期、查询响应时间必须达到等保标准。等保2.0对网络日志的要求是具体的，不是一句"保留6个月"就能应付的。合同里应该写清楚：上网行为日志的留存格式（是否满足等保测评机构的要求，建议直接把等保要求的格式规范附在合同附件里）；日志查询响应时间（输入查询条件后多少秒内返回结果）；谁有权限查询日志（是只有网络中心还是公安机关依法调取也支持）；日志留存期间的完整性保证（是否有防篡改机制，是否有完整性校验日志）。如果等保测评机构检查时发现日志格式不符合要求，学校有权利依据合同要求厂商整改，而不是学校自己承担整改成本。但这个前提是合同里写清楚了格式标准。

系统升级和安全补丁的维护周期必须明确。校园上网计费系统通常是一次签约、多年使用的，但系统的安全漏洞是持续出现的。如果合同里没有约定厂商在哪个期限内必须提供安全补丁，厂商完全可以在产品迭代到新版本之后停止对老版本的安全支持，学校继续在老版本上跑，漏洞暴露在那儿没人管。合同里应该写明：厂商对合同期内使用版本的安全补丁支持周期是多少年；发现严重安全漏洞后厂商提供补丁的最长时限是多少小时；系统升级提供免费版本的条件是什么，大版本升级和小版本升级是否有区分。

这五件事不是法律条款，不需要律师帮着写，但每件事背后都有真实发生过的项目争议。把这些东西写进合同，是在给未来可能发生的摩擦加一道防线。