做转运平台项目的甲方，多数不是第一次写信息化采购参数。但转运这个场景有两个特殊之处：它横跨急救与非急救两套体系，又同时面向主管部门、服务商、医院、患者四类用户。参数写得笼统，评标时无法横向比较；写得过细，又容易把某一家厂商的实现方式写进标书。合理的做法是分层：功能项、性能项、对接项，三层各有各的写法。
一、最常见的写法问题：把功能写成菜单
不少标书的技术参数是这种形态：「支持订单管理、支持车辆管理、支持人员管理、支持统计分析」。这类表述的问题不在于错，而在于无法验证——任何一家厂商都能全部响应，评标专家也无从判断差异，最终只能比价格。
参数的作用不是描述系统有什么，而是描述系统必须做到什么程度。同样一个「派单」，写成「支持自动派单」和写成「在指定半径内按规则筛出候选车辆，超时未接单按预设间隔扩大范围，扩圈过程与结果均留痕」，得到的是完全不同的交付结果。
二、功能项：写「能力」而不是「菜单」
功能项建议按「触发条件—系统动作—留痕结果」三段式描述，每一段都对应一个可演示、可验收的动作。
| 常见写法 | 问题 | 可验收写法 |
|---|---|---|
| 支持自动派单 | 无法验证派单规则是否可配置 | 可按距离、服务商评分、车辆状态组合配置候选规则；派单失败时按设定间隔扩圈，扩圈记录可查 |
| 支持资质管理 | 无法验证证照过期后的行为 | 人员或车辆证照到期后自动退出派单候选范围，并在列表中标记状态与剩余天数 |
| 支持数据统计 | 无法验证口径是否一致 | 按日、周、月统计订单量、完成率、平均响应时长，统计口径在页面内注明，支持导出明细 |
| 支持监管查询 | 无法验证权限边界 | 监管账号按辖区与角色授权，仅可查看授权范围内订单与车辆轨迹，操作行为记录日志 |
按这个标准写，一条参数往往从六个字变成六十字。工作量增加，但换来的是评标可比较、验收可对照。
三、性能项：指标必须带测试方法
性能是最容易被写成空话的一节。常见表述是「系统响应快、支持高并发」，这种描述无法验收。建议至少量化三项，并写清测试条件：
- 并发受理能力：明确同时在线的坐席数、每分钟可受理的订单峰值，以及测试时的部署形态（单机 / 集群）。
- 关键操作响应时长：把「响应」拆成具体动作——订单创建、候选车辆返回、轨迹刷新，分别给出口径，注明是服务端处理时间还是含网络传输的端到端时间。
- 可用性：按年或按月给出目标值，并约定统计方式（是否排除计划内维护窗口）。
需要提醒的是，具体数值应当由本市的订单规模测算得出，而不是照抄其他城市的参数。日均订单量相差一个数量级，对部署形态与性能指标的要求完全不同。
四、对接项：五类接口单独列，写清责任方
对接是最容易在上线阶段产生争议的部分。原因通常是标书里只写「支持对接」，没写接口由谁提供、联调由谁配合、对方系统不具备条件时如何处理。
| 对接对象 | 典型内容 | 需在参数中写明的责任边界 |
|---|---|---|
| 医院信息系统 | 患者基本信息、床位与出院时间、转运申请 | 医院侧开放接口的责任方、字段范围、联调窗口期 |
| 支付与结算 | 在线支付、退款、对账单 | 支持的支付渠道、结算周期、对账差异处理方式 |
| 短信与消息 | 下单通知、派车通知、到达提醒 | 通道提供方、发送量上限、失败重试策略 |
| 地图与定位 | 地址解析、路径规划、轨迹回传 | 底图来源与授权、坐标体系、轨迹保存期限 |
| 政务云与统一认证 | 部署环境、账号体系、日志归集 | 是否要求适配既有云平台、等保测评配合方式 |
其中「对方系统不具备条件」这一情形，务必在参数中给出替代方案（如提供标准模板导入、人工录入通道），否则项目容易卡在联调阶段。
五、四类内容不宜写死
- 品牌与型号：除非有明确依据，不应指定具体厂商或产品型号。
- 独家实现方式：把某家的技术路线写成强制要求，等于排除竞争。
- 过度定制的一次性功能：写进标书的定制项越多，后期维护成本越高，且难以随政策变化调整。
- 具体金额：参数文件写功能与指标，价格由商务部分承载，两者混写容易引发质疑。
六、一份可用的参数框架
按以下顺序组织，评审时更容易对照：
- 总体要求：建设目标、用户范围、部署形态、标准依据
- 功能需求：按端组织（用户端、调度端、服务商端、监管端、机构端），每端按「触发—动作—留痕」写
- 性能需求：并发、响应、可用性，附测试方法
- 对接需求：五类接口逐条列责任边界
- 数据需求：字段范围、保存期限、导出格式、移交要求
- 安全需求：等保级别、权限模型、日志留存
- 交付与验收：交付物清单、验收步骤、试运行期限
需要这份框架的可编辑版本，可以联系我们获取；也可以把本市现有的参数稿发来，我们按上述分层做一次对照标注。