When a customer calls and requests support, how does a business know if and what level of service they are entitled to? Or what if service is only provided on certain products? Service could be provided for a certain period (e.g. a warranty) and then a customer must pay for service beyond the warranty period. It could also be that customers can purchase extended warranties or service contracts that may be valid for a certain period or only for certain products. As you can see, managing and tracking entitlements can become complex! Many organisations have difficulty making sure that the appropriate level of service is provided and it is not hard to understand why!

What is Entitlement Management?
In Salesforce Service Cloud, entitlement management is used to assist service agents to verify whether a customer is eligible for support, manage service contracts and service levels.

What kinds of entitlements are available in Service Cloud?
Salesforce supports three such entitlement management methodologies:

• Entitlements Only
• Service Contracts with Entitlements
• Service Contracts with Line Items and Entitlements

The basic difference lies in the number of criteria that define your Entitlement Management Process. It could be as simple as to check whether eligible for support or not. This is a simple Yes / No situation and is depicted by the “Entitlements Only” model. Remember, simplicity isn’t always bad. Some companies might just not want the granularity and administration overheads imposed by the other two Entitlement Models.

The “Service Contract with Entitlements” model is used when an additional criterion called Support Levels are introduced into the equation. Support Level would mean the Premier / Gold / Silver categorization of support offerings. This entitlement model allows you to track whether a customer is asking for more support than what his support contract allows.

The third type of Entitlement model is where you would want to specify the support levels per product lines.

So, with these models, entitlements can be setup to be based on:

• Account
• Account Contacts
• Specific Assets
• Service Contracts
• Product / Asset covered under a Service Contract

Lets look at an example where an entitlement is setup for a specific asset. In the example below are the details of the mixing machine asset recorded against the Aethna Corporation account.

An entitlement record can be created against this asset. The start and end dates can be set, in this case the entitlement is valid for 2 years. Salesforce has a standard formula field and icon to determine if the entitlement is active. There are additional features available such as limiting the number of cases that can be created against the entitlement. For example, the entitlement may be valid for 2 years as below, but also has a limit on the number of service calls allowed. The ‘Cases Per Entitlement’ could be used to limit the number of cases that can be created and associated with this entitlement to a certain number.

Now that the asset and entitlement records are setup, let’s imagine that a customer calls as their mixing machine is not working. Salesforce describes the process that the support agent would follow as :

1. Customer calls support
2. Support agent searches for the customer’s account, contact, asset or service contract
3. The support agent verifies that there is an active entitlement
4. The support agent creates a case from the entitlement

In our case, the agent would search for and navigate to the customer asset record as show below. Entitlements are displayed in a related list. In the example below, there is one active entitlement. A link is provided to create a case directly from the entitlement.

Another example is using Line Items in a Service Contract.  An electronics company offers washing machines, TVs and electric shavers. A customer has opted for an extended warranty for the washing machine and TV, but not for the electric shaver. Service Contracts are ideal for businesses that offer paid extension of warranties, or tiered levels of support. Also, note the out of the box association available between a Service Contract Line Item, and an Asset. Asset is a purchased instance of a product, and that is the logical entity for which a business would provide a service for.

 Shown below is a sample service contract for our example:

If the Service Contracts and Service Contract Line Items objects need to be customized, this can be done in the Entitlement Management section. Interestingly, unlike the other standard objects this is nested within the Entitlement Management section in setup, and is not visible directly in the “Customize” section.

The appropriate custom fields, page layouts, validation rules and so on can be configured for the Service Contracts and Contract Line Items objects. The configuration is not any different from how you would configure other standard object, however these objects would appear only if you have a valid Service Cloud licence (or a developer edition).

The Service Contract tab needs to be made visible in the appropriate App, as well as adding the Service Contract related list to Account or Contact. A service contract must always have an associated Account or Contact, for it to make logical sense.

Once the Service Contract and Contract Line Items are in place, the next step in the process would be to define an Entitlement. Similar to service contracts, you would visit the Setup screen, and configure the necessary fields, layouts, validation rules, etc. for the Entitlement object; and finally expose it as a tab. Also, you would expose Entitlements as related lists for Account and Contact, which improves service rep productivity.

An entitlement record can be associated with an entitlement process. The entitlement process defines the rules enforcing service levels.

Just like a Sales Process, Entitlement Process defines the path through which a Case should progress. The Entitlement Process is defined from setup, and is an ordered collection of Milestones. Milestone records are characterized by a deadline (in minutes, hours, or days), success action, warning action and violation action. For example, a milestone may be setup to ensure that the case status is updated to ‘Responded to Customer’ within 8 hours. Success, warning and violation actions can be associated with workflow actions to send out emails, create tasks, or change a case owner (to signify escalation). The ordered set of milestones form an entitlement process.

This is just an overview of what is possible with Entitlements in Salesforce.  All the above mentioned objects that are part of the entitlement process are accessible via Apex, and therefore you could customize the behavior to further suit your business needs. One common requirement is to provide more assistance to the support agent to determine the appropriate entitlement either by providing a mechanism such as a button on the account screen to search for valid entitlements manually or do an automatic entitlement check.

Appexchange products such as ServiceMax provide comprehensive entitlement functionality for field service applications, including the abilty to define entitlements at multiple levels (e.g. product lines, part numbers, based on counters), entitlement verification and the auto entitlements, both for internal users and self service.

The Salesforce entitlement implementation guide can be found here:
Salesforce Entitlements Implementation Guide