服务台是用户和服务提供商组织之间互动的枢纽。用户在需要时与服务台联系，他们的业务生产力取决于服务台提供有效和及时的援助。为了提供这种帮助，服务台工作人员经常依靠其他团队的网络为他们提供有用的信息，并跟进问题以推动整体服务质量--这是一个更广泛的问题解决过程的一部分。虽然大多数服务台工作人员对问题解决的工作方式有一定的了解，但以下是他们可能不知道的关于问题解决的5个事实，这可以帮助提高你的服务台绩效。
不是所有的问题都应该被解决
精通技术的人有一种想要解决事情的倾向；重要的是回应用户和企业的需求。作为一个指标，第一接触点解决（FCR）的兴起有时会推动这种行为，而用户想要的只是能够完成他们开始的重要任务，而这有时可以通过一个精心选择的变通方法更优雅、更快速地完成。
问题管理和风险管理有很多共同点，包括对投资回报（ROI）的强烈关注。作为问题解决过程的一部分，每一个被确认的问题都有一个对组织的预计影响，以及对该问题在未来发生的可能性和频率的一些估计。每个问题的调查都有一个成本，我们可以在此基础上加上实施解决方案的成本（投资）。许多问题需要的投资超过了潜在的回报；这些问题是不应该被解决的。
系统上线时有问题
当一个服务台为一个最近发布的系统或从另一个服务台过渡过来的系统提供支持时，我们可以假设该系统会带来一系列已经被人所知的现有问题。对于新的系统（或最近发布的系统），开发团队很可能有设计决策、工程假设、问题、风险和缺陷的清单，这些问题在发布前已经被发现但没有完全解决。如果系统是从另一个支持团队或服务台职能部门过渡到服务台的，FAQ、故障排除指南和问题管理记录提供了已知问题的清单。所有这些都代表了服务台可能遇到的潜在问题。作为向服务台转移知识的一部分，服务经理应该捕捉这些已知的问题，以便保留这些信息，而不是丢失。
自助式事件管理并不能使问题消失
有一种常见的做法是使用自助服务和自动支持功能，使用户能够解决请求和事件，而不产生服务台工作人员的人力资源成本。虽然这可能是一种有效的运营成本规避技术，并为服务台节省资金，但自助服务支持并不能使问题消失，也不能使你的ITSM功能为用户提供更好的服务。相反，自助服务事件解决鼓励服务台和服务所有者忽视潜在的服务问题，最终导致服务质量下降和组织整体成本增加。
服务台可能遗失或破坏了对解决问题至关重要的数据
信息可能是短暂的：有时存在于看到发生了什么的用户的记忆中；或者.log文件和其他监测数据只存在几个小时或几分钟，或者被重新启动删除。然而，重启、重新启动、重新加载和稍后再试是服务台工作人员给用户的一些最常见的事件解决指示。虽然这些技术在减轻事件的影响和快速恢复服务方面可能是有效的，但意想不到的影响往往是破坏了环境条件、上下文数据和系统日志信息，而这些信息是识别和解决根本问题的重要诊断工具。在做出任何这些破坏性的建议之前，服务台工作人员应该暂停一下，考虑是否有任何诊断信息可以和/或应该首先被捕获以帮助解决问题的过程。
同时，我们应该做出一些努力来捕捉那些以后很难或不可能得到的信息：用户第一次看到这个问题的确切时间，以及同样重要的，用户最后一次能够成功使用该功能的时间。
每一个打到服务台的电话都是一个人的问题
服务台电话都代表着对用户和业务流程的正常运作的影响，因此应该捕捉和解决的问题。无论呼叫是关于访问请求、关于如何做某事的指示、更改请求、报告错误或提醒支持人员注意系统中断--用户已经停止了他们的正常工作活动，与服务台接触。问题不仅仅与事件有关，它们存在于用户不得不停止他们正在做的事情并在恢复之前遵循一个单独的流程的任何时候。随着公司将每个渠道（电子邮件/聊天/社交媒体/电话）的信息汇集在一起，挖掘每个SD互动的改进机会已经在发生。
更为重要的是，中介互动（与用户有对话的互动）将由一流的方法来管理。这将意味着更快地实现应该自动化的东西的自动化。访问请求可以建立在业务入职流程中；用户界面更加直观，不需要说明；反馈和变更请求机制嵌入到系统中；以及更好的监测，当系统出现故障时，用户不需要报告。
许多组织的服务台是一种被低估的资源，用于路由和常规查询。他们在帮助捕捉有助于诊断和解决的数据方面的作用必须得到认可和丰富；甚至了解服务台如何通过每一个准确的数据来增加价值，也有助于推动绩效的提高。
如果您对服务台的问题解决培训感兴趣，Kepner-Tregoe可以提供帮助50多年来，KT的问题解决专家一直与像您一样的公司合作，通过培训、咨询和促进，提高员工解决问题的技能。