If you’re planning to build a paid application that will be hosted on the Salesforce AppExchange, you’ll soon encounter the question, “how does licensing work?”
The most common and recommended option that guarantees the best return on your investment is to set up the app so the customer pays for a specific number of app licenses and assigns those licenses to Salesforce users as appropriate. This is referred to as ‘per seat licensing’. As the owner of the product, you can also determine how many app licenses constitute a seat.
Recently, I had the chance to work on two different projects back to back, for two different clients (let’s call them Client A and Client B). Both of them decided that it was important to go with the per seat licensing model to ensure that the revenue from the applications is driven based on the number of people using the app. I was tasked to design both applications to technically enforce this requirement. There’s no universal key approach to solve this problem and the solution really depends on the nature of the product and feasibility of restrictions. Though the problem at hand is the same, the solutions had to be very different based on the nature of the applications.
Client A:
Product context
Client A built a sleek engine that collects useful metrics about companies worldwide including any recent news references, important people, funding info, employee count, etc. They’ve built a high latency API so that other systems can take advantage of this information. However, they had to offer this for a fixed fee with no way of maximizing their revenue based on the usage. If XYZ company has 6,000 sales reps taking advantage of their information – and placing more load on the API – Client A had no way of measuring that and billing XYZ company accordingly.
Now, Client A wants to build an AppExchange app that integrates with their API and provides information to Salesforce so that accounts and leads in Salesforce can be automatically enriched with this powerful data. This will help sales reps have much more context about the account, lead or opportunity.
Problem
How can we make sure we solve their current problem of fixed billing and provide them with the ability to charge customers based on the usage (number of users trying to use the enrichment data)?
Solution
We designed the application such that only records owned by users who have the app license assigned will be enriched. Let’s say there are two sales reps: Tim and Tom. Tim has been assigned the app license but Tom doesn’t have one. Accounts and leads owned by Tim will have the enrichment information populated but accounts and leads owned by Tom won’t have any enrichment info.
If you’re like me, you must be thinking what if customers try to trick the application by having a single owner for all accounts and hence purchase a single license? Record ownership is a cornerstone to a lot of features that Salesforce offers and the customer would pay a steep price to let go of all that just to save some bucks for using this app. Client A was okay to have this as the restriction, given their target customers.
Client B:
Product context
Client B built a smart and powerful AI engine that can predict the most likely choice based on input text and historic data. Application use cases for this engine are limitless. As part of one of the use cases, they wanted to build a Salesforce app which takes advantage of their AI engine and prefills field values on cases, leads and possibly other Salesforce objects. This can also enhance the routing process of those records. For example, when a case comes in, case description and title (unstructured text that Salesforce’s OOB routine engine cannot process) can be sent to Client B’s API, which will predict a value for the case category field to be ‘Baggage department’. The case routing can be set to assign the cases to the appropriate queue/customer service agent based on this field. This saves a tremendous amount of time during the routing process as well as for the customer service agent who is handling the case since they don’t need to manually fill in all the case details.
Problem
How can we make sure that Client B gets their fair revenue share based on the number of agents taking advantage of their prediction data?
Solution
We cannot have restrictions based on ownership of records in this case since one of the main purposes of the product is to prefill fields so that they can be routed to appropriate owners. Also, if we impose any restrictions based off of ownership, there’s a chance that all new cases will be assigned to a default owner (which is a common practice), meaning a customer could purchase a single license when 1,000 reps could be working on those cases. Thus, making Client B leave money on the table by losing their fair revenue share. The solution that worked for Client A does not apply to Client B. Our recommendation for Client B was twofold.
- This license and checkout process is based on the trust between Client B and their customers. Hence, answer the customer’s question “How many licenses do I need?” by saying that it should be approximately equal to the number of active customer service agents.
- Have a scheduled process that runs periodically to send the aggregate number of active Service Cloud users and the number of app licensed purchases to Client B so that they can contact their customers to see if there’s a specific use case why they might be doing it.
Summary
There’s no one-size-fits-all solution for technically enforcing the per seat license model as part of the application. Your solution will depend on the customer’s product, target market, pricing model and various other options.
