IT工单系统选型，先要回答“检查什么”。建议围绕入口与受理、分派与流转、SLA与升级、权限与数据隔离、通知与协作、报表与审计、集成与扩展、部署与合规八类能力建立检查表，再结合团队规模、服务对象和现有系统逐项验证。能力清单用于缩小候选范围，最终判断仍需通过试用和场景演练确认。
要点总览（TL;DR）
- 选型检查表建议覆盖入口与受理、分派与流转、SLA与升级、权限与协作、报表与审计、集成与扩展、部署与合规七类能力，先按服务对象和工单类型划定范围。
- 入口检查重点验证邮件、聊天工具、API等各渠道提交后字段是否统一，以及重复工单能否识别合并。
- 流转与SLA必须用场景演练验证：自动分派与升级、挂起暂停计时、关闭后重开，配置预期与实际耗时对照记录。
- 权限检查用真实组织架构模拟跨组账号，确认无法通过搜索或报表绕过数据隔离。
- 能力清单只用于筛选，最终决策以3–5个高频与高风险场景的端到端演练、评分和书面证据为准。
先明确服务对象与工单边界
选型的第一步是划定评估范围。IT工单系统可以承载的范围很宽，从员工报修一台电脑，到客户提交服务请求，再到跨部门的权限开通和变更审批，都可能被纳入同一套系统。范围不同，对入口、权限、SLA和报表的要求差别很大。先写清前提，后面的能力检查才有统一口径。
建议用一份选型前提清单固定以下内容：
- 提单人范围：仅内部员工、仅外部客户，或两者兼有。外部客户提单通常涉及账号注册、服务目录展示和数据隔离，内部员工提单更关注组织架构同步和统一登录。
- 工单类型：故障报修、服务请求、变更申请、权限开通、咨询问答等。不同类型对应不同的表单字段、审批环节和时限目标，需要分别列出。
- 处理角色：一线服务台、二线专业组、外部供应商或研发团队。角色数量决定分派规则和权限模型的复杂度。
- 边界与暂不纳入项：与IT资产运维套件的分工，例如资产台账、巡检、补丁管理是否由其他系统承担；与研发工具的分工，例如缺陷和需求是否留在研发管理系统中，工单系统只做入口和转接。
把“完整IT资产运维套件的全面评估”和“旧系统替换与迁移方案”明确列为暂不纳入项，可以避免评估范围不断膨胀。前提清单确定后，后续每一类能力都按同一组服务对象和工单类型来核验。
入口与受理能力检查
入口决定员工或客户提单是否顺畅，受理字段决定工单进入系统后能否被正确分类和处理。检查时不要只看入口数量，要验证每个入口提交后是否生成结构一致的工单。
| 检查项 | 核验内容 | 验证方式 |
|---|---|---|
| 入口形式 | 门户、邮件、聊天工具、电话转单、API是否都能生成工单，各入口字段是否统一 | 分别从每个入口提交一条测试工单，比对字段完整性 |
| 自助服务 | 是否有服务目录、常见问题引导和知识库推荐，员工能否自助解决部分问题 | 以普通员工身份走一遍自助提单流程 |
| 表单与模板 | 必填字段、附件上传、分类模板、表单字段能否按工单类型自定义 | 为故障报修和权限开通各配置一套模板并试填 |
| 重复工单识别 | 同一问题重复提交时能否提示或合并，合并后历史记录是否保留 | 连续提交两条相似工单，观察系统提示与合并结果 |
邮件转单和聊天工具转单需要重点验证：邮件正文、附件和发件人信息是否完整带入工单，回复邮件是否回写到工单记录。API入口则要确认字段映射和鉴权方式，为后续与监控系统或门户对接做准备。
分派、流转与SLA能力检查
工单从受理到关闭的过程，是选型中最需要演练的部分。规则配置得再细，如果实际流转卡顿或SLA计时口径与业务不符，上线后仍会回到人工催办。检查时把分派、状态、时限和异常处理放在一起看。
分派与路由
- 是否支持按组别、技能、值班表或工单类型自动分派，同时保留手工改派。
- 自动分派规则能否设置优先级和兜底组，避免无人接收的工单滞留。
- 转派时是否保留原处理人记录，转派次数能否统计。
状态流转
- 状态机能否自定义，例如待受理、处理中、待用户确认、挂起、已解决、已关闭。
- 状态变更是否可绑定必填字段或审批动作，例如关闭前必须填写解决方案。
- 挂起、重开和关闭规则是否明确：挂起期间是否计时，重开次数是否受限，关闭后能否追加回复。
SLA与升级
- SLA计时口径：按自然时间还是工作时间，是否支持节假日日历，哪些状态暂停计时。
- 能否为响应、解决等环节设置多级目标，不同优先级使用不同时限。
- 临近超时是否有提醒，超时后是否按层级逐级升级到组长或负责人。
试用时至少演练三个场景：高优先级故障的自动分派与升级、用户补充信息导致的挂起与恢复、关闭后用户重开。每个场景记录实际耗时和通知对象，与配置预期对照。
权限、协作与通知能力检查
工单系统通常涉及员工、服务台、专业组和外部供应商多类角色。权限设计要同时满足两件事：处理人能看到足够的信息解决问题，无关人员看不到敏感内容。
- 角色与数据权限：能否按组、按工单类型、按提单人隔离数据。例如权限开通类工单只对特定组可见，外部客户只能看到自己的工单。
- 内部协作：是否支持内部备注与用户可见回复分离、@提醒、关注人和协作处理人。内部备注不能泄露给提单人，这一点要在试用中实际验证。
- 通知机制：通知渠道是否覆盖邮件、聊天工具和站内消息，能否按事件和角色控制通知频率，避免大量重复提醒。
- 敏感信息控制：附件和字段能否设置访问范围，导出操作是否受权限约束并留痕。
权限检查建议用真实组织架构做一次模拟：新建一个仅属于某专业组的处理人账号，确认其只能看到本组工单，且无法通过搜索或报表绕过限制。
报表、审计与集成扩展能力检查
工单系统上线后，管理者需要用它回答“服务做得怎么样”，审计人员需要回答“谁在什么时候改了什么”，运维团队需要把它接入现有工具链。这三类需求对应报表、审计和集成能力。
| 类别 | 检查项 | 关注点 |
|---|---|---|
| 统计口径 | 工单量、响应时长、解决时长、SLA达成率、重开率 | 口径是否可定义，暂停时间和工作时间如何计入 |
| 报表能力 | 自定义报表、筛选维度、导出格式、定时推送 | 能否按组、按工单类型、按时间段拆分 |
| 审计留痕 | 字段修改、状态变更、权限调整、导出操作是否记录操作人和时间 | 日志能否查询和导出，保留期限是否满足要求 |
| 集成方式 | API、Webhook、SSO、聊天工具、监控系统对接 | 接口文档是否完整，事件触发是否及时 |
| 扩展能力 | 自定义字段、自动化规则、二次开发支持 | 扩展是否影响升级兼容性 |
在流转、协作和报表环节，ONES可承载与工单相关的管理动作：将请求以工作项形式记录，按状态和负责人流转，配合自定义字段和报表查看处理进展。选型时可以把这类能力放进同一张检查表，用相同的场景脚本验证其配置方式和实际效果。
部署方式、合规与成本核验
功能满足只是入选条件之一，部署形态、数据要求和成本口径决定系统能否长期用下去。这一部分需要向厂商逐项确认，并把答复落到书面。
- 部署形态：SaaS、私有化或混合部署，各自对网络、运维人力和升级节奏的要求不同。服务对象包含外部客户时，还需确认对外访问方式。
- 数据存储与合规：数据存储位置、备份策略、数据导出和删除机制，是否满足所在组织的合规要求。具体认证和资质以厂商提供的有效证明为准。
- 计费口径：按账号数、处理人数量、并发还是存储计费，提单人是否计入收费账号，超出额度如何计费。
- 实施与运维投入：初始化配置、流程梳理、培训和数据迁移分别需要多少人力，后续版本升级是否额外收费。
- 版本与兼容性：当前版本的功能范围、与现有浏览器和办公工具的兼容情况，需向厂商查证并以书面答复为准。
成本核算建议把首年投入和持续投入分开列：首年包含实施和培训，持续投入包含账号、存储和运维。只比较订阅价格容易低估落地成本。
用场景演练完成选型验证
能力清单的作用是筛选，不能替代验证。把清单转化为演练脚本，才能看出配置是否符合业务习惯、处理人是否愿意使用。
演练场景选择
从高频和髙风险两个方向各选场景，总数控制在3–5个。例如：普通故障报修的全流程、高优先级故障的升级、权限开通的审批与留痕、外部客户提单与数据隔离、批量重复工单的合并处理。每个场景写明提交人、处理角色、预期状态变化和预期通知。
评分与证据记录
| 检查项 | 权重 | 通过标准 | 证据 |
|---|---|---|---|
| 自动分派与升级 | 高 | 高优先级工单在设定时限内分派到正确组别并触发升级 | 配置截图、通知记录 |
| SLA计时口径 | 高 | 挂起期间暂停计时，恢复后继续累计 | 工单时间线截图 |
| 数据隔离 | 必须满足 | 跨组处理人无法查看和搜索他组工单 | 账号测试记录 |
| 报表口径 | 中 | 响应时长和解决时长可按定义导出 | 导出报表样本 |
| 集成对接 | 中 | API或Webhook能完成一次真实事件推送 | 接口调用记录 |
评分表要区分必须满足项和加分项。必须满足项不通过即淘汰，加分项用于在合格候选中排序。所有结论附上截图、配置项或厂商书面答复，避免凭演示印象决策。演练结束后形成对比结论，并确定试点范围，例如先在一个专业组或一类工单上运行，再逐步扩大。
常见问题
工单类型很多，选型时要不要把所有类型都纳入首轮评估？
不必。首轮评估建议聚焦2–3类高频工单，例如故障报修和权限开通，用它们验证表单模板、分派规则和SLA配置是否够用。变更申请、跨部门审批等低频但流程复杂的类型，可以在候选缩小到两家以内时再补充演练。这样既控制评估工作量，也能看出系统在复杂流程上的配置上限。
SLA计时口径在试用中怎么验证才算充分？
至少覆盖三种情况：工作时间内正常计时、挂起期间暂停计时、跨节假日或非工作时段的时间扣除。每种情况提交一条测试工单，记录系统显示的时间线与人工计算是否一致。如果业务对响应和解决分别设目标，还要确认两级目标能否独立配置、分别触发提醒。
内部备注和用户可见回复的分离，为什么需要单独验证？
这是权限设计中最容易出问题的地方。演示环境里备注和回复通常分开展示，但实际使用中如果通知模板、邮件回写或导出功能把内部备注带出去，敏感信息就会泄露给提单人。验证方法是：用处理人账号写一条内部备注，再检查提单人端收到的邮件、站内通知和工单详情页，确认备注内容不出现在任何提单人可见的位置。
候选产品功能都满足检查表，怎么做出最终选择？
进入这一阶段后，比较重点从“有没有”转向“配置成本和使用意愿”。可以让每个候选按同一套演练脚本操作，记录完成配置所需的时间、是否需要厂商协助、处理人对界面的接受程度。同时核对部署与计费口径是否与预算匹配。功能都合格时，实施投入低、处理人愿意日常使用的方案更容易长期运行。
试点范围怎么定比较稳妥？
试点建议选一个专业组加一类工单，运行2–4周，观察分派准确率、SLA达成情况和处理人的实际反馈。试点期间保留原有提单渠道作为兜底，避免影响正常服务。试点结束后根据数据决定扩大范围还是调整配置，再进入全面推广。
