I have a pet peeve concerning two things I’ve been meaning to write about lately, namely CRM and multi-tenancy. I recently read an excellent article referencing both concepts and thought itmight be a good stepping stone to a quick blog post.

In his article Don’t Get Conned – The many disguises worn by software-as-a-service, Matt Wallach discusses CRM software and the concept of SaaS multi-tenancy. Matt’s business is life sciences, and he discusses the state of CRM software for his industry. His argument is along the lines of “be wary of on-premise wolves in SaaS sheep clothing”. The wolves, in this case, areon-premise CRM vendors who simply throw servers over a wall and call it a SaaSday. The sheep (aka the good guys) are those genuine SaaS vendors riding a multi-tenant architecture. He then proceeds to define what multi-tenancy means using the well-known “neighborhood versus apartment” analogy. Sounds innocuous enough (and the piece is well-written) but here’s the problem I have.

I am going to get a lot of heat for this statement but, truth be told, CRM is a hoax. There is no such thing as CRM. It’s all smoke and mirrors, and you cannot nurture customer relationships (or any other form of relationship) using a bunch of bits. It’s a cop-out. I know of CRM market segments and sizes. I am well aware of CRM dissemination and popularity in corporate America. I don’t question its omnipresence in virtually all businesses in one form or another. My claim, however, is that it does not and cannot work as billed. In numerous cases, it is simply a waste of “feel-good”money. Here’s why.

The companies and industries making the most use of CRM packages are those with the worst customer service. This in itself should be eye-opening. Airlines are perfect examples. Can anyone think of an industry with worse customer service? I can’t. Yet they spend gazillions on CRM and boast about it frequently. How about retail? When’s the last time these guys used CRM to do anything besides manage their “rewards programs” (who are they rewarding please tell me?) or push advertizing gimmicks? How about Telecoms? How many people are happy with their cell carriers in the US? When was the last time your interaction with a carrier’s customer service department was either useful, efficient, or pleasant? How about the automobile industry or even car rental outfits? When was the last time you were wowed by one of those big corporate CRM consumers?

Now, I’m not saying all companies who use CRM manage customers poorly. Some do get lucky. And others use it as a tool, not a means to an end, which is perfectly fine. What I am pointing out is that customer service quality seems inversely proportional to the resources spent on CRM at the corporate level. And that’s ironic. The problem is in the C-suite. These folks see CRM as a panacea but inherently, deep down, these people do not have customer service “genes”. They have Board of Directors genes, profit margin genes, or MBA ones, but they don’t know the first thing about worshipping customers – It’s a form of autism on their part.

Because in my experience, customer service is not something you can learn on the fly (although I suspect it is taught in business schools). And it’s not something you can acquire via software. Companies, like people, are either born with it or not. It’s a nature not a nurture trait. And no amount of software or resources will change the behavior of a company whose culture isn’t obsessively centered on the customer. It sounds obvious, and everyone talks about it, but most of the time, it’s nothing more than lip service. It’s a sham I tell you.

Luckily, the solution is simple: throw the software out the window. Really, honestly, you don’t need it. You can’t even prove you need it anyway. Most of the time, you don’t know how to interpret or filter the results. And worse yet, you have too much information. You get overloaded with it in a drunken stupor and it ends up clouding your judgment. And shortly thereafter, you throw common sense out the window. Malcom Gladwell makes excellent anecdotal arguments against information overload in Blink, one of his classics. It’s a fascinating read(specifically I refer to section 4 of chapter 4). CRM and software overload have the same effect on corporate management as those described by Gladwell affecting ER doctors’ decision making. Too much information leads to disastrous results.

I’m not suggesting the demise of customer or performance managementsoftware as a whole obviously. Keep the databases, the warehouses and the BI in-house (because analysis and insight arestill obviously crucial) but take your big honking CRM software and pull the plug. You will likely learn more (and spend a whole lot less) by talking to yourfive top customers. If you want to stay in control and get 360 customer views,sign up for something like TeamSupport – it’s all you need. Most importantly, dosomething truly revolutionary: get out of the building and walk a mile in yourcustomers’ shoes.

Order your own product, fly your own airline (in coach), rent your own cars, dial your customer service numbers repeatedly – from a roaming zone, for example – visit your retail stores (incognito) and talk to your customers. Order your own food, visit your own bathrooms, wear your own clothes. Engage customers one on one, on the streets, in the stores, at their home, face to face, and listen like you mean it. Listen like your life (and job) depended on it – because it does. You cannot manage customer relationships from a spreadsheet or a SQL query any more than you can steer a marriage successfully via the web (yes Iknow, there’s probably an iPhone app for that). It’s that simple. Your fancy CRM system is the blue pill. Take the red one!

So now, having sufficiently ticked off everyone in the CRM industry, let me tackle the SaaS “badge of honor” also known as multi-tenancy. Here’sa reality check: no one really knows what multi-tenancy means. How do I know this? Because if you ask three people what it means you will get five different answers. And when you search for it online, you get multiple descriptions, some more convincing than others. So unless I missed something, there is no official definition, only qualified opinions.

To me, the gist of it involves partitioning software application space very quickly and cheaply to accommodate exponential massmarket adoption cycles (there’s a mouthful). Exactly how you achieve this, from a technical perspective, is open to interpretation. Some people partition inside the database and share schemas (like Salesforce.com, where every tenant shares database tables), others partition on the application layer where processes may serve multiple requests, some consider virtualization to be a form of multi-tenancy, and yet others implement a hybrid approach.

At the end of the day, multi-tenancy is a design methodology. Multi-tenancy (however you implement it) allows faithful cloud landlords to follow basic rules. If Moses had come down from “The Cloud” instead of Mount Sinai, he might have brought these back instead:

(1) You shall provision tenants quickly without affecting other parts of the system.

(2) You shall be able to provide deterministic system metrics on a 24/7 basis.

(3) You shall let non-technical staff (or software) handle provisioning.

(4) You shall monitor your platform’s health day and night.

(5) You shall implement and frequently simulate doomsday scenarios.

(6) You shall make it as easy to provision one tenant as it is for one hundred.

(7) You shall segregate and protect thy tenant’s data at all cost.

(8) You shall upgrade transparently and automatically for all tenants.

(9) You shall allow tenants some degree of customization but not more.

(10) You shall have a simple, clear and consistent pricing model.

In my opinion, what goes on behind the scenes to supportthis is irrelevant because it’s irrelevant to the user. The user just wants to be “on-boarded” and provisioned pronto and safely without hassle. If you happen to be able to pull this off technically and cost-effectively, then you’re multi-tenant! If not, you have some pain coming your way.

Whether or not you can support thousands of tenants perinstance (however you define “instance”) is, for all intents and purposes, really your problem, not the user’s. And I have yet to meet a prospect who’s first and foremost concern involves “multi-tenancy”.

This might suggest we cease using the term as a marketing asset because I don’t think it resonates clearly. In my experience, the only things that matter to a cloud user are simplicity, service levels, trust, and cost. So let’s give users exactly what matters to them,explain it simply, and keep it real.

Yours in BI.