Archive for the ‘software’ Category
Last installment discussed organizing your content; free or fee.
This time, organizing your customers is the topic. Having a simple, and documented vision for how your customers will interact with your ESD system is a critical step in ensuring the long-term success of your program. The foundation of this vision is organizing customers into groups based on how you expect them to use the ESD system.
This is not a market segmentation exercise, per se. What we’re talking about here is use-models. From this perspective you can segment users along the same lines as your content; those who don’t know what they want, and those users who are coming to get what they are owed.
How many of your users will be browsing though your content library, undecided on what files they need or want?
How many are looking to get in and out of your ESD site, as fast as possible, with exactly what they already paid for?
Are your buyers and your users the same people? If not, how will the people who buy your content distribute those assets to the users?
Are the bulk of your users individuals (B2C type) or will you have multiple users per corporate account (typical B2B scenario)?
The only wrong answer in this process is to say “all of the above, equally”. That is a cop-out, and a sure path to disappointing results. Your ESD program needs a defined primary audience and user community. Pre-sales serving of free content, and post sales fulfillment of orders cater to different users at different stages in their relationship with your company. Decide which will be dominant.
Organize your ESD project around how your customers are categorized as they interact with your business. Trying to service every type of customer interaction equally, much like the keychain above, will to lead to a heavy ESD deployment and leave a big hole in your pocket.
Categorizing your content is the first patch of turf that will directly involve all of your internal Business, Engineering, Sales, and Marketing team members. Get them in a room and build a consensus view of the near future for this topic. You can always change and adjust your categories, but you have to start somewhere.
Begin by listing the files you are targeting for electronic distribution into two columns: Free and Paid.
Consider the Free assets. Will you allow anonymous access to those files? Will users be asked to register before being granted a download entitlement? Maybe both (optional registration)?
Segment the assets by license agreement type. Are their different terms for Free and Paid assets that must be agreed to before downloading? Are their different types of legal use agreements for assets within each category? Do you use third party or open source components that affect these terms?
Segment the assets by license enforcement technology (keys, time-out logic, dongles, etc.)
Decide if you will continue to support physical distribution, and if so, how the answer to that question affects the format of the assets you are delivering (.pkg vs .iso or .dmg, for example).
Fast-forward four to six months. Updates and patches are ready to ship for both Free and Paid assets. Will you provide incremental or full updates? Is there a difference if they are Free or Paid?
Things can get complicated in a hurry, especially if you happen to be in a company that has more than a handful of applications to deliver. But you’ve taken the step to address content categories early on, so never fear.
Let’s recap: Categorize your content
1. Free or Paid
2. Anonymous or Registered
3. Licensing Terms
4. License Enforcement Technologies
5. Physical Alternatives
6. Update / Patch Methods
Next installment – Categorizing your ESD Customer
Had a good conversation with the WSPGroup last week.
They published a whitepaper about Electronic Software Delivery a few months ago that is very detailed and worth a read.
Its our experience that these benefits require a huge scale (like the Microsoft case) to become a primary driver of transition to electronic delivery, but they are applicable at a small scale as complimentary ROI for other ESD initiatives.
So, take please take a look at the environmental advantages that you may be able to take credit for as you look at upgrading your software delivery practices to include ESD and entitlement management.
We had another discussion today on the differences between entitlement and enforcement in software licensing schemes.
Here is an image we have used to draw the distinction from our perspective.
We’ve developed our systems to enable publishers a high degree of control over the entitlement of software and technology. Preserving flexible entitlement choices for publishers eases some of the burden on downstream enforcement tools in a number of business scenarios.