Headline Feeds
"Opportunity computing" is a term that Danny Kolke, founder and CTO of Etelos, has coined -- or at least introduced into general use in the CRM community, thanks to his recent post, "Utility v. Opportunity."
A partner recently asked Kolke about Etelos' move into the utility computing business. "My immediate reaction was to stare at [him] in amazement," he wrote.
Etelos is in opportunity computing, not utility computing, he then told the partner.
"Utility computing" is gaining momentum as an accepted term in the industry and is sometimes used interchangeably with "cloud computing," Kolke noted. "The utility computing model gets you out of managing infrastructure elements like database clustering, bandwidth metering, failover, etc... It also allows you to scale as you go, paying incrementally for your usage. This is a great model, but is only part of what you need to be successful as a business."
Opportunity computing, by contrast -- at least as Kolke explains it -- seems to be more relevant to what is happening in the Software as a Service industry.
"The general premise is to take the concept of what utility computing has started and extend that into other services, best practices, APIs (application programming interfaces), and other enablers of computing," he told CRM Buyer.
However, there is a flip side to opportunity computing that developers should consider: Just because this wealth of resources makes it possible to build something -- should you?
To Build or Not
In an earlier blog post, Kolke gives five reasons for developing something in-house and six reasons for going to market for the functionality instead.
Yes, the build-versus-buy debate that has been around for a while, but Kolke's point is spot on: Thanks to vendors' growing propensity to release code, companies should be selective when designating which projects will get development resources.
"One value of the Web as a platform is that you can best practice a lot of services that aren't competitive to your own business," he says. A functional billing, for instance, doesn't particularly excite an audience, "but if that billing system isn't working it totally consumes your organization."
The Virtues of Measuring
As a consultant paid to produce measurable results, Paul Greenberg gave readers a delightful exegesis of just where on the spectrum of useful business practices this sometimes falls in
CRM, Philosophy, Baseball & Universal Metaphors." After praising an article he had just read on
experimental marketing, Greenberg objected to one particular finding cited in the article -- namely that 79 percent of people surveyed by the Jack Morton marketing 
organization said that a key obstacle was measuring/demonstrating experiential marketing ROI, or return on investment.
"Even though I GET the idea that people need to account for investments in a business in some way, what just drives-me-up-a-wall sometimes is that it ALWAYS has to have some tangible NUMBER associated with it. I GET IT! NUMBERS ARE IMPORTANT FOR BUSINESSES AND THEY ARE A USEFUL GAUGE FOR RELATIVE SUCCESS OR FAILURE. I GET IT! But, know what? That isn't ALWAYS the best measure," Greenberg fumes.
Don't believe it? Then take Greenberg's 60 second pop quiz:
"Tell me about something that you LOVE? About something that you LIKE A LOT but don't LOVE? About something that you LIKE but maybe not A LOT nor do you LOVE it?
"On the opposite side of the coin, can you tell me about something that you HATE? DISLIKE? SORTA DISLIKE? Don't care about either way? I'll bet you with some thought that you could say yes to all of them. Conversely, can you tell me what the actual degree of difference in love, like, hate, etc. is on a scale of 1 to 10? What is the difference between 3 and 4 or 5.6 and 5.9? Does it matter as much as the above? Maybe to your business, but the numbers are not the way humans work."
In other words, ROI isn't always a specific metric.
Blogging About It
Two executives from Sage -- David van Toor, general manager for Sage CRM solutions for North America, and Larry Ritter, SVP of global product management -- launched corporate blogs last month that wouldn't, they promised, be scripted by marketing.
I'm guessing they meant it. In a recent post, van Toor asked for "examples of less than desirable experiences" Sage customers have encountered.
"There were three key themes that came up in these replies (and in other posts): breakdown in the automated generation of license keys following on line purchases; being bounced from person to person in service or support and having to repeat details; [and] apparent complexity of the product causing implementation issues," van Toor reported.
One sample response: "About a month ago I downloaded the trial version of version 2008. I decided today to go ahead and purchase ver 2008. I purchased the downloadable version, as well as the CD and the extended right to download again for 2 years. I probably didn't need both, but I wanted all my options. The download went as expected and everything seemed to working as planned until I tried to start my new version of ACT. It appears I needed to register, so I called the number provided to register and that's where my nightmare started. I was transfered to between 5 and 7 different people."
Van Toor
responded to the customer saying he'd be using the post "as an example of where our processes can break as we research how to prevent a similar issue occurring again."
Talkback: 
