Cases
Cases (Service Cases) are where the rubber meets the road for Customer Service. Cases are used to track all service interactions with your customers. Normally, we might think of Customer Service as a generic category for all issues related to a customer's interaction with an organization's people, processes, products, and services. This would be a fair assessment of the way that Cases can be used in Microsoft CRM. Figure 9.9 shows the Service Case screen.
Figure 9.9. The Service Case screen.
Microsoft CRM Cases can support multiple, varied servicing processes. Some of the ways Cases can be used include, but are not limited to
Product Technical Support
General Customer Service
Collections Issues
Implementation/Installation
Site Service Calls/Visits
Multiappointment organization (for example, scheduling a prospective student's day visit to a university or a customer's visit through multiple departments of a spa)
A little later we'll look at an example of how we can leverage Activities in supporting multiple, varied processes. However, for now, let's look at Table 9.5 for a clear understanding of Case records and their attributes.
| Tab.Section.Field | Description |
|---|---|
| General Assignment Information | |
| Owner | The User to which the Case is assigned. |
| Status Reason | The Status Reason field displays different values based on the Case's current status. These Reason values are hierarchically linked to the various Case Statuses. While Case statuses cannot be modified (Active, Cancelled, and Resolved are the fixed Case status values), status reasons can be modified. Let's look at examples of why we might want to do this. First, by default, Cases in the Active status have status reason values of
|
| Customer Information | |
| Customer | The Customer field links to the Contact or Account record associated with this Case. |
| Overview | |
| Title | Title is intended for a brief description of the issue. |
| Subject | The Subject field enables you to categorize the Case based on the Subject hierarchy discussed earlier. You can think of this as the Case Type. Having Subjects associated with Cases enables you to identify Cases based on product line, but not necessarily the specific product or on a general subject that is not product specific. |
| Description | Description is an expanded overview of the issue at the center of the Case. |
| Details | |
| Contract Information | |
| Contract | The Contract field enables the user to lookup all Contracts associated with the Case's customer (Contact or Account) and associate the Contract to the Case. You must make this association if you plan to track the use of Case or Time allotments against Contracts. Without adding a Contract to the Case, you cannot add a Contract line item and, therefore, you would not be able to track allotment usage. |
| Contract Line | After a Contract has been added to the Case, you can use the Contract Line lookup to associate the Case with a specific line item on the Contract. This enables allotment tracking and more specifically identifies how the Contract is being fulfilled. |
| Product Information | |
| Product | The Product field can be used to associate a specific Product to the Case. This can be useful if you later want to track the number and nature of Cases attributable to each Product. This can be overbearing if you have general product lines with numerous SKU's in each line. In this case, it might be easier to associate Cases only with Subjects and remove the Product field from this screen. This is, of course, dependent on how you plan to use the data you wish to collect. |
| Serial Number | The Product's Serial number can be included on the Case. Remember that Serial Number can also be included on the Contract line item records as well. |
| Follow Up By | This field allows the user to manually enter a date for follow up or a Workflow process could be configured to set the date automatically based on other attributes of the Case or the Case's associated Contract or customer. |
| Priority | The priority of the Case as defined by the administrator. |
| Details | |
| Contract Information | |
| Service Level | The Service Level guaranteed for the Case. This information can be pulled from the Case's associated Contract. |
| Satisfaction | The customer's satisfaction level with respect to the handling and resolution of the Case. |
| Case Origin | Case Origin enables the user (or an automated process) to record how the Case was initially logged in the system. The default values of this field are Phone, Web, and email. |
| Case Type | Case Type refers to the nature of the question. The default values for this field are Question, Problem, or Request. |
Figure 9.10. Resolving a Service Case.
In our discussion of the Status Reason field we differentiated between the Case's Status and the Status Reason field. Table 9.6 provides more detail on the statuses of Case records. Again, remember that the Status of a Case refers to the uneditable header information that can be found in the lower left corner of the Case screen.
| Status | Event | Description |
|---|---|---|
| Active | User creates the Case | Case is open and Activities and Notes can be added to it. |
| Cancelled | User cancels the Case by selecting Cancel Case from the Case's Actions menu. | Canceling a Case is like canceling a Contract. The Case record remains in the system, but in a deactivated state. New Activities and Notes cannot be added to cancelled Cases. A User can reactivate the Case by selecting Reactivate from the Case's Actions menu. |
| Resolved | User resolves the Case by Selecting Resolve Case from the Case's Actions menu. | When a User resolves a Case, the Resolve Case screen (see Figure 9.10) is presented and the User can enter the total amount of billable time as well as a description and notes about how the Case was resolved. This information is added as a Resolution record on the Case's Activity History tab. New Activities and Notes cannot be added to resolved Cases. |
Service Cases can be created directly from the Contract or Line Item screens, allowing them to inherit certain information from the Contract and Contract lien item objects. This can save keystrokes and ensures that each Case is associated with a Contract.
Using Activities with Cases
We mentioned earlier how Cases can be used for everything from Implementation to Technical Support. Activities can help us with this, especially when we enable Workflow processes to automatically create Activities based on the type of Case we have created. For example, let's look at a company that sells and implements software. For this company we can create a Subject called implementation and enable workflow to auto-generate Activities for Cases created with the Implementation Subject. Figure 9.11 illustrates a group of auto-generated Activities on an Implementation Case.
Figure 9.11. Auto-generated Activities on a Case record.
The purpose of this example is to illustrate that, as we said earlier, Microsoft CRM is a versatile tool that can be used in various ways. As with any CRM package, you will often have to be creative in your data and process modeling, but the better you understand the application, the more you will be able to achieve.