Part 2: SaaS Entitlements: The What, Why and How-To

This blog is Part 2 of the Series on understanding Entitlements. Part 1 covers the basics of Entitlements.

In this blog, we will examine the key requirements for entitlements from the perspective of different stakeholders. These requirements will form the basis for the best implementation approach, a topic we will cover in Part 3.

Requirements for Entitlements

‎

Entitlements impact several functions/roles within a company —

1. Product Manager
2. Engineering
3. Sales
4. Finance
5. Customer Success/ Support and even the
6. End customer

In this section, we will examine the requirements of each stakeholder.

Product Manager

As a product manager, I should be easily able to:

• Add a new entitlement to an existing plan
• Migrate an existing entitlement from a higher-tier to all the lower-tier plan(s)
• Run reports on an entitlement/plan basis, e.g., what % of users in a particular plan are utilizing a specific entitlement that is not available in the lower-tier Plan.
  • If the % usage is low, the product manager can consider migrating this feature to the lower-tier plan
  • If the % usage is high, the product manager now understands that the entitlement is an excellent step-up feature
• Add one or multiple tags to the entitlement. These could be — "New feature," a country name* (to indicate that this feature is available in that country), or "beta" (not fully launched).

* Ideally, every country should have dedicated plans based on the corresponding local currency (more on this use case in a later blog), and each such plan should have its list of entitlements. However, traditional billing systems don't have good support for multiple currencies and geo-specific payment processors, and as a result, it is pretty common to see USD currency pricing being available worldwide.

Engineering

As an engineer, I would like to choose an architecture that offers the following:

• A single system of truth for entitlements
• Plan for failure (if the entitlement service is slow or unresponsive)
• Ability to make changes quickly required by the product team around entitlement workflows
• Ability to satisfy the requirements of all the stakeholders

Sales

As a sales rep, I would like to be able to:

• Edit certain entitlements for an enterprise deal. For example, for entitlements with a value/range, be able to edit the number up or down. Let's say we have two entitlements:
  • Feature A: default value 500, max value 1000
  • Feature B: default value 200, max value 50

During negotiation, the customer wants less of Feature A and more of Feature B; I'd like to be able to edit these numbers. One could argue why such limits exist in the first place and why not offer the max values upfront. In this case, not using the max values acts as a negotiation lever to increase the perceived value of the deal to the end customer. If, however, these features can be associated with strong value, they can also be priced. As we mentioned in Part 1 of the blog series, it is not an entitlement in that case but a product or an add-on.

Billing

As a billing person, I would like to be able to:

• List certain entitlements on the invoice (especially the ones whose values were edited during the quoting process).

Customer Support / Success

As a customer support or customer success specialist, I would like to be able to:

• Find the plan and corresponding entitlements for a given customer (ideally, all this information should be in-product so that both the end customer and support have the same view)
• Suppose the customer needs to upgrade to a new plan or buy more units of a value-based entitlement. In this case, I should be able to direct the customer to the appropriate in-product experience, or if that's not built as yet, I should be able to go to the internal billing system and make the changes myself.

End Customer

As an end customer, I would like to be able to:

For value-based entitlements:

1. How many units of entitlement have I used so far? For example, an entitlement allows the end user to "5 reports", and the user wants to know how many reports they have remaining.
2. Am I close to exhausting the entitlement? In the above use case, the customer would like to be notified through some means (email, in-product notification or even text depending upon the use case) when they have only 1 report remaining. Ideally, such workflow is pre-configured for the customer with the flexibility to edit the threshold.
3. Can I buy more? The end user could either upgrade to the next plan (with more units of the entitlement) or buy more.

For non-value-based entitlements

1. What entitlements have I not used? Power users often seek to extract more value from the product, and showing what entitlement(s) they haven't used so far could be a good trigger point for exploring the corresponding functionalities.

How to implement Entitlements?

Given the above requirements, the question is how to best implement entitlements.

There are essentially three approaches to doing it.

1. Hardcode the logic in your product
2. Store them in a database somewhere that the product queries in real-time (feature-flags is an excellent way to think about this use case)
3. Store them in the billing system

In the next blog of this series, we will learn why most choose Approach #1 even though it is the least optimal and why Approach #3 is actually the best, although it requires your billing system to be integrated with the quoting system.

Stay tuned!