You may have seen the news that Adobe announced the Adobe Creative Cloud and that they are going all-in on a subscription pricing model (see "Adobe Goes All-In On Subscription Pricing Model", "Adobe Kills Creative Suite, Goes Subscription Only" and "Adobe CEO: The Truth About Creative Cloud" for more details).  This is certainly interesting news and confirms what we've been seeing in the market and our research confirms – the move to subscription and usage-based licensing models is real and gaining speed.

Unfortunately, as is often the case, the discussion about software licensing models often gets confused with the deployment model.  In this case, Adobe has decided to only offer the product with a subscription licensing model.  You can no longer purchase it via a perpetual license model.  This decision does not directly have anything to do with how the software is deployed and delivered.  If you read into the details of the story, the software is now a hybrid deployment with both a local client application with cloud services as well.  In fact, the CEO comments that you can use the product just fine in a disconnected mode where you have no internet connectivity.  Even by their choice of name, Adobe Creative Cloud, Adobe has added a bit to the confusion as this suggests this is a fully cloud-based, software as a service (SaaS) product, which it is not.

We continue to see growing adoption of subscription licensing models for both on-premises and on-demand (cloud or SaaS if you prefer) applications.  Subscription licensing models are both viable and available for any type of software, including on-premises, on an increasing basis.  The only thing that does seem to be an absolute it that once a company has chosen to offer its product as a SaaS or on-demand service, it almost always does so via a subscription vs. perpetual model to more closely align revenue with ongoing operational costs associated with delivering the service.

I suspect you will continue to see more and more vendors moving this direction – adopting subscription and usage-based licensing models.  The market is demanding it and vendors are responding.  They are also demanding more cloud-based offerings as well which is why we continue to see many established companies acquiring cloud-based applications.  But keep in mind that the software licensing model and delivery model are two separate things that may or may not be related – and each offers their own benefits to both application producers and their customers.

For more information on subscription and usage-based models, please read:

• Usage-based Software Licensing Examples and Patterns
• White Paper: 2012 Key Trends in Software Licensing and Pricing Report

In Part 1, I talked about the well-known tradeoff that product bundles are advantageous for producers while a la carte offers are advantageous for consumers. In Part 2, I discussed the tradeoffs of product bundles versus a la carte from an entitlement management perspective and in Part 3, I will discuss best practices regardless of the course you pick.

Product and Entitlement Management Best Practices

• Keep it simple: Whether you choose product bundles or a la carte offers, have no more than 3-5 orderable options per product family to keep it simple for sales professionals and customers.
• Consider a "base + options" approach to get the best of product bundles and a la carte offers. A base bundle could package features that 80% of customers would want while niche features could go into a la carte offers. Feature usage analysis could help you fine tune what to package into the base versus a la carte offers.
• Invest in an entitlement management system. Regardless of the approach, keeping track of customers based on bundles or a la carte options can become complicated very quickly – an entitlement management system would be the way to go
• Be change-ready - changes in product packaging are inevitable as sales, customer and market needs evolve. Successful software products with active product roadmaps involve packaging and pricing with almost every major software release. Again, entitlement management systems are the proven approach for handling packaging changes without significant IT change costs.
• Avoid dependencies between options in an a la carte model. In the EZ Calculator example, if you had made "add" and "divide" a la carte, then the "average" feature would require both "add" and "divide" to be ordered and activated.
• Avoid version upgrades at the product bundle level. Version upgrades are either part of software maintenance or require separate purchase. If you version a product bundle, versions for products in a bundle have to be synchronized. This is probably one reason that Microsoft's Office suite is released once every few years. Version upgrades for a la carte product options can be independent of each other – making them more flexible for publishers. Note that SaaS and cloud-based apps can escape issues related to product versioning since by definition; most SaaS products support only one version for all customers.
• Pick orderable names carefully – ensure that the value of a bundle or option is self-evident from the name. Look to buyer personas (E.g. Accountant or Scientist for EZ Calculator) or customer segments (e.g. Home, Small Business, Enterprise for Microsoft Office) or use case groups for inspiration.
• Think through entitlement lifecycle use cases before you pick a course. Think beyond the initial order – subscription/maintenance renewals, upsells, version upgrades, software updates and machine management are all essential use cases to map out into a seamless customer experience.
• Standardize on one approach (i.e. bundles or a la carte) across product lines in your company. This makes it easy for sales professionals and customers.
• Invest in a customer experience czar. Once you grow beyond a few products and handful of customers, the sheer complexity of entitlement management can bog down your business and your perception as a company. Having a single voice for your company that ensures consistency of entitlement lifecycle processes and customer experience is key.

What approach has your company picked? Why? Are you planning on changing it? I would love to hear your perspectives.

Related articles

Product Bundles or A La Carte Products: Entitlement Management Tradeoffs & Best Practices - Part 1

Product Bundles or A La Carte Products: Entitlement Management Tradeoffs and Best Practices - Part 2

Why Producers Need a Proven Commercial License and Entitlement Management System to Support the Full Software Lifecycle Process

Why Salesforce.com Isn't Suited for Complex License and Entitlement Management Processes

In Part 1, we talked about the well-known tradeoff that product bundles are advantageous for producers while a la carte offers are advantageous for consumers. This time we will discuss from an entitlement management standpoint, product bundles versus a la carte and the tradeoffs.

• SKU management. Suppose your app, EZ Calculator, offers features like add, subtract, multiply, divide and so on. You want to target casual users, accountants and scientists. The table below lists the SKUs you could offer as bundles or a la carte to monetize the features in EZ Calculator. Notice that a la carte offers can achieve the same business results with fewer SKUs. When you add upsell paths (e.g. Basic Edition to Scientist Edition), the number of SKUs grow for the product bundles approach.

• Sales positioning & ordering experience. For the initial sale to a new customer, product bundles can be easier to position and order. In the EZ Calculator example, if you are an accountant, you just buy the Accountant Edition if the bundle is offered. But, an accountant would need to buy Base plus the Accountant package in the a la carte model. Too many a la carte offers could end up in a complex and confusing selling and ordering experience. Note that if you do offer upsells between bundles, the ordering experience post the initial sale could be just as complex for product bundles.
  
• Dependencies between features could be hidden from customers in a product bundle. Too many a la carte options with dependencies between them might require a product configurator to get orders processed correctly. 
  
• Packaging evolution over successive software releases. With product bundles, new and chargeable features have to be added to an existing bundle. To monetize the extra value from these features, bundle prices have to inevitably increase over time, if you stick with the same set of bundles. Case in point: between 1995 and 2011, cable channels included in Basic Cable grew 5% per year and monthly prices for Basic Cable went up 6.1% per year, almost in lockstep. Eventually, price increases will force some customers to drop out. In contrast, new features can be added to existing options or to new a la carte options – so a la carte is more flexible for producers without the inevitable price increases for customers associated with bundles. 
   
• Product & software license fulfillment experience (or service provisioning for SaaS) for initial purchases are usually streamlined and simplified for product bundles. In contrast, a la carte offers can result in an error prone experience as there can be dependencies between them. But, if you do offer upsells between bundles, the product and softwa licensing experience could be just as complex for product bundles over time.     

Interestingly enough, SaaS and cloud-based products seem to have picked the product bundle
approach to the extent that I could survey them. For example:

• Salesforce.com: http://www.salesforce.com/crm/editions-pricing.jsp
• Eloqua: http://www.eloqua.com/products
• Box.com: https://www.box.com/pricing/    

Unlike on-premises software, pure SaaS/cloud-based apps can mitigate some of the downsides of product bundles:

• Because they use subscriptions, upsell SKUs can be avoided by waiting till the end of a term and renewing users/customers on a higher bundle.
• Product and software license fulfillment issues do not exist by definition – users/customers are simply provisioned for whatever bundles they ordered

However, pure SaaS/cloud-based apps:

• Would still run into the issue of evolving product packaging (for new, chargeable features) without price increases for customers if they use bundles
• For 3 or 5 year subscriptions (an industry best practice), they would need upsell SKUs if users/customers do not want to wait 3 to 5 years to move from lower to higher bundles.

On balance, other than the initial ordering and fulfillment experience for first time customers, product bundles have no compelling entitlement management advantages over a la carte offers. I have tended towards the a la carte option largely because of the flexibility they offer over the product lifecycle. Despite what some leading SaaS/cloud-based providers have done, my sense is that they will have to re-think their product bundles approach at some point.

In Part 3, I will discuss product and entitlement management best practices regardless of the course you pick.

Related Entitlement Management blog posts:

Posted by Deloitte:

• Strategies to Improve Licensing and Entitlement Management Capabilities

• Why Producers Need a Proven Commercial License and Entitlement Management System to Support the Full Software Lifecycle Process
• App Stores for B2B Application Producers are Simply eCommerce Sites
• Publishers MUST Provide Entitlement Data to their Customers before Holding them Accountable for Compliance
• Consider How Software is Deployed to Drive Adoption of New Licensing and Entitlement Models
• Integrating Entitlement Management into Your Existing IT Infrastructure
• Best Practice: Publishers should provide software entitlement and maintenance information to customers and channel partners 7x24

Six years ago, I went off the cable TV grid. Despite 70+ channels, we were watching just three or four channels and overall, spending less time watching TV. At some point, given my consumption pattern, I felt it was not worth spending nearly $50 per month on cable TV. I recall calling my cable operator to see if they could offer me a la carte pricing on the channels I liked and was pretty much laughed off. No surprise, I dropped cable subscription altogether. The cable TV industry is still largely driven by bundled offerings – such as Comcast's Starter, Preferred and Premier bundles – and has still not caught on to the iTunes concept of a la carte offers of songs, TV shows, movies, apps and more. Like cable operators, software producers have to strategize between bundled products or a la carte offerings – in this blog, I explore entitlement management tradeoffs and best practices that will help you pick a course.

Before you read on, take a look at Microsoft's Office bundles which package Word, PowerPoint, Excel, Visio and other apps in different combinations. Microsoft also offers these apps a la carte, as standalone programs. Bundles can include distinct products (e.g. the Office suite). But, even a single app could be sold as bundles with different levels of features: for example, Microsoft sells Visio as Visio Standard and Visio Professional and Intuit's Quicken is offered as Deluxe, Premier and Home & Business.

So, why sell bundles in the first place? A well-known tradeoff is that product bundles are advantageous for producers while a la carte offers are advantageous for consumers. As an example: suppose you produce an app with feature A and feature B. Customer 1 is willing to pay $10 for feature A and $5 for feature B. Customer 2 is willing to pay $5 for feature A and $10 for feature B (see Table below).

If the producer:

• Bundles feature A + feature B for $15, they would make $30 (2 customers x $15)
• Offers feature A for $10 and feature B for $10 a la carte, they would make $20 (because Customer 1 buys only feature A for $10, Customer 2 buys only feature B for $10). They could also offer feature A and B for $5 each and get 2 customers for each feature but would still make only $20.

In this example, the a la carte model is advantageous for customers as they pay only for what they value. But, the producer makes more money with bundles. Of course, the example assumes that customers are willing to spend $15 in total for a bundle and will not walk away or postpone purchases due to "sticker shock" if the bundle is the only way to purchase. This is a big assumption driving the advantage for bundles - it works well in markets where the software producer is a monopolist and customers have no choice but to buy from them.

What about entitlement management tradeoffs for bundles versus a la carte offers? I will explore that in Part 2.

1. Business model differences
2. Inflexible operations
3. Non-compatible policies
4. Internal system capabilities
5. Organizational culture

3.   Non-compatible policies. Policies are framed to support the needs of a business model. Hence many of the policies of hardware companies fail to satisfy or even are at conflict with the needs of the software business. For example, as marginal cost of software is nearly zero, compensation and bonus structure in software companies are skewed to disproportionately reward top sales performance. A common policy for sales compensation between hardware and software would risk losing the software sales people by paying lower salaries. 

Besides managing existing policies, new policies that relate to software lifecycle events for e.g. software compliance enforcement policies (when would you deny software access, how would you respond to extra usage, do the policies vary across customer segments, geography etc.,) need to be developed. 

The diverse nature of the two businesses needs policies that can support them.  The organization should undertake a careful analysis of the combined businesses to identify the ones that can be standardized, those that need to be different and those that need be newly defined.

4.   Internal system capabilities. The ERP and CRM systems of hardware companies are designed neither to track software licenses and versionsat customer sites nor to manage entitlements for different software lifecycle events. Besides, the foundational capabilities required for supporting new software business models like managing bundled offerings, enterprise contracts, billing based on usage, recurring invoicing and sophisticated revenue recognition and allocation mechanisms are not well supported by traditional ERP systems.

I find that these poor system capabilities affect IDMs' top line and bottom line by inhibiting their ability to launch new products and business models, increasing operational costs and impacting customer satisfaction. While this is an issue for many software companies as well, I find that IDMs try to bend their internal systems a lot more until they break.


5.   Organizational culture. Software companies not only experience shorter product lifecycles but also experience rapid evolution of business models. Hence developing a viable software business is a continually moving target. To support this rapid change, the culture of software companies is more collaborative that enables them to co-exist in an ecosystem with other partners while at the same time they are also likely to have a more top down management approach to facilitate quick decisions.

The culture of many IDMs is at odds with that of software companies and poses significant challenges as they try to grow organically. This challenge is even more pronounced if they embark on an acquisition path. Even IDMs that have a successful track record of integrating acquisitions find these hurdles manifesting into longer lead times, significantly higher integration costs and less than expected benefits.

Companies embarking on a journey to become more solution-centric should be aware of these challenges. Although the path may be difficult and the waters rough, significant rewards exist for the one who traverse. A ship is safest at the harbor, but that is not where it is meant to be.

At Flexera Software, our products and services focus on helping IDMs from a strategic, operational and technological perspective as they navigate through the rough waters. For more information, read the related white papers: Ten steps to optimizing your software licensing revenue and How IDMs are using embedded software to grow revenue

Look forward to hearing your experiences and thoughts.

If David Letterman did a "Top 10 Signs Your Homegrown Licensing is Broken" it might go something like this…

1. Your CTO says to his team, "run, Forrest run" when you ask him to make changes to the license key generator
2. Your celebrity CEO is asked to sign a pirate copy of your software on a trip to China
3. Your LinkedIn request to hire someone who knows Cobol gets 0 hits
4. Your CFO ends up in Brazil after appearing on the cover of the Wall Street Journal for missing quarter end revenue
5. You realize that the latest spam email from Nigeria has a master key for your software
6. You only sell one copy of the software to China and your sales team says that the market is saturated
7. Customers are completely happy with a non-expiring trial version of your software
8. Your business is in an HBR Story "The paradox of 100% of the customers having your new software, but the renewal rate is only 10%"
9. Your Oracle R12 migration costs exceed the GNP of most countries
10. No one in your organization has ever heard of Flexera Software

What is in your top 10 list?

All kidding aside, if any of the Top 10 ring a little too close to home – our proven and scalable software licensing, entitlement management and software delivery and update solutions can help.

In the early 90’s I had a cell phone. It was one of those old clunky things, at least 2 or 3 inches thick and it only knew how to call people (imagine that). Just like the cell phone, the cell plan that was tied to the phone included a clunky pricing model – I paid afixed amount for unlimited local calls and a per-minute charge for roaming.  As you can imagine, the fixed amount wasn’t the issue, the roaming charge was the issue, for lots of reasons:

1. It was hard to know if you were roaming or not unless you looked at the phone as you were talking (my android phone still has a feature where it beeps if I go into roaming)
2. It was hard to predict your monthly pay outs—my bill, month to month, swung by 50-300%
3. So I tried very hard to not use my cell phone, unless it was an emergency. Of course, when you travel 50% of your time, this really dampens your productivity.

As soon as an operator provided a “some roaming is included” plan – I switched.

Now imagine the same with software and pay-for-use. If it’s highly predictable or a small amount, then I can see someone signing up for it. In fact, today as consumers we subscribe to $1.99 apps, $4.00 books and even $50.00 electrical bills, but would a CIO sign up for pure pay-for-use model, i.e. “every time your users run the French dictionary, you owe $1.00” or “for every KB stored by your users, you owe $0.50.” I just can’t imagine budgeting this way. The only exception is # of users – because new hires are budgeted.

Bottom line, in my opinion: Pure pay-for-use won’t work for most enterprises (some exceptions noted). The answer, in my opinion, is hybrid software licensing models:

1. Pay up front for some amount – for predictability
2. Pay in arrears for any over-use – for flexibility

With those types of pricing models, CIOs will start playing some very interesting “WHAT IF” analysis, such as “budget for 10% overage, how low can my upfront be.” CIOs will then have truly gotten rid of shelf-ware and Publishers will be fairly rewarded for their IP.

Check out these related pay-per-use and usage-based software licensing, pricing models and metrics blogs:

• Usage-Based Software Licensing Examples and Patterns
• Usage-Based Licensing without Usage Data – Is it Possible?
• The Next Evolution of Software Licensing: Monetization of Usage Data
• True Pay-As-You-Go Software Licensing Model – Myth or Reality?

In the 80s and 90s, the most common software licensing model was the concurrent/floating license model. What's not to love?

• Install software on any # of devices
• License server will prevent more than <purchased quantity> from using at any time

The theoretical advantage is that enterprises don't have to buy licenses for every user, only for peak # of users (most at any one time).

Seems like the perfect solution…right?

• Always in compliance
• Easy to administer

That may have been the case in the 80s and 90s, but for the last few years, we've seen a large decline in this preference. From 2010 to 2012 in the enterprise version of the Software Licensing and Pricing Survey that Flexera Software holds annually with IDC, when asked what licensing models enterprises preferred, the preference for concurrent licensing declined significantly year over year.

• 2010: 60% preferred
• 2011: 40% preferred
• 2012: 24% preferred

I believe there are several drivers for this:

• Enterprises are prioritizing availability over costs (and getting shelf-ware in the process)
• Determining "peak # of users" sounds easy, but:
  • Enterprises need to budget a year in advance, so they have to determine peak use way ahead of knowing new hires and new projects
  • If they are wrong, they might prevent some expensive resource (i.e. electrical engineer) from accomplishing a task and possibly missing deadlines etc.)
• Based on our review of many of our customer's log, they tend to over-buy, often quite significantly.  Our guess is 25-30% on average.
  • Some enterprises will want to reserve the licenses for particular projects or departments, because they are paying for those licenses This means that the story around "peak # of users" gets far more complex. It's "peak #" except that "Department #1" gets 10 of them and "Project #37" gets 30%.  This can be managed locally –but it's often a nightmare. We've seen "options" files (the mechanism for controlling allocation of licenses) with 100s if not 1000s of entries.
• Publishers are not providing good licenses – making analysis almost impossible. Examples of "bad behavior" includes:
  • Using same license version # from one product release to another
  • Often enterprises need to keep older versions of software for specific projects. By not providing version #s on their licenses, enterprises have to purchase "peak #" across all versions, making analysis quite difficult.
  • Using the same license feature across different products
  • Enterprises then have to guess which users will use which products and then estimate peak use of the feature

So what's better? According to the enterprises that completed the survey from 2010 to 2012 is a shift towards:

• Device/named user based (+20%)
• "Larger" meters –site, financial metrics, enterprise, etc.  (~10% - the question was not asked consistently  year over year)

What licensing models do you think will gain favor in 2013 and beyond?

Related articles

Application Producers Are From Mars - Enterprises Are From Venus?

Last time we discussed Why Salesforce.com Isn't Suited for Complex License and Entitlement Management Processes. In this post we will share why in our experience, mature software producers need several product, entitlement, license, machine and software delivery lifecycle processes – well beyond what can be reasonably built in Salesforce.com. While not exhaustive, these processes include (note that these processes apply to producer users, end customers and channel partners, which adds additional complexity):

Product lifecycle workflows

• Defining and managing product versions, with release and end-of-life (EOL) dates
• Managing "feature-clipped" editions of products
• Maintaining relationships between products (e.g. licensed product related to maintenance product)
• Defining and maintaining license models (e.g. trial, perpetual, term license/subscription)

Entitlement lifecycle workflows

• Supporting "try-before-you-buy" flows
• Renewal of maintenance entitlements
• Update notifications for software updates available for customers current on maintenance
• Partial renewals (e.g. Acme renews maintenance for 400 units out of 1000)
• Entitlement transfers within an enterprise (e.g. transferring 30 units from Acme San Jose to Acme Chicago)
• Identifying upsell (e.g. "Base" to "Premium") and cross-sell opportunities

License lifecycle workflows

• Fulfilling licenses from an entitlement. For example, Acme could fulfill 50 licenses initially and install them on a license server 1, 100 licenses on a different day on install them on license server 2 and so on, but can never exceed the 1000 units they bought
• Fulfilling licenses for online, offline and occasionally connected users
• Renewal of subscription licenses
• Enforcing licensing rules for version upgrades (e.g. do not allow more than 1000 units of EZ-Calculator to be fulfilled across all version)
• Auto-fulfill licenses for product versions that are available to customers on maintenance
• License transfers from one machine to another
• License returns

Machine lifecycle workflows

• Registering machines that contain licensed apps or license servers
• Displaying the application stack with associated licenses on a machine
• Viewing the licenses available on a license server machine
• Moving machines from one business unit to another
• Returning defective machines back to the manufacturer and processing credit for associated licenses

Electronic software delivery workflows

• Electronic software delivery based on entitlements (e.g. allow software downloads only for customers on maintenance)
• Managing files associated with a downloadable product
• Archiving EOL products and files
• Automated export compliance checks
• Reporting on software download activity

Entitlement management systems deliver on these processes. Ideally, they should co-exist with Salesforce.com; each system serving business processes they are good at and with appropriate data sharing between them. Salesforce.com is ideal for managing customers and sales opportunities, sales forecasting, support contracts and support entitlements. Entitlement management systems complement Salesforce.com by taking care of product, entitlement, license, machine and software delivery lifecycle workflows as defined above.

What do you think?

The terms "entitlements" and "entitlement management" are also used by customer relationship management (CRM) systems, notably Salesforce.com. Understandably, software producers we serve are confused: "Do we need entitlement management from Flexera Software? How is it different?" A prior post addresses a related topic on why enterprise resource planning (ERP) systems are not suitable for entitlement management. Quite simply, ERP systems are intended to maintain integrity of financial transactions and are not a great fit for entitlement management. In what follows, we demystify entitlement management in Salesforce.com and demonstrate that like ERP systems, Salesforce.com will require significant customizations to solve entitlement and license management use cases, as defined by Flexera Software.

Salesforce.com defines entitlements as: "Entitlements help you determine if your customers are eligible for customer support so you can create cases for them. A customer may be eligible for support based on a particular asset, account, or service contract. Here's an example of how support reps use entitlements:

1. A customer calls support.

2. A support rep searches for the caller's account, contact, asset, or service contract.

3. The rep verifies there's an active entitlement on the Entitlements related list.

4. The rep creates a case from the entitlement."

Entitlements, as defined by Flexera Software, refers to "a record of license use rights or rights to a service, as defined through agreements between a software user (or recipient of service) and a software producer (or service provider)". Our definition is geared towards software producers, unlike Salesforce.com's definition, which is oriented for hard goods manufacturers.

Let's say Acme buys an entitlement for 1000 units of EZ-Calculator Basic under a concurrent license model with maintenance expiring on December 31, 2013. By Flexera Software's definition, this gives Acme the rights to use no more than 1000 instances of EZ-Calculator Basic at any given time; they can use the product forever but the software maintenance expires on December 31, 2013.

To model what was sold to Acme in Salesforce.com, you would do the following (I only show fields that are relevant to this article – actual Salesforce.com implementations have a lot more fields):

• Create a Salesforce.com opportunity with the following line items:
  • PricebookEntryId = EZCalculatorBasic, Qty = 1000, => represents the licensed product
  • PricebookEntryId = EZCalculatorBasic Maintenance, Qty = 1 => represents the maintenance purchase 
     
• Create a Salesforce.com asset with
  • AssetId = EZcalcAssetId
  • AccountId = AcmeEnterpriseId
  • Product2Id = EZCalculatorBasic
  • Quantity = 1000
  • UsageEndDate = permanent

 The asset represents the licensed product that was sold to Acme.

• Create a Salesforce.com entitlement with
  • AccountId = AcmeEnterpriseId
  • End date = December 31, 2013
  • Type = "maintenance"
  • Service contract id = AcmeEnterpriseServiceContractId
  • AssetId = EZcalcAssetId

The entitlement tracks the maintenance rights associated with EZCalculator Basic.

You have to do all this manually but once this is set up, when Acme calls the producer, the producer's rep would be able to see that (a) Acme has a valid (or expired) maintenance plan and (b) Acme originally purchased 1000 units of EZ Calculator Basic. But that's about it. Out of the box, this is all you get with Salesforce.com.

The reality is, to run a software business you have to build a lot of custom workflows around the Salesforce.com entitlement and asset objects. In fact, a publisher I spoke with has built a custom maintenance renewal process by extending the product, asset and entitlement objects through Force.com custom fields and added a lot of custom code to process each opportunity in the "closed-won" state to:

• Create an asset automatically if product type = "licensed product" (Note: product type is a custom field on the Force.com product object)
• Create an entitlement of type "maintenance" automatically if product type = "maintenance"
• Create a renewal opportunity with a forecast close date one year in the future if product type = "maintenance"

They estimated that building just this one process in Salesforce.com took about 8 person-months of effort for the initial development plus additional effort to fine tune it as business needs changed. In addition, the IT team of this publisher had to become experts in renewal processes before they could even build such a custom application.

Next time—Why Publishers Need a Proven Commercial License and Entitlement Management System to Support the Full Software Lifecycle Process

Related articles

Application Producers Are From Mars - Enterprises Are From Venus?