The Support Role Cluster includes service desk and incident and problem management functions. Support is key not only to internal users (employees) of the corporate IT services, but to external customers of an organization's products and services, commonly referred to as product or technical support.

The Service Desk service management function (SMF) is typically associated with the Support Role Cluster. The service desk function is responsible for first-line support to the user community for problems associated with the use of IT services. The service desk also attempts to identify a problem or rectify a known error through discrepancies or incidents reported by users. A service desk may be an organizational unit composed of multiple service groups-for example, a call center and one or more site-support teams.

For example, suppose that service desk personnel are working to restore service levels at a business-to-customer (B2C) e-commerce site. The customers are encountering problems and reporting them, and the incident management staff is trying to gather all the relevant information, but the automated tool they use (a data entry form) wasn't designed to accept information that is critical to the problem. For example, the form used to enter information might include hard-coded fields for items like the customer's computer make and model, but not the bandwidth of the line they use to connect to the Internet. This would prevent the correct information from reaching the problem management group, which would slow its response to problems and leave customers with the impression that the company is not committed to providing good service. The group can try to change the tool, if possible, or work around the problem by repurposing existing fields to store the newly needed data.

The context for this risk is that service desk personnel use tools to collect information from customers who log complaints regarding the company's business-to-consumer e-commerce Web site. The tools seem to collect the right information today, but what if future problems arise that would require additional information, which the tools weren't designed to collect?

The following table shows various examples of risk components pertinent to a scenario involving the Support Role Cluster.

Table: Support Role Cluster risk components

Risk component	Statement
Root cause:	Technology
Condition: The following event occurs ...	Customers using the B2C site encounter problems and report them, but the incident management tools do not collect all relevant data.
Operations consequence: ... operations will be hurt in this manner ...	Problem management doesn't receive the information they need to track down the underlying problems.
Downstream effect: ... and the business as a whole will be hurt in this manner ...	Customers perceive the slow response to problem reports as a sign the business doesn't take customer service seriously, and the customers switch to a competitor's B2C site.
Mitigation: Prior to the condition occurring, we will try to reduce the impact and/or probability by ...	Change the incident tracking tool if possible and, if not, attempt to store the additional required information in an unused field.
Trigger: If the condition is imminent (but has not yet occurred), we will know because this happens...	Problem management realizes that the information needed to solve a problem isn't being collected by incident management.
Contingency: If we are unable to prevent the condition, we will respond to the trigger in this way:	Change the incident tracking tool if possible and, if not, attempt to store the additional required information in an unused field.

Note that in this case, the mitigation and contingency are the same. In some cases, the difference between them is timing. The contingency plan executed for today's condition may serve as a mitigation in the future, reducing the impact or probability of the condition recurring.