简介：《ManageEngine ServiceDesk用户手册》面向企业IT管理员、服务台负责人及刚接触ITSM的运维人员，围绕安装配置、后台管理、服务请求处理、资产管理与报表分析等场景，帮助读者建立从部署到流程落地的认知。压缩包约25.97MB，文件总数与类型明细暂未提供，结合标题和描述可知内容以管理员手册、使用指南类文档为主，便于按安装、系统设置、服务台管理、IT流程定制和最佳实践等模块查阅。已有816人学习，对实际运维具有参考价值；读者可重点了解角色权限、SLA、自助服务门户、事件与问题管理、CMDB、自动化规则及报表分析等要点。文中的最佳实践还涉及定期备份、系统更新、终端用户培训和流程优化，可作为企业梳理ITSM落地路径时的辅助材料，适合中初级管理员按模块查阅并对照日常运维工作。
1. 手册写成功能清单那天，工单就开始在群里飞
一套 ServiceDesk 用户手册真正的检验时刻，不是评审会，而是上线第三周：新来的同事想请假外出的门禁权限，是先找行政还是先开工单？坐席收到一条“系统打不开”的请求，该把它记成故障还是服务请求？值班主管凌晨被电话叫醒，因为一条早已处理完的工单还在 SLA 倒计时里红着。这些都不是系统功能缺失，而是手册没把“谁在什么情况下做什么”写死。我见过一个两百人规模的团队，系统部署完两个月，工单量不到真实请求的十分之一，绝大部分事情照旧在即时通讯群里喊一嗓子解决；翻回去看他们那份手册，前半部分是模块截图，后半部分是按钮说明，唯独找不到“我遇到这件事该走哪条路”。这篇笔记讲的就是怎么把一份 ServiceDesk 用户手册从说明书改造成能落地的操作规程：先定工单的流转语言，再按读者拆章，然后把 SLA 和优先级写成能判定的规则，最后留一页真正解决问题的排查清单。
2. 先定工单状态机：ServiceDesk 手册的骨架从这里长出来
2.1 手册第一章为什么不该是登录和界面导览
绝大多数服务台手册的开篇是“系统登录”和“首页功能概览”，因为写手册的人打开系统，第一眼看到的就是这些。但读者打开手册的目的是解决一件具体的事，登录只占他三十秒，界面导览他点两下就懂了。真正让他卡住的是：我提交之后会发生什么、多久有人管、我能不能催、什么情况下会被打回来。
所以手册的第一张核心图表应该是状态流转表，而不是首页截图。它把系统里那套看不见的规则摊开在纸面上：新建、待分派、处理中、待用户确认、挂起、已解决、已关闭，每个状态由谁推动、停留多久合理、能不能回退。这张表一旦定下来，后面所有章节都有了引用锚点——自助门户章节讲“你的工单现在在哪个状态”，坐席章节讲“你接手后要把它推到哪个状态”，审批章节讲“审批只发生在哪个状态之间”。
我一般会要求团队在写任何一句正文之前，先在白板上把状态画出来，然后逐条追问：这个状态存在的必要性是什么？如果删掉它，会出现什么信息丢失？很多团队有七八个状态，其中三个是历史遗留，坐席自己也说不清“待处理”和“待分派”的区别，这种状态留在系统里，手册就永远写不明白。
2.2 状态、责任人、退出条件：一张必须能对照现场的表
状态机落地成手册内容，最实用的形式是三列表：状态、谁负责推进、满足什么条件才能离开。别小看第三列，它是排错时最常被翻的地方。下面这张表是我在一个约三百人规模的团队里用过的版本，可以按自己的流程裁剪，但列的语义别改。
| 状态 | 推进责任人 | 退出条件 | 常见误用 |
|---|---|---|---|
| 新建 | 提交人 | 提交人确认信息完整并提交 | 把草稿当工单挂着 |
| 待分派 | 服务台坐席 | 已指定处理组，且组内有人认领 | 直接丢给“IT 组”无具体人 |
| 处理中 | 处理人 | 已给出处理结论或需要用户补充信息 | 处理人休假工单不动 |
| 待用户确认 | 提交人 | 提交人确认解决，或超时自动确认 | 用户长期不看导致积压 |
| 挂起 | 处理人 | 等待外部条件（备件、第三方、变更窗口） | 用挂起掩盖拖延 |
| 已解决 | 处理人 | 结论写入工单，附处理说明 | 只写“已处理”三个字 |
| 已关闭 | 系统或坐席 | 关闭后进入回访与知识沉淀 | 关闭条件不明确 |
表里“待用户确认”这一行，是很多团队争论最久的地方。有人主张去掉，理由是用户不回就没法推进；有人主张保留，理由是坐席单方面关单会让问题反弹。我的做法是保留状态但设自动确认时限，默认三个工作日，时限到了由系统关闭并在工单里留一条自动记录。这条规则必须写进手册正文，而且要写清“自动确认不等于问题已解决，反弹请在原工单上重开”。
关于重开规则，手册里也要有一个明确说法：关闭后多少个自然日内允许在原工单上重开，超过之后必须新建并引用原工单编号。没有这条规则，统计报表里的重复工单会多到没法看，运维主管每次周会都要花半小时解释数字为什么对不上。
2.3 用一份配置把状态机固化，别让它只活在文档里
手册和系统脱节是常态，解决办法是让状态机同时存在于两个地方：手册里的表格，和系统里的一份可核对配置文件。下面这段 YAML 是我常用的描述方式，字段不多，但足够让实施的人和写手册的人对着同一份东西说话。
# ticket_state_machine.yaml —— 工单状态机描述（用于手册核对与实施配置） states: - key: new # 新建 owner: requester exit: "requester_submit" max_dwell_hours: 24 # 草稿超期提醒 - key: triage # 待分派 owner: service_desk exit: "assigned_to_group" escalate_after_hours: 2 # 未分派超时升级 - key: in_progress # 处理中 owner: assignee exit: "conclusion_written" max_dwell_hours: 72 - key: pending_user # 待用户确认 owner: requester exit: "user_confirm_or_timeout" auto_confirm_days: 3 - key: on_hold # 挂起 owner: assignee exit: "external_dependency_resolved" require_reason: true # 挂起必须填原因，否则无法保存 - key: resolved # 已解决 owner: assignee exit: "closure" - key: closed # 已关闭 owner: system reopen_window_days: 5 transitions: - from: pending_user to: in_progress trigger: user_reject # 用户点“未解决”回到处理中 - from: closed to: in_progress trigger: reopen_within_window字段里有两个值得单独解释。require_reason: true的意思是挂起必须填写原因，这条规则看起来是系统限制，实际上对手册写作帮助极大——因为一旦系统强制填写，你就可以在手册里直接说“挂起时请写清等的是什么、预计什么时候有结果”，读者照着填就行，不用理解背后的管理意图。auto_confirm_days: 3是可以按团队节奏调整的参数，改它之前先想清楚：改短了坐席省事但反弹率高，改长了工单积压、报表失真，我一般从五个工作日起步，跑两个月看反弹工单占比再往回收。
还有一点容易被忽略：状态机描述文件应该和手册放在同一个版本库里，改配置和改手册走同一次评审。我吃过亏，配置里把挂起改成“必须填原因”，手册过了三个版本才补上这句话，中间那段时间坐席天天在群里问为什么保存不了。
3. 按角色拆章：自助门户、坐席、审批人读到的内容不该是同一份
3.1 三类读者的诉求差异到底在哪
同一份 ServiceDesk 用户手册发给所有人，是最常见也最省事的做法，代价是三类读者都觉得不好用。提交人只关心“怎么提、多久有回音、怎么看进度”，坐席关心“字段怎么填、模板怎么套、什么情况下升级”，审批人关心“这条请求合规吗、我批了要承担什么”。这三种诉求几乎没有交集，硬塞进一本书里，结果就是提交人被字段说明劝退，审批人被状态机图绕晕。
按角色拆章不是简单地在目录里加三个分组，而是要承认一个事实：手册的默认读者是提交人，不是运维。很多服务台手册通篇站在管理视角写，动不动就讲流程规范，普通员工看完的第一反应是“这么麻烦，不如直接找人”。所以我会把提交人相关的章节放最前，语言尽量短、动作导向，坐席和审批人的章节放后面，允许出现字段名和配置项。
这里有个小技巧值得说：坐席章节的写法是“照着做一遍”，提交人章节的写法是“看不懂就不用往下看”。前者可以长，后者必须短。同一个“工单分类”概念，在提交人章节里写成“选一个最接近的类别，拿不准就选‘其他’并说明”，在坐席章节里才展开完整的分类树和重分类规则。
3.2 自助门户章节：把“提交一张工单”拆成五个动作
提交人章节最容易写成一段流水账，正确的做法是把它拆成可以单独跳转的五个动作，每个动作配一张真实截图或一段界面文字说明，读者卡在哪一步就翻到哪一段。
第一步是判断要不要提工单。这一步很多人觉得多余，其实最省时间。手册里给一张简表：密码重置、软件安装、权限申请、设备报修走工单；紧急中断类问题走值班电话并在事后补单；咨询类问题先查知识库。三条线一划，能挡掉相当一部分不合规的“随手一扔”。
第二步是选对入口。自助门户里的服务项按业务域分组，手册要给出的是“我要做某件事，应该点哪个组”，而不是把所有服务项列一遍。常见的做法是给出一张“场景—入口”对照表，二十条以内，覆盖八成真实请求。超过二十条就不要往手册里塞了，改成门户里的搜索提示。
第三步是填字段。这是提交人最容易放弃的地方。手册里的原则应该是“必填项不超过五个，其余靠模板带出”。如果系统里已经这么配置了，手册只需要解释那五个字段怎么填；如果没有这么配置，先改配置再写手册，别指望用户忍受十几个必填项。
第四步是提交后的确认。要写清提交成功会看到什么、会不会收到通知、通知里有什么信息。这一步的意义是给用户一个“事情已经在轨道上了”的确定感，减少他转身去群里再问一遍。
第五步是看进度和补充信息。手册要明确告诉用户：工单详情页可以看到当前状态和处理人，如果坐席在工单里提问，回复在哪里输入。很多团队的工单反弹率高，原因就是用户不知道能在工单里回复，只能另起一张新单。
3.3 坐席章节：字段、模板和一次完整处理演示
坐席章节的核心不是把所有功能讲一遍，而是给出一次从头到尾的完整处理演示，中间穿插字段说明。演示要覆盖三条典型路径：一条顺利关闭的常规请求、一条需要退回补充信息的请求、一条需要升级到二线的故障。三条路径跑完，坐席基本就能上手。
字段说明部分，我一般按“什么时候必须填”来组织，而不是按界面顺序。比如“影响范围”这个字段，只有在故障类工单里必填，服务请求类可以留空；那它就不该出现在服务请求的处理说明里。按界面顺序写字段说明，是手册臃肿的主要原因之一。
模板部分要给具体的填写范例，至少正例和反例各一条。反例比正例有用，因为它能让人瞬间理解边界。“已处理”是反例，“已重置账号密码并通过电话告知用户，用户当场登录验证通过”是正例。手册里把这对例子放进去，比写十行“请详细描述处理过程”管用。
升级路径要写清楚触发条件：什么情况下坐席可以自己处理完，什么情况下必须转二线，转的时候要带哪些信息。这条规则如果不写死，结果是坐席要么什么都往二线扔，要么硬扛着自己修，两头都不对。
3.4 审批人章节：只写决策需要的最小信息
审批人通常是兼职的部门负责人，他不会认真读手册，所以这一章要短到能在两分钟内看完。内容只有三块：我要批的是什么、我看到的信息够不够判断、我批错了会怎样。
第一块要把审批节点在流程里的位置说清楚，配一张只有三四个方框的极简流程图，别用完整状态机图。第二块给出“审批时可以要求补充的信息清单”，比如金额、资源归属、使用期限。第三块写清审批留痕和追溯方式，让审批人知道自己的操作是被记录的，这既是约束也是保护。
审批超时怎么办，也要有一句话。常见做法是超时自动提醒一次，再超时升级到上级，规则写进手册，避免每次靠人喊。
4. SLA、优先级与分类：手册里最容易被写成形容词的部分
4.1 用影响度乘紧急度，把优先级从形容词变成判定表
“高优先级工单需在两小时内响应”——这句话在手册里出现了一百次，但它没法执行，因为没人知道什么算高优先级。凡是靠形容词定义的规则，最后都会退化成“谁嗓门大谁优先”。
解决办法是把优先级拆成两个可观测的维度：影响度指受影响的用户范围或业务关键程度，紧急度指问题是否阻断工作以及有没有临时绕行方案。两个维度各三档，交叉出一张 3×3 的判定表，每个格子对应一个优先级。这张表必须写进手册，而且要举例子，每个格子至少一个真实场景，否则读者对“影响度二档”这种说法没有感觉。
| 影响度 \ 紧急度 | 完全阻断且无绕行 | 有绕行但效率受损 | 不影响当前工作 |
|---|---|---|---|
| 多人或关键业务 | 最高 | 高 | 中 |
| 小团队 | 高 | 中 | 低 |
| 单人 | 中 | 低 | 低 |
表定下来之后，还要写一条“谁有权改优先级”。我的做法是只允许服务台主管改，并且改的时候必须填理由。没有这条限制，优先级会被慢慢抬高，三个月后所有工单都变成了高。
4.2 SLA 计时规则里最该写清的是“什么时候停表”
SLA 出问题，八成不是响应慢，而是计时口径不一致。手册里必须明确三件事：从哪个状态开始计时、在哪些状态下停表、时钟按什么日历走。
开始计时的点，我一般定在“提交人确认提交”而不是“坐席接单”，理由是用户感知的等待从提交那一刻就开始了。停表状态通常是待用户确认和挂起这两个，因为它们都在等外部条件，让处理人背时间不公平。日历口径要写清楚是全天候还是工作时间，跨夜和跨周末怎么算，这一条如果含糊，月底报表一定吵架。
手册里给一段判定逻辑的伪代码或者真代码，比纯文字描述可靠得多。下面这段 Python 只是用来验证规则，不是生产代码，放在手册附录里让读者能自己跑一遍，理解计时口径。
# sla_check.py —— 用手册里的规则反推一张工单的剩余时间（示例） from datetime import datetime, timedelta WORK_START, WORK_END = 9, 18 # 工作时间窗口，按团队实际改 PAUSE_STATES = {"pending_user", "on_hold"} # 停表状态 def working_minutes(start: datetime, end: datetime) -> int: """只统计工作时段内的分钟数，跨夜与周末不计入""" total, cur = 0, start while cur < end: if cur.weekday() < 5 and WORK_START <= cur.hour < WORK_END: total += 1 cur += timedelta(minutes=1) return total def remaining_minutes(ticket: dict, now: datetime) -> int: """ticket 需包含 state、created_at、paused_minutes、sla_minutes""" if ticket["state"] in PAUSE_STATES: return ticket["sla_minutes"] - ticket["paused_minutes"] used = working_minutes(ticket["created_at"], now) - ticket["paused_minutes"] return max(ticket["sla_minutes"] - used, 0)代码里的paused_minutes需要系统在状态切换时累计，这一点要在手册里对应写到“每次进入停表状态，系统自动累计停表时长，报表里的实际处理时长已扣除这部分”。如果系统没有这个能力，就只能靠人工记录，那手册里得给出记录模板，别假装它自动发生了。
WORK_START和WORK_END这两个参数改之前，先和服务对象确认。有的团队对外承诺是全天候响应，但内部按八小时工作制排班，这个落差迟早会在一次夜间故障里暴露出来。
4.3 分类树不是越细越好，够用且稳定才是目标
分类字段的用途只有两个：路由到正确的处理组，以及支撑统计。超过三层的分类树，提交人填不对，坐席要花时间重分类，统计口径还会因为重分类而失真。
我的经验是两层足够：第一层按业务域分，六到八个；第二层按具体服务项分，每个域下不超过十个。再细的信息放在标题和描述里，靠搜索解决。手册里要写的是“拿不准时选哪个”，而不是把所有分类列一遍。通常留一个“其他”兜底，并规定这个兜底项每月复核一次，把高频的“其他”提升为正式分类。
分类变更要有个规矩：新增分类容易，删除和合并难，因为历史工单还挂着老分类。手册里加一句“分类调整需同步更新报表口径”，能省掉后面不少解释工作。
5. 排查章节：手册里最该有、也最常被砍掉的那一页
5.1 工单提交后没有任何回音，状态一直停在新建
现象：用户说提交成功了，页面也跳转了，但既没收到通知，工单列表里也找不到，坐席那边更是什么都没看到。
原因通常有三个。一是提交动作只完成了页面跳转，后端因为某个必填字段校验失败而丢弃了请求，前端没做错误提示，这在自定义表单里很常见。二是通知规则配置成了“仅当分派给具体人时发送”，而工单还停留在待分派，所以谁都没收到。三是用户提交的是草稿，草稿状态不在默认列表视图里，看起来就像没提交。
解决：手册里加一条“提交成功判据”——能看到工单编号且状态为新建或待分派，同时给出“在我的请求里按状态筛选草稿”的操作路径。运维侧则要检查表单校验的错误提示是否可见，以及通知规则是否覆盖待分派状态。这两件事都属于配置问题，但用户侧的手册必须先教会他自检，否则每次都要人工查。
5.2 SLA 倒计时和实际时间对不上
现象：工单明明挂起了两天，SLA 剩余时间却没变；或者反过来，工单处理完了，倒计时还在跑。
原因：停表规则只配在了部分状态上，或者状态切换时的累计逻辑有遗漏。最常见的是挂起状态配了停表，但“待用户确认”没配，坐席以为在等用户不算时间，系统却在照常扣。另一种情况是工单被重开，计时器重新从零开始，而不是接着原来的剩余时间走。
解决：把停表状态清单写进手册，和系统配置逐条对照，做成一张核对表。重开规则单独说明，明确“重开后续用原计时，不重置”。每次调整 SLA 参数后，拿一张测试工单完整跑一遍状态流转，看报表数字是否符合预期，这一步别省。
5.3 知识库里明明有文章，用户就是搜不到
现象：坐席确认某篇解决方案已经在知识库发布，用户在自助门户搜索关键词却一无所获。
原因：文章标题和正文用的是内部术语，用户搜的是自己的说法；或者文章状态是“已发布但未对外”，只在坐席端可见；再或者搜索只匹配标题不匹配正文，而关键词只出现在正文里。
解决：手册里给坐席一条硬性要求——每篇对外文章至少写两个“用户会用的说法”作为同义词放进标签。同时把文章可见范围作为一个必填项，发布前确认。定期抽查搜索日志里无结果的高频词，反过来补文章，这个动作每月做一次，比一次性写一百篇更有用。
5.4 审批流卡在中间，谁都不知道在等谁
现象：工单状态显示处理中，但处理人说自己提交审批了，审批人说自己没收到。
原因：审批节点绑定的是角色而不是具体人，角色下有多人但没配“任一人审批即可”还是“全部通过”，系统按默认规则等待所有人；或者审批人离职、岗位调整后角色没更新，通知发到了无效账号。
解决：手册的审批章节要写清审批节点的通过规则，并在工单详情里明确展示当前等待的审批人和已审批记录。角色成员变更要有交接动作，交接清单里包含“检查待审批事项”。这一条看起来是管理动作，但缺了它，流程卡住时谁都拿不出依据。
5.5 手册写的和系统里看到的不是一回事
现象：用户照着手册操作，发现按钮位置变了，或者某个字段根本不存在。
原因：系统配置变更没有触发手册更新，两者各自演进。这在快速迭代的团队里几乎是必然的，唯一的解法是把手册纳入变更流程。
解决：给手册加版本号和“最后核对日期”，每季度做一次全量核对，只核对手册里出现的截图和字段名。变更管理里加一条：影响用户操作的配置变更，必须同步提交手册修改，否则变更不算完成。我一开始也觉得这条太重，直到有一次改了两个字段名没同步，一周内收到二十多条咨询，才老老实实把它写进流程。
6. 让手册活过三个月：目录结构、版本与验收
手册能不能活下来，取决于它好不好找、好不好改。目录结构上，我习惯按角色分三个顶层目录，再按任务拆文件，一个文件对应一个完整任务，文件名用“动词+对象”的格式，比如“提交一张权限申请工单”“处理一条超时未分派工单”。这样做的直接好处是搜索友好，用户搜“权限”和搜“提交”都能命中同一个文件。
# 手册仓库的目录约定，文件名即检索入口 servicedesk-manual/ ├── 01-requester/ # 提交人视角，语言最轻 │ ├── 提交一张权限申请工单.md │ ├── 查看工单进度并补充信息.md │ └── 判断该不该提工单.md ├── 02-agent/ # 坐席视角，允许字段名 │ ├── 处理一条超时未分派工单.md │ ├── 挂起工单时必须写清的三件事.md │ └── 升级到二线要带的信息.md ├── 03-approver/ # 审批人视角，两分钟读完 │ └── 审批时需要核对的信息.md ├── 99-appendix/ │ ├── ticket_state_machine.yaml │ └── 版本与核对记录.md └── CHANGELOG.md # 每次配置变更对应一条记录配套的验收清单我一般压到五条，多了没人执行：
| 验收项 | 通过标准 |
|---|---|
| 任务覆盖 | 最近一个月真实工单里出现频次前二十的场景，手册都有对应文件 |
| 首屏可判 | 每个文件开头三句话内能判断“这件事是不是我要做的” |
| 字段一致 | 手册里出现的字段名与系统当前配置逐字一致 |
| 路径可走 | 随机抽三个任务，按手册独立操作能完成 |
| 版本可追 | CHANGELOG 最近一条与系统最近一次变更对得上 |
最后说一个我自己的习惯。我写这类手册时，会在每个文件末尾留一行“最近一次照着手册操作的人和时间”，让真正用过的人签个名。这个动作听起来有点笨，但它比任何评审都有效——签名的人会认真试一遍，试不通就会当场提出来。我靠这一行抓到过好几个自认为写得很清楚、实际第一步就卡住的段落。手册不是写给自己看的文档，是给别人照着做的工作底稿，能被人照着走通一遍，才算写完。希望帮到你。
本文还有配套的精品资源，点击获取
