A reader recently asked me to comment on what a First Call Resolution (FCR) is according to ITIL and general best practice.   When collecting metrics you want to be sure that the reporting brings good business value. From a reporting perspective it might serve well to report incidents and requests separately.      Each organization will have to have policies for how the metrics are reported based on business value.  One option is to have a policy that will report on “Service Requests” separate from “Incidents”.  If we do not separate the logging and reporting for these very distinct processes the combined metrics and reporting might not be something that is meaningful or that could be acted upon correctly.  You could end up with a very high FCR rate but your Mean Time To Restore Service metric could be breaching the SLA.  Therefore, the question is not whether the call was resolved at first line, but rather was it a FCR for an Incident or Requ...

In a recent conversation I was asked about the difference between an Incident and a Problem. This is one of the most often confused points in all of IT Service Management and ITIL. Part of the confusion comes from the fact that both words are used (at least in the English language) to express similar ideas. Each reference some kind of issue occurring that potentially could lead to human action. However, in ITIL words are more clearly defined and have particular contexts for usage. Incident: Any unplanned event that causes, or may cause, a disruption or interruption to service delivery or quality Problem: The cause of one or more incidents, events, alerts or situations While Incidents have to do with disruption of delivery or quality, problems have to do with causes. From these distinct definitions we can see that not every incident would result in a problem, and not every problem even needs to be related to an incident. Keep in mind that “Incidents never grow up to be Problems.” Th...

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident status of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead? Thanks, René W. Answer: René. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” ...

The most frequent question of the last few months has been "What are IT organizations doing to reduce costs in a downturned economy?" With constrained human and financial resources, the answer to this question can be daunting. The business still expects the same level of service with fewer resources. What's an IT department to do? IT Service Management best practices have always provided guidance for managing or lowering the cost of services without sacrificing quality. Frameworks, such as ITIL, advocate processes that net higher efficiencies and effectiveness, which in turn result in lower costs and higher quality. The better you are at doing something, the lower the cost of doing it. Here are some other ways ITSM can help reduce costs: Understand your costs by calculating cost per service, cost per customer and cost per activity. You can't reduce costs if you do not understand what they are in the first place. Create and analyze a Service Portfolio of services in th...