信息技术服务台流程图（事件与服务请求）
服务台流程图：事件与服务请求共用一个受理队列，涵盖分类定级、优先级、一线修复、二线升级、请求交付与关闭确认。
运作方式
把泳道改成你们真实的角色
把用户、服务台、二线支持、资产与采购，以及问题管理，换成你们实际拥有的团队。规模较小的组织常常把资产与采购并入服务台泳道，而问题管理可能是一个指定的人，而不是一个团队。每个决策者一条泳道，而不是每个人一条，这样有人换岗时图还能继续用。
写下区分事件与服务请求的判定标准
“事件还是服务请求？”这个分岔，只有当工程师能在几秒钟内做出判断时才有用。把判定标准写在决策旁边：是本该正常工作的东西坏了，还是用户在要一件标准的、事先约定好的工作？把你们真实存在的临界情况列出来，例如一台变慢的笔记本电脑与一份换新机的申请，并写明每一种各走哪条路。
公布你们的优先级矩阵
把你们对影响度和紧急度的定义附在“按影响度和紧急度设定优先级”上，写明每个优先级在受影响用户数和业务后果上分别意味着什么。把这张矩阵放在用户看得到的地方，正是让优先级变成推导出来的结果、而不是逐单争论出来的关键。
确定一线的边界，以及一次升级必须携带什么
界定一线被允许、也有能力修复的范围，以及二线接手之前，一次升级必须包含哪些内容：已经尝试过的步骤、受影响的服务、证据，以及用户什么时候找得到。同时决定要不要加一道基于时间的兜底规则，把毫无进展的工单自动升级，并写明交接之后由谁负责这张工单。
决定哪些需要审批、哪些属于预先批准
把低成本、低风险的目录项标记为预先批准，让它们完全绕过“直属主管批准该请求？”，把这道关口留给支出、许可证，以及任何会改变一个人能访问什么的请求。如果请求的是系统权限，就移交给你们的访问申请流程，而不是在这里批准。
就关闭、重新打开和问题移交达成一致，并只发布一个版本
写明什么算用户确认、一张已解决的工单要等多久才自动关闭，以及“是否为重复或已知问题？”上触发问题记录的标准。然后带着每条泳道的人走一遍这张图，修正他们实际执行的步骤，并把它作为现行版本发布，附上已记录的批准，让所有人读的是同一个修订版。
常见问题
服务台流程和事件管理有什么区别？
服务台流程是服务台本身的运行流：任何渠道进来的每一次联系，都被路由到对应的处理方式上。事件管理是它里面的一条支线，只处理服务的非计划中断。ITIL 4 正是出于这个原因，把服务台、事件管理、服务请求管理和问题管理当作彼此独立的实践，尽管小团队通常由同一批人从同一个队列里把它们全部跑完。这张图是服务台层面的视角，展示这些支线如何共用一个受理入口和一个关闭动作，并把事件的深层细节——例如重大事件的宣布和 SLA 超时升级——交给事件管理流程。
事件和服务请求有什么区别？
事件是本该正常工作却没有工作的东西：登录失败、打印机离线、应用程序报错。服务请求是标准的、事先约定好的工作，不涉及任何故障：新软件、一个许可证、一台替换设备、给新员工开一个邮箱。这个区分之所以重要，是因为它几乎改变了下游的一切。事件按影响度和紧急度得到优先级，考核的是恢复；请求走审批和交付路径，考核的是交付。把两者混在一起，要么让例行请求挂在故障时钟上，要么让真正的故障排在笔记本电脑订单后面。
服务台工单什么时候应该升级到二线？
当这项工作超出了一线的技能、工具或权限边界时就升级，这属于职能升级。它与层级升级是两回事：层级升级是因为影响或延误已经从技术问题变成业务问题，才把管理者拉进来。很多服务台会加一道基于时间的兜底规则，让毫无进展的工单自动升级；这作为安全网很有用，但单独作为主要规则并不好。无论触发条件是什么，交接都必须带上已经尝试过的内容，否则二线会把第一个小时花在重复一线的工作上。
工单可以在用户确认修复之前关闭吗？
已解决和已关闭是两种不同的状态，这张图把它们分得很清楚。工程师在修复完成时把工单标记为已解决；只有当“用户是否确认已修复？”得到“是”，工单才关闭。如果用户说问题还在，工单会重新打开回到一线，而不是新开一张，这样历史记录和最初的时钟才留在一起。由于总有一些用户从不回复，多数服务台会设置几个工作日的自动关闭窗口，并先发一次提醒，同时把这个期限写进服务说明里，让关闭不至于让人措手不及。
涉及采买的服务请求如何纳入这个流程？
它们走交付分支：目录要求审批的先审批，然后是“物品是否有库存？”，要么从现有库存发放，要么在交付前开具采购订单。人们最常跳过的一步是更新资产记录，所以这里把它放在与交付同一个节点上。如果在发放的那一刻不更新资产台账，许可证数量和硬件更换计划在几个月内就会失真。对于金额较大或目录之外的采买，服务台提出需求，由更完整的采购订单流程接手，它有自己的寻源和发票核对环节。