来，大家一起来讨论些具体案例，增加对概念的理解。

       某单位提供公众服务。内部IT部门为内部的所有IT业务提供设计、开发、运维等、数据分析处理、项目管理等各项工作。
其中有个专门的支持部门，负责受理技术团队内外（含非公司员工外部用户)的报障；
在运维团队，也有安排一名监控人员，负责受理报障。运维监控负责查看所有系统流量图以及各类监控系统的告警信息；
按规定，有故障了，如果可明确是运维方面的问题，可以直接找监控报障。如果不确定只知道服务受影响了，可向支持部门报障。监控负责记录运维故障信息。
在实际过程中，大家发现，用户方（都是同事）都往往会直接找到具体的工程师来报障。而忽略监控。而监控也觉得自己忙于看流量图和系统告警信息，难以跟进及记录详细的故障信息。

监控目前是7*16 二班的形式。一共编制3个人。

综合考虑全局情况，讨论几点：
一、在人员编制不增加的必要前提下
1）监控是否适合继续承担服务台故障记录、受理故障之责；
2）服务台该如何设计、人员如何分工更适合？？（可综合考虑支持部门、运维部门，可以考虑部门人员调动）

二、在人员编制可增加的情况下
服务台的设计应该如何规划？对于用户来说需要最高效的方式。找运维监控或工程师最快捷。找支持部门的人员，就慢了很多。特别故障都是要尽快解决的

谢谢大家的回帖支持，讨论的话题做了内容进一步的完善。

确实是一个实际的问题，其实从某种角度上来说，监控本身也是一种意义上服务台。理解这点的话，可能就只要从工作量的角度去协调就ok了

一、在人员编制不增加的必要前提下
1）监控是否适合继续承担服务台故障记录、受理故障之责；
2）服务台该如何设计、人员如何分工更适合？？（可综合考虑支持部门、运维部门，可以考虑部门人员调动）

由于贵公司已有支持部门接收内外用户的报障，并可保证故障详细记录，而且监控团队压力较大，建议尽量引导用户通过支持部门报障，当然需要很长的过渡期。
如果在人员编制不增加，并且各部门工作量比较饱和的情况下，可考虑将支持部门作为服务台，培训支持部门报障接收人以及准备流程和指引手册，可将故障直接指派到处理人，从而减轻监控团队压力。
另外可深入调查监控工作是否存在优化空间，可通过自动化程序或工具代替日常监控人工工作，降低监控人工工作量。
针对紧急故障，必须建立紧急故障评判标准（不是所有用户反馈的紧急故障都一定是紧急故障），并且提供相应绿色通道，避免因工作排期而延迟。


二、在人员编制可增加的情况下
服务台的设计应该如何规划？对于用户来说需要最高效的方式。
找运维监控或工程师最快捷。找支持部门的人员，就慢了很多。
特别故障都是要尽快解决的


其实直接找到运维监控以及具体工程师，只是用户感知比较快，实际不一定快。
直接联系工程师，中间缺乏服务台的监控与跟进，紧急的事情很容易被人为地延迟。
人员编制可增加，建议搭建独立的内部IT服务台，并考虑与监控团队融合，内部IT服务台在闲时可协助监控团队处理日常工作。

监控一班只有一个人，确实少挺多，可能报警策略有调整，就会有大量报警过去，对监控人员要求挺高，技术手段可以做一些沟通工具提醒的功能做优化。单从这方面看，人手的问题，监控是不适合做服务台故障记录和受理的。除非添加人员。
另外一方面若建立服务台，服务台的人数需根据具体业务规模来定。并保证同事保障有人接听记录，然后分派。但这么看，有可能会有监控上报故障，然后给到服务台，服务台又将任务给到监控处理（比如重启机器等简单的操作）。
增加人员，可将服务台合并到监控当中。

这个题目挺实际，不错，看看大家的高见。