一份可用的工单系统评估清单，需要覆盖五类信息：谁在什么阶段使用、分阶段检查项、每项的通过标准、证据与负责人、阻断项与完成条件。清单的价值在于每项都能判定“通过”或“不通过”，并留下可核查的证据。本文按选型初筛、试用评审、上线前验收的顺序给出可直接填写的检查表，聚焦工单平台本身，供服务台、IT 管理、采购与安全合规等角色共用一套口径。
要点总览（TL;DR）
- 清单按角色—阶段—检查项—通过标准—证据—负责人—阻断项组织，覆盖选型初筛、试用评审、上线前验收三个阶段。
- 每项检查要写成可演示、可复现的动作，通过标准写成观察得到的结果，例如“在试用环境中完成一次跨团队转派并留痕”。
- 证据以配置截图、演示记录、测试用例结果、合同或报价文件为主，统一存放并按阶段复核。
- 阻断项与普通检查项分开管理：核心流转、权限隔离、数据导出、安全要求任一项不通过，不进入下一阶段。
- 评估结束输出结论页，包含通过项数量、差异项清单、阻断项状态和最终结论。
谁在什么时点使用这份评估清单
清单先定使用规则，再谈检查内容。同一套检查项由不同角色在不同阶段填写，判定口径容易分叉，因此要在表头固定三件事：谁填、什么时候填、填完得出什么结论。
参与角色按职责分工：业务提单人关注提交入口是否顺畅、进度是否可见；服务台或运维负责人关注流转、SLA 与知识沉淀；IT 管理员关注权限、集成与部署；采购与安全合规关注合同条款、数据存放与审计。每个角色只对自己职责范围内的检查项提供证据和判定意见，避免所有人都对全部项目打分。
三个阶段使用清单的不同部分，输出不同结论：
| 阶段 | 主要参与角色 | 使用的清单部分 | 输出结论 |
|---|---|---|---|
| 选型初筛 | 服务台负责人、IT 管理员 | 需求与范围、核心流转能力、部署方式与成本口径 | 入围：进入试用名单 |
| 试用评审 | 服务台负责人、业务提单人代表、IT 管理员 | 流转能力、权限与通知、集成与数据、报表 | 可试用转可采购：形成差异记录 |
| 上线前验收 | IT 管理员、安全合规、采购 | 部署与安全、数据迁移、合同与报价核对 | 可上线：阻断项全部通过 |
阶段结论要写成明确状态，例如“入围”“不入围”“可上线”“整改后复测”，并注明判定人和日期。初筛阶段不要求提供试用环境证据，验收阶段则必须以实际配置和测试结果为准，两个阶段的证据标准不同，清单中应分别标注。
需求与范围阶段：先确认要评什么
进入产品对比前，先把工单范围、服务对象和边界固定下来，否则后续检查项没有统一的判定基准。范围确认本身也是检查项，未完成则不进入产品评审。
范围确认检查表建议包含以下内容，每项写明通过标准、证据和负责人：
| 检查项 | 通过标准示例 | 证据 | 负责人 |
|---|---|---|---|
| 工单类型清单 | 列出全部工单类型（如故障报修、账号申请、咨询、投诉），每类注明典型处理路径 | 工单类型清单文档，经服务台负责人确认 | 服务台负责人 |
| 来源渠道 | 明确需要支持的门户、邮件、IM、API 等渠道，并标注哪些为必须、哪些为可选 | 渠道需求表，业务方签字 | 业务提单人代表 |
| 服务对象与组织范围 | 写明服务人数、部门数量，是否需要多团队隔离或多租户 | 组织范围说明，HR 或行政部门提供数据 | IT 管理员 |
| 与运维套件的边界 | 明确本次只评工单平台，资产台账、监控告警等由既有系统承担，接口需求单列 | 边界说明一页纸，IT 负责人确认 | IT 负责人 |
| 旧系统处理方式 | 确认旧系统替换另行立项，本次评估不包含迁移方案评审 | 立项说明或会议纪要 | 项目发起人 |
本阶段的阻断项是范围未定：工单类型、服务对象、必须支持的渠道三项中任一项缺失，就不进入产品评审。范围确认完成后，后续所有检查项都以这份范围说明为参照，超出范围的诉求记录为待定项，不临时加入评估。
工单流转能力检查项与通过标准
流转能力是工单系统的核心，检查项要写成可演示、可复现的动作，通过标准写成观察得到的结果。以下检查表可直接填入试用记录：
| 检查项 | 通过标准示例 | 证据 |
|---|---|---|
| 工单创建与分类 | 在试用环境中通过门户提交一张工单，选择类型与分类后自动带入对应字段 | 提交截图、表单配置截图 |
| 优先级与指派 | 按规则自动指派到对应处理人，手动改派后原处理人收到通知 | 指派规则配置截图、通知记录 |
| 转派与跨团队协作 | 完成一次跨团队转派，转派原因、经手人和时间在工单上留痕 | 工单详情截图 |
| SLA 计时与暂停 | 设置响应与解决时限，工单进入等待用户状态时计时暂停，恢复后继续累计 | SLA 配置截图、计时记录 |
| 升级与超时提醒 | 临近超时触发提醒，超时后按规则升级到上级处理人 | 提醒记录、升级日志 |
| 状态流转与自定义流程 | 按预设状态流转完成一张工单全流程，流程节点可增删并生效 | 流程配置截图、流转记录 |
| 审批节点 | 在指定节点插入审批，审批通过后工单继续流转，驳回后回到上一节点 | 审批记录截图 |
| 知识库与自助提交 | 提单时展示关联知识条目，用户按知识自助解决后可标记为已解决 | 知识关联截图、自助解决记录 |
| 重复工单合并 | 将两张同类工单合并，处理记录与通知归并到主工单 | 合并前后截图 |
判定时以“在试用环境中完成一次并留痕”为准，产品介绍中的功能描述只作为初筛参考。SLA 的计时口径（按工作日还是自然日、暂停条件）要在通过标准中写明，不同产品默认口径不同，验收时按企业实际排班核对。
权限、通知与协作检查项
权限和通知决定工单系统能否在真实组织中运转。检查重点是数据可见范围是否可控、通知是否触达且不打扰、内外部沟通是否分开。
| 检查项 | 通过标准示例 | 证据 |
|---|---|---|
| 角色与数据权限 | 配置至少三种角色（提单人、处理人、管理员），各角色只能看到授权范围内的工单 | 角色配置截图、越权访问测试记录 |
| 字段级权限 | 敏感字段（如联系方式、内部成本）对指定角色隐藏或只读 | 字段权限配置截图 |
| 通知渠道 | 站内、邮件、IM 至少两种渠道可配置，通知内容包含工单编号与关键状态 | 通知配置截图、实际收到的通知 |
| 免打扰与订阅规则 | 用户可按工单或按类型订阅，非工作时间免打扰规则生效 | 订阅设置截图 |
| 评论与 @提醒 | 在工单内 @ 同事，对方收到提醒并可回复，记录保留在工单时间线 | 评论记录截图 |
| 内部备注与对外回复区分 | 内部备注仅处理人可见，对外回复同步给提单人，两者在界面上有明确标识 | 界面截图、提单人视角验证 |
权限检查要包含一次越权测试：用低权限账号尝试访问未授权工单，确认被拒绝或不可见。通知检查要记录实际收到的通知样本，仅看配置页面不足以判定触达。
集成、数据与报表检查项
集成与数据决定工单系统能否融入现有工具链，报表决定管理层能否据此做判断。检查项如下：
| 检查项 | 通过标准示例 | 证据 |
|---|---|---|
| 开放 API 与 Webhook | 用测试账号调用创建工单接口成功，Webhook 在状态变更时推送事件 | 接口调用记录、推送日志 |
| 单点登录 | 通过企业统一身份认证登录，账号停用后无法再登录 | 登录测试记录、配置截图 |
| IM 与邮件对接 | IM 内提交的工单进入系统并回传处理进度，邮件回复可追加到工单 | 对接配置截图、往返测试记录 |
| 监控告警对接 | 告警触发后自动生成工单，携带来源与严重级别字段 | 告警到工单的链路截图 |
| 数据导入导出 | 按模板导入历史工单，字段映射正确；导出全量工单数据且字段完整 | 导入结果、导出文件样例 |
| 报表指标与口径 | 工单量、响应时长、解决时长、满意度四项指标可出报表，口径说明与实际计算一致 | 报表截图、口径说明文档 |
报表检查要核对口径：响应时长从提交算起还是从指派算起、解决时长是否扣除等待时间，这些定义要在通过标准中写明，并与企业现有统计方式对齐。数据导出是防止锁定的底线检查，验收阶段必须实际导出一次全量数据。
部署、安全与成本检查项
部署方式、安全要求和计费口径往往在上线后才暴露约束，因此要在合同签署前核查清楚。
| 检查项 | 通过标准示例 | 证据 |
|---|---|---|
| 部署方式 | 确认 SaaS 或私有化部署，网络访问方式与数据存放地点符合企业要求 | 部署说明、网络方案确认单 |
| 账号安全 | 支持密码策略、多因素认证，离职账号可及时停用 | 安全配置截图、账号停用测试 |
| 审计日志 | 登录、权限变更、数据导出等操作有日志，可按人和时间查询 | 日志查询截图 |
| 数据备份与恢复 | 备份频率与保留周期明确，完成一次恢复演练或取得书面说明 | 备份策略文档、恢复演练记录 |
| 计费口径 | 明确按坐席、按工单量还是按模块计费，试用期与超量规则写入报价单 | 报价单、合同条款 |
| 隐藏成本项 | 列出实施、培训、接口开发、存储扩容等可能额外收费的项目 | 报价明细、售前书面确认 |
安全与合规结论以书面材料为准，口头说明记录为待确认项。成本检查要把三年期的总拥有成本拆开：订阅费、实施费、接口与定制费、运维人力，逐项填入报价核对表。
证据与负责人怎么填
每项检查都要指定证据形式和责任人，否则清单会退化成意见汇总。填写规则如下：
- 证据类型：配置截图、演示录屏、测试用例结果、接口调用日志、合同或报价文件。功能类检查优先用试用环境中的实际操作记录，商务类检查用书面文件。
- 负责人分工：证据提供人负责在约定时间内提交材料，判定人负责对照通过标准给出结论，两者可以是同一角色，但要在表中分别署名。
- 留存位置：所有证据统一存放在评估项目的共享空间，按“阶段—检查项编号”命名，便于复核时定位。
- 复核时点：初筛证据在入围会上复核，试用证据在试用结束评审会上复核，验收证据在上线决策会上复核；复核后证据状态标记为“已确认”或“需补充”。
评估过程本身也需要承载：检查项、证据链接、判定结论和复核记录可以放在同一个协作空间里，与工单试用数据相互引用。例如使用 ONES Desk 试用时，试用中产生的工单可直接作为流转能力的证据，工单可关联到 ONES Project 的工作项跟踪整改，评审结论沉淀到 ONES Wiki 页面，供下一轮评估复用。这样清单、证据和结论在同一处可查，复核时不必再向各角色逐个收集材料。
阻断项与完成条件
阻断项是必须满足才能进入下一阶段的检查项，与普通检查项分开管理。典型阻断项包括：
- 核心流转无法配置：工单类型、状态流转或指派规则在试用环境中无法按范围说明实现。
- 权限不满足：无法做到按角色隔离数据，或敏感字段无法限制可见范围。
- 数据无法导出：全量工单数据不能完整导出，存在锁定风险。
- 安全要求不达标：部署方式、数据存放地点或审计能力不符合企业硬性要求。
阻断项未通过时，处理方式有三种：要求供应商限期整改后复测；调整范围说明，确认该需求可以放弃并记录原因；放弃该产品。整改和复测要记录责任人和复测日期，复测仍不通过则按放弃处理。
整体完成条件分两层：所有阻断项通过，是进入下一阶段的必要条件；非阻断项允许存在差异，但每项差异要写明影响、接受人和接受日期，由决策人确认后归档。评估结束时输出一份结论页，包含通过项数量、差异项清单、阻断项状态和最终结论（入围、可采购、可上线或放弃），作为本轮评估的正式交付物。
常见问题
评估清单里的检查项和通过标准，怎么区分才不至于写成同一句话？
检查项回答“查什么”，通过标准回答“看到什么算通过”。例如检查项写“转派与跨团队协作”，通过标准写“完成一次跨团队转派，转派原因、经手人和时间在工单上留痕”，证据是工单详情截图。通过标准要落到具体动作和可观察结果，避免出现“支持转派”“流程灵活”这类无法判定的表述。
如果一项检查在试用环境中无法复现，可以降级为初筛参考项，在验收阶段改用书面材料或演示录屏作为证据，并在清单中注明证据标准随阶段变化。
试用阶段时间有限，哪些检查项必须实际动手做？
建议优先做实操验证的是四类：核心流转（创建、指派、转派、状态流转）、权限隔离（含一次越权访问测试）、数据导出（全量导出一次）、通知触达（记录实际收到的通知样本）。这四类直接决定系统能否在真实组织中运转，仅看配置页面或产品介绍不足以判定。
报表口径、审批节点、知识库关联等检查项，可以在试用中做一次抽样验证，其余细节留到验收阶段按实际配置核对。初筛阶段则以范围确认和部署方式、成本口径为主，不要求提供试用环境证据。
评估过程中需求发生变化，清单要不要跟着改？
建议把变化分成两类处理。范围说明内的细节补充，可以直接更新对应检查项的通过标准，并记录修改人和日期；超出范围说明的新诉求，记录为待定项，不临时加入本轮评估，避免不同产品被放在不同标准下比较。
如果新诉求属于硬性要求，应先更新范围说明并重新确认，再评估是否影响已完成的检查结论。这样处理可以保证各候选产品面对同一套判定基准，评估结论也便于复核。
阻断项复测仍不通过，评估该怎么收尾？
复测仍不通过时，按放弃该产品处理，并在结论页写明未通过的阻断项、复测日期和判定人。如果企业确认该需求可以放弃，则调整范围说明、记录放弃原因和接受人，再继续推进；这一处理方式要在评估开始时就约定，避免临近决策时临时放宽标准。
无论哪种结果，结论页都要保留通过项数量、差异项清单和阻断项状态，作为本轮评估的正式交付物，供下一轮选型或上线决策引用。
清单、证据和评审结论分散在不同人手里，怎么保证可追溯？
做法是把检查项、证据链接、判定结论和复核记录放在同一个协作空间，按“阶段—检查项编号”命名证据，并指定证据提供人和判定人分别署名。复核时直接对照清单定位材料，不必向各角色逐个收集。
以 ONES 为例，试用中产生的工单可作为流转能力的证据，工单可关联到 ONES Project 的工作项跟踪整改，评审结论沉淀到 ONES Wiki 页面供下一轮复用。这样清单与证据相互引用，复核记录也能保留在原文旁边。
