Let's talk about a conventional software business model: We build it, you buy it (license model). Think of Microsoft Word. Do you think Bill Gates worries about how many documents you write with it after you buy it, whether or not you use Mail-Merge, or running headers? Not really, he's got your money, and to get more of it, he essentially has to offer more features and sell you an upgrade.
Let's say that Microsoft changed its business model for Word, and instead of buying a license that lasted forever and installing the software on your personal computer, you accessed a hosted version through your browser (can you say Google docs?) and did one of the following:
- paid a monthly fee based on the number of features you were signed up for (feature-based pricing)
- paid by the number of documents you saved (transaction-based pricing)
When I was a UX designer for CheckFree, we had a similar situation. CheckFree is a bill pay application for Web banking and they get a cha-ching every time someone pays a bill online. Do they care if you pay one bill or ten bills a month? Darn-tootin' they do!
(me saying "darn tootin'")
I think the role of user assistance changes dramatically when you shift to a usage fee-based model and becomes one aimed more at sustained or progressive user adoption. That means that documentation needs to emphasize the use and value of contracted features so that users renew those features (sustained adoption) or points out opportunities where the user could benefit from unused features or increased use of pay-as-you-play features (progressive adoption). See my article Fattening the long tail through progressive user adoption to see how we applied user assistance in that strategy at CheckFree.
As more products go to a SaaS or transaction-based model, think how user assistance can improve feature renewal or adoption. Because in this economy, I'd much rather calculate my value add as part of a revenue stream.
4 comments:
I'd be a lot more inclined to treat the author as credible if he had not misrepresented the corporate name of Microsoft not once, but multiple times. It's "Microsoft," not "MicroSoft."
Thanks, Anonymous, for the catch. I've made the corrections.
But why do some technical communicators have to be so mean about comments like this? I didn't "misrepresent" anything; I mis-capitalized a word (twice). It was a mistake, not a misrepresentation. And how does that mistake affect the credibility of the content?
Secondly, it's a blog; a less formal, more spontaneous way of communicating ideas to a community. When we start nit-picking small things like this and discounting the ideas that are being shared, we put a chill on what should be an open and collaborative medium.
And I'd be a lot more inclined to respect the comments of someone when they put their name to the comment, as I put my name to my ideas, and not hide behind "anonymous."
I apologize in advance if there are any errors in this comment.
There are two other SaaS fee models that I'd be interested in your thoughts on, in terms of what the UA goal should be: charging purely by seats and charging purely by bandwidth. In our case, we *do* license by 3 feature streams, but I think it's unlikely we'll see many customers divvying them up; I think it'll be all or nothing.
So is there anything UA can do (other than the usual ease-of-use/lower TCO*) to assist w/ expanding the number of seats a customer wants to direct to the service? In terms of bandwidth, some SaaS vendors may charge by teh amount of traffic customers are putting through the service. Anything we can help with there?
*Will TCO morph into TCS? (subscribing)
TCS--cool!
I think charging by the seat is essentially the same model as licensing, even though it is SaaS. I don't see how UA would change. Not to say that if you think your UA sux for licensing you shouldn't improve it :-)
Same for bandwidth pricing except that I might tone down multimedia UA elements on lower bandwidth versions. (Or include them so the lower bandwidth experience is an unpleasant one--just kidding)
Good questions, maybe others will have more insightful comments than I was able to offer.
Post a Comment