Blog Post Version 8.4.2 Build 4519.pac: Service Pack 14: Winter Edition

If I were labeling my blog posts like software versions, I might call this post Version 8.4.2 Build 4519.pac: Service Pack 14. Or not.

Among the other standards we've not yet settled on in the software-as-a-service (SaaS) market, we haven't adopted a standard version naming convention.

For the folks in operations and customer support, there's a good reason to be precise in labeling. They need to know exactly which version of the application the customer is running. It's why the Apple Care tech needs to know that I'm running "Mac OS X 10.5.6." That's a bit more awkward than the "Tiger" nickname, but not nearly as cumbersome as "Microsoft Windows Version 5.1 Build 2600.xsp_sp3_gdr.080814-1236; Service Pack 3" that's running on my PC.

But don't let the needs of operations and customer support bind the hands of marketing when it comes to naming versions. As much as I argue that we marketers need to keep a sharp pencil and wear a green eyeshade when it comes to managing customer acquisition costs, part of our job is to generate interest in the solution and project its appeal and value. By that measure, "version 8.4.2 Build 4519.pac..." isn't really very shiny.

Go ahead and put the precise release identification information in the technical documentation and make it accessible to the system administrator, but there's no need to use it as the marketing moniker as well.

There are a few naming options that SaaS vendors are using. Some stick with the "release x.x." convention, carrying it over from the traditional on-premise model. It does have the advantage of being familiar to IT buyers, but if you're trying to convey that your SaaS offering is new, different, and better, using the old naming convention could be working against you.

Others are relying on the seasons, labeling versions "Summer '08" and "Winter '09." It certainly sounds appealing, like Sam Adams "Summer Ale" or "Winter Lager." It also provides a handy way to signal that they've just shipped a bunch of shiny new stuff. I especially like that it gives development a big window to actually deliver the enhancements. If you tell customers that the new feature will be available in the "Spring "09" release, they should expect it sometime between March and June. (Don't even ask what the seasonal labels mean for customers in the southern hemisphere!)

I've also seen variants of this seasonal naming scheme. There's "salesforce crm 9," for example. In fact, salesforce.com also labels new releases by season.

At the extreme end of the spectrum, some SaaS vendors have opted to forego version labeling entirely. They announce new enhancements, but don't use a "born on date" label at all. The customer's solution is being updated regularly. They always have the latest, the greatest, the freshest, the newest. That's what SaaS is all about, right?

Whichever naming convention you choose, I'd recommend you follow 3 rules:
  1. Free the marketing label from the operations and customer service nomenclature. They serve different purposes.
  2. Fit the naming scheme to the rest of your marketing and business strategy. If you're consciously breaking new ground and explicitly selling against the established on-premise vendors, why not go with an altogether non-traditional naming convention?
  3. Keep it simple. (That advice goes on most of my lists.)
As for me and the labeling of my blog posts, I think I'll stick with a headline and the date for now.