B8 Communication with users and customers

This section appears last, not because it is the least important, but because it incorporates several of the areas discussed above. An important principle in communicating with customers is that communication should not focus on internal aspects of Service Operation. The focus is on the customer or users’ requirements and what IT is doing to meet them. This should not involve technical descriptions and detailed information about internal processes.

Purpose	There are a number of reasons for user and customer communication in Service Operation. These include: Ensuring that services have been delivered as agreed Communication around fulfilling Service Requests Reporting Incidents and keeping users and customers updated on their status until resolved Notifying users and customers of changes that may impact them Providing access to services Dealing with potential security issues Scheduling activities that involve users or customers, e.g. maintenance Notification of special business events that require additional support or changed priorities Review of customer and user satisfaction Coordination during contingency situations
Frequency	Communication with users and customers is ongoing. The format and content of communication will be defined by the processes that are being executed. For example, communication about an Incident will be determined by the Incident Management process. Some communication will be formal and scheduled, e.g. providing reports on the performance of a service during a review meeting. Other communication will be formal, but ad hoc, e.g. communication about the status of an Incident
Role Players	The identity of the role players and their number will depend on which process is being executed, the type of situation that has occurred and the scope of what is being communicated, e.g. providing an update about the status of a Service Request will have a very different audience than when participating in a Service Level Review meeting
Content	The content of this communication will vary depending on the context. However, it is important to gear the communication to the audience. This means using service names rather than server or application names, being professional, avoiding technical jargon, not being condescending and treating customers and users with respect
Context / sources	The context of this communication is the day-to-day executing of operational activities and the delivery and support of services. Service Operation teams should not be communicating with customers or users on planning issues, strategy, design or testing – unless they have been assigned to a project team which is dealing with one of these areas

Table B.11 Communication with users and customers

Appendix C: Kepner and Tregoe

Charles Kepner and Benjamin Tregoe developed a useful method to analyse problems. In this appendix, their method is presented as an example of a Problem Analysis method.

Kepner and Tregoe state that Problem Analysis should be a systematic process of problem solving and should take maximum advantage of knowledge and experience. They distinguish the following five phases for Problem Analysis (described further below):

• Defining the problem
• Describing the problem with regard to identity, location, time and size
• Establishing possible causes
• Testing the most probable cause
• Verifying the true cause.

Depending on time and available information, these phases can be realized to a greater or lesser extent. Even in situations where only a limited amount of information is available, or time pressure is high, it is worthwhile adopting a structured approach to Problem Analysis to improve the chances of success

Дата добавления: 2014-12-23