PIRATED 20130912 0930

PIRATED 20130912 0930

NOTE: This content appears to have been plagiarized. Please leave a comment or email tnwiki at Microsoft (with a link to this article) if we are mistaken. The content was pulled from the following source:
The community rules state:
  • "Someone else has relevant content and you want to help them share it with the world. It's a nice thought, but do not copy other people's content to the Wiki, even if the owner said it was OK."



This article introduces three fundamental record types used for service management. These include: 

  • Cases are the fundamental record type in service management, and represent a single incident of service. Different organizations may refer to cases using different terms, including incident, ticket, service request and so forth.
  • The Knowledge Base is a repository of articles used to assist customer service representatives in the resolution of cases.
  • The Subject Tree is a hierarchical list of subjects used by many organizations to classify cases and other record types. 

Cases 

Service management is about creating, managing, and tracking cases. Cases can include customer service requests (a car needing repair) and customer complaints (someone complaining about a fallen tree in the neighborhood) to mini-projects (an internal request to the Information Technology Department to add a new report to an internal application). 

Subject Tree 

The Subject Tree is a hierarchical list of subjects an organization can use to classify service cases and other records in Microsoft Dynamics CRM. The Subject field is presented as a lookup field on the default case form, and is often used to classify cases. By default, it can also be used to classify product records and Knowledge Base articles. 

Here is an example of a subject tree for a business that sells auto parts: 

  • Parts
    • Engines
    • Spark Plugs
    • Filters
    • Belts
    • Hoses
  • Wheels
    • Tires
    • Brakes
    • Rims
  • Exhaust
    • Emissions
    • Mufflers
  • Interior
    • Stereos
    • Alarms
    • Lights 

Designing the Subject Tree 

One of the most important uses of the Subject Tree is to classify important record types such as cases, products, and Knowledge Base articles. For example, several pre-configured reports are available that feature sorting and grouping by the values entered in the Subject Tree. As a best practice, consider designing the Subject Tree before the deployment of Microsoft Dynamics CRM. As part of the design process, review reports such as the Case Summary Table to verify that the Subject Tree values you have entered satisfy your organization's reporting requirements. 

Also important is to review which users in your organization should be allowed to create and modify values in the Subject Tree. By default, users assigned to any of the manager security roles or higher can update the Subject Tree. Many organizations may want to restrict privileges to update the Subject Tree to fewer security roles than this. 

Knowledge Base 

The Knowledge Base is a repository of articles containing problem resolution information, best practices, technical details, or any other documentation that business users access to address and resolve issues. Knowledge Base articles are often used by service and support professionals to assist in the process of resolving cases for customers. 

Use of the Knowledge Base can benefit organizations in many ways, including the following: 

  • Customer service organizations might experience high turnover. Therefore, it pays to capture the knowledge of experienced service workers and maintain that knowledge within the organization. The Microsoft Dynamics CRM Knowledge Base provides a method for retaining knowledge.
  • Knowledge Base articles can help new employees learn and help service personnel find information about unusual, rare, or difficult problems. Knowledge base articles can provide clear and concise information that is approved by the management team to ensure accuracy and consistency.
  • An organization could create a customer portal website to make Knowledge Base articles available on a self-service basis to external customers. 

Cases and the Service Management Process 

In most organizations, service representatives are required to record contact with customers, such as case resolution and customer inquiries, complaints, or recommendations. 

Microsoft Dynamics CRM helps an organization find the balance between doing work and tracking the work done by providing a customer relationship product that does not require burdensome amounts of data entry. 

By providing a structure for tracking customer inquiries, the Microsoft Dynamics CRM service module provides several benefits, including the following: 

  • Cases can be automatically routed to an appropriate queue or service representative based on criteria defined by the organization.
  • The case resolution process can be simplified and automated with processes such workflows and dialogs.
  • Important customer interactions and activities can be managed more effectively.
  • By providing better customer service, customer relationships can be improved as well. 

Creating and Assigning Cases 

Like most record types in Microsoft Dynamics CRM, case records have several fields which are required by default. Organizations can customize many features of the case creation process, including adding custom fields to the form, or changing the requirement settings of certain fields. Here are some important considerations to keep in mind regarding the default case creation process in Microsoft Dynamics CRM: 

Required fields

  • The Title field is required. You can enter any text you like, although many organizations define agreed-upon conventions for text fields such as this one.
  • The Customer field is always required for case records. This requirement setting cannot be changed. The behavior of this lookup field is identical to other places it is used on forms, such as the "Potential Customer" lookup field on the Opportunity form: you must use it to identify either an account record or a contact record as the customer record with which the record will be associated.
  • The Owner field is always required for case records as for most other record types. Case records have a default behavior slight different from other record types, in that by a new case record will be routed to the owning user or team's "default queue". 

Other important fields

  • Subject is a lookup field to the subject tree discussed above.
  • Case Origin is a picklist with default values of "Phone", "E-mail" and "Web", which can be customized by a system administrator.
  • Case Type, Satisfaction, Status Reason and Priority are also picklists with default values that many organizations will customize to fit their business requirements. 

Queues and Contracts in Service Management 

Neither queues nor contracts are required for Microsoft Dynamics CRM service management, but each offers several advantages to organizations choosing to use them. 

Queues can be used to manage work items, such as cases, activities or other record types. Microsoft Dynamics CRM users by default have personal queues which can be used to route important activities and records assigned to each user. Shared queues can also be used to support service management in a team-based collaborative environment. Cases are often routed to queues as part of an automated service management process. 

Contracts can be used to specify levels of service to which customers are entitled. Contracts can be associated with cases. When cases and contracts are used together, organizations can automatically track and maintain a running balance of important customer entitlements such as the number of hours or support incidents remaining on a contract. 

Introduction to Queues 

Queues are containers for work items, such as cases, activities or other record types. Both users and teams have default queues, which can be used for routing important items. In addition, shared queues can be created by users with sufficient security privileges. These shared queues can be made visible to all users in an organization, or can be secured so that only certain users or teams have access to the items they contain.  

When users and teams are added to the system, each new record is configured with a "default queue". While most record types in Microsoft Dynamics CRM can be customized to support queues, only cases and activity record types are pre-configured with support for queues. A demonstration of this important functionality is shown next; queues are covered in detail later in this course. 

Some common uses of queues include:

  • An escalation queue might be a shared container for service cases not resolved within a specified time frame or other violations of a customer service level agreement.
  • Queues might also be designated for cases meeting specific criteria. For example, all cases regarding mountain bikes can be routed to the "Mountain Bikes" queue, while cases regarding road bikes are routed to a "Road Bikes" queue. Customer service representatives (CSRs) with the appropriate expertise might monitor each queue.
  • Opportunity records with estimated revenue above a certain threshold might be routed to a special queue to elevate their visibility to sales management. 

Introduction to Contracts 

Contracts can be used to specify the amount of support services a customer is entitled to. This "allotment" can be defined in terms of number of hours, or number of support incidents, for example.  

Contracts are not required to work with and resolve service cases, but they do provide some additional benefits if used. For example, a contract can be used to maintain an agreed-upon number of support incidents for a customer. Then, cases can be associated with this contract, and as cases are resolved, Microsoft Dynamics CRM will automatically maintain a running balance of available incidents remaining for the customer. 

If a customer has an active contract, it can be associated with a case record by searching for it in the Contract and Product Information section of the case form. If a customer does not have a contract, or a contract exists but is not active, no contracts will be returned when the search is performed.

Leave a Comment
  • Please add 8 and 3 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
Comments
  • Carsten Siemens edited Revision 3. Comment: Completed titel of original source  in plagiarism note

  • Carsten Siemens edited Revision 2. Comment: Pirated Content - see my comment

Page 1 of 1 (2 items)
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
Comments
  • Carsten Siemens edited Revision 2. Comment: Pirated Content - see my comment

  • NOTE: This article was reported as Pirated/Plagiarized Content (content you didn't write) and will be removed. Please do not steal content from others. If you feel we are mistaken, please leave a comment or email tnwiki at Microsoft with a link to this article and with clear and detailed reasons why you own the content or have explicit permission from the author.

    Content was taken from: "Book - COURSE 8913:  APPLICATIONS IN MICROSOFT DYNAMICS - CRM 4.0 (page 15-2 ...) -"

    Published by Microsoft on December 2007

    de.scribd.com/.../8913-En-Applications-in-CRM-Student-Manual

  • Carsten Siemens edited Revision 3. Comment: Completed titel of original source  in plagiarism note

Page 1 of 1 (3 items)