业务系统访问
收集系统、申请角色、业务理由，以及必要时的到期日期。审核人批准访问，由获授权的管理员在实际系统中开通，再为申请人记录结果。申请应用中的状态变化不等于账号已开通。
写清您计划交付的服务
| 决策 | 政策示例 | 应避免的常见错误 |
|---|---|---|
| 预期结果 | 笔记本电脑与工位已配置完毕，可供员工使用 | 不要仅因采购订单获批，就将申请标为完成。 |
| 所需背景信息 | 业务需求、地点、日期和设备要求 | 收集会影响交付决定的事实，无需填写所有可能的资产字段。 |
| 授权 | 指定设备审核人 | 审核决定允许作出相应承诺，但不证明已完成实物交付。 |
| 交付任务 | 准备笔记本电脑；配送扩展坞 | 每项任务都需要负责人和完成详情。 |
| 验收 | 员工确认两项交付均已完成 | 任何任务未完成或受阻，都会阻止最终验收。 |
围绕决策环节构建流程
区分服务申请与意外问题
“岗位变动，需要配备笔记本电脑”是既定服务；“现有笔记本电脑无法充电”是支持问题。参与人员可能相同，但输入信息、决策和完成条件不同。
明确对结果负责的人
指定能够协调跨团队分歧的服务负责人。任务负责人完成各自工作，服务负责人仍对整项申请及承诺的结果负责。
仅在需要决策时要求授权
费用支出、访问权限或例外情况可能需要人工审核，日常低风险交付则未必。避免增加延误工作却没有实际管控作用的形式化审批。
让不完整的信息能够补正
审核人需要能够退回申请、说明缺失信息并接收更正版本。不要抹去原决定，也不要用无记录的字段修改替代拒绝后的处理。
定义何为交付完成
列出必需任务及各负责人应记录的完成凭据。员工应清楚自己在验收什么，不能用一个已完成部分掩盖尚未完成的依赖任务。
不同申请需要不同处理方式
会议室显示屏故障
这是意外问题，并非服务目录中的服务申购。记录房间和影响、指定处理人、记录诊断与等待，并确认显示屏恢复正常。可使用内部帮助台示例管理这一生命周期。
先推行一项完整服务
从一项服务和几个真实场景开始
测试日常申请、需要授权的申请、部分交付、退回补正和完整交付。请实际服务负责人确认，每种情况是否都进入正确的下一步。
先审查停滞工作，再添加仪表板
关注缺失信息、无人负责的任务、阻碍因素和验收延迟。创建能帮助人员解决这些问题的视图；只有数量并不能说明该做什么。
明确边界后再扩展
能清楚描述所需信息和交付方式时，再新增服务。保密申请、技术开通和专业事件响应，应继续在为其设计的系统和权限范围内处理。
服务申请流程规划常见问题
谁应负责服务申请管理？
指定了解承诺结果、能够协调跨团队交接的服务负责人。各项交付任务仍需各自的责任人；负责仪表板不等于负责服务。
应先设计政策，再选择软件吗？
至少先明确服务结果、所需信息、必要时的审批人、任务负责人和验收条件，再检查应用是否能让这些决策和例外得到实际处理。
申请信息不完整时应如何处理？
提出具体问题并退回，同时保留历史。明确由谁补正、何时可以继续，不要只为移出处理队列就将其标为拒绝。
小团队应从什么指标开始？
先明确要作什么判断：哪些申请没有负责人、哪些任务受阻、哪些交付等待确认？只有定义了起止时间、工作日历和等待政策后，才添加交付时长指标。
服务交付与帮助台示例是一个同步应用吗？
不是。它们是独立示例，分别处理既定服务交付和员工意外问题。若需要在两者间交接，应设计关联和负责关系，不要假定会自动同步。
选择适合团队的下一步
将一项书面服务政策落实为可执行流程
使用示例申请和交付任务测试您团队的交接，再扩展到更多服务。