Last time we discussed Entitlements Management, we were looking at the basic functionality. This time around, we’re going to dig into some decisions about how to set it up. The first of these is choosing the Entitlement Model. The way I think about the Entitlement Model is this:
- How is support sold to the customer?
- Where is the agent going to confirm that the customer is eligible to receive support?
Can you answer those two questions (or one of them, even)? If so, you’re well on your way to figuring out which Entitlement Model is right for your organization.
Before going any further, I want to call out one important fact. Entitlements Management is a flexible system. This means that you can make decisions today and revisit them in the future. As your business needs change, Entitlements Management can handle those changes. Maybe you’re changing your support process a little bit. Maybe your organization is rethinking how it approaches support at a high level. Entitlements Management has the flexibility to handle these changes without a lot of headaches.
Let’s consider the following Scenario:
An organization provides support to customers who have purchased their product. If you own it, you get support on it – it’s included in the price. There isn’t any tight tracking of who can call for support.
In this case, the organization just needs to confirm that the customer does own the product. Since they are keeping it simple, they could use an Entitlements Only model. The agent is confirming that there is an entitlement record. There are no service contracts or separate purchases involved. This is the simplest model of entitlements. It’s most appropriate when an organization treats entitlements like a warranty.
It’s possible to set up the Entitlement record to link it to other objects. An example of this is if only certain contacts from a company should be contacting support. Through a related list on the Entitlement record, those contacts would become Entitlement Contacts. Establishing entitlement contacts allows support to verify which contacts exist on an entitlement. It also allows support to verify which Entitlements a specific contact has. Another example would be if the Entitlement has a lookup relationship to the Asset. Each entitlement has an association with a specific asset belonging to a customer. But wait… there’s more. It’s also possible to link the Entitlement to the account. In that case, the entitlement record will show up in a related list on the Account page.
What’s cool about Entitlements-only is that it is linking to standard objects. These objects are objects most Salesforce implementations use. This makes it easy to set up basic entitlement models without much extra work. Sometimes, though, this doesn’t reflect the way that a company runs its business. As organizations have learned, service is a competitive differentiator. More and more organizations offer ‘premium’ support at a premium cost. Other organizations use tiered service or sell extended warranties. In any case, the idea remains the same: Service as a product. The agent is no longer just looking up if they own a product. They now are looking to see if there is a service contract in place. In these cases, it can start to make sense to use a different Entitlements model. Salesforce offers two basic choices here:
- Service Contracts with Entitlements
- Service Contracts with Contract Line Items and Entitlements
The two are similar in some ways, but different in others. Service Contracts with Contract Line Items and Entitlements involves line items. This means that the warranties, service agreements, subscriptions, etc.. appear as line items on a sales order. These line items link to one or more entitlements, but the items get treated as products. The agents verify based on the line items present in the Service Contract.
Service Contracts with Entitlements is a little bit simpler. The service contract exists as its own entity. The agent verifies that a contract is present, but they don’t dig into the specific line items inside of it. This applies when a customer renews their entitlements at a contract level. In both cases, the Entitlements are purchased and managed separate from the product. For more information, I recommend looking at Salesforce’s documentation and the Entitlements Implementation Guide. It contains charts that can be helpful to determine what model suits your business.
Before we move on, I’d like to introduce one caveat. Service Contracts with Contract Line items and Entitlements does demand the use of products. If your organization doesn’t currently use products, this may be a consideration.
When thinking about choosing an Entitlement model, communication is key. Try to identify and engage all the stakeholders involved. That engagement piece is critical – take time to gather good requirements! Don’t assume you need a complicated model if a simple one will do. It also doesn’t hurt anything to go down one road and later discover you need to change. Requirements always change, and what you learn now will help you in the future. As I mentioned earlier, Salesforce designed Entitlements to be a flexible system. If you need to change things mid-stream, it will be okay.
For the purposes of the next few posts we’re going to introduce a hypothetical scenario. We’ll start today by choosing an Entitlements Model.
Here’s the scenario:
Alembic Java is a mid-sized company that supplies high-end Coffee subscriptions and services. Their market is offices and homes throughout the US. Besides coffee, they also provide coffee-brewing equipment and classes in brewing and appreciation. Here are some relevant bits of data:
- 60 support reps.
- Over 5000 customers and growing.
- Customer base is both commercial and residential.
- Two different support processes – one for commercial accounts, one for the residential accounts.
- The support process is First Response, Update the Customer, Resolve the Issue. The timing is different when the priority is higher.
- At the moment, the support reps verify customers by checking the account record. They look to see if there is an asset on the record. If so, Alembic will offer support.
Based on the above, what do you think would be an appropriate Entitlements Model? Did you say “Entitlements-Only”? If so, we’re in agreement. If not, let me explain why I didn’t choose a different one:
Service Contracts with Entitlements. Alembic could structure their support to work this way. It might make sense to sell separate service contracts, but it’s not what they are doing today. Alembic is using a standardized model of support across their products. Eligibility for support comes from having a subscription. In this case, the support is ‘bundled’ into the price of the coffee. There’s no benefit to creating or managing service contracts right now. If they decided to pursue this business model, it would be worth revisiting. For now, this would represent extra complexity without extra benefit. Likewise, Contract Line items would not be helpful for Support or Sales at this time.
Next time, we’ll dive into some of the Alembic’s specific requirements. Then, we’ll walk through creating milestones, milestone timelines, and entitlements.