I have recently been receiving pressure from certain vendors and CRM SIs to give more visibility to Open Source CRM products. Open source may be in fashion, but that's hardly a reason to recommend it.

Open source is not better. Yet. And I won't recommend it for enterprise size companies. Yet. And here's why.

Last week I had an inquiry from an SSPA member about how to handle customer emails regarding open support incidents. It turns out that the company is using an open source CRM package, and when an agent emails a customer about an open support incident, and the customer replies, the customer reply only posts into the open ticket if the email is from the contact who opened the ticket. If that person sends it to their system administrator for input, they go on vacation and someone else inherits the problem, or perhaps they escalate to their boss who then emails, the emails are opened as new support incidents.

Why? Unlike just about every customer support application on earth, instead of using XML embedded in the header record to route the email correctly, the open source product routes the email and posts it using the customer's email address. So if a different contact at the customer account replies, the email isn't recognized as related to the open case. And a duplicate case is opened. I have no idea what happens when a customer has 2 tickets open at the same time.

This irritates me because I worked for one of the very first customer support vendors 12 years ago, and even then, our product was smart enough to use a batch load process for inbound emails, validated by the incident ID in the email header. This basic logic is now in every packaged CRM suite.

I completely admit that there has been little or no advancement in case tracking/trouble ticketing in many years. This piece of CRM is totally a commodity. But, and this is the important part, it is a commodity that is the bedrock of every customer support organization in the world. While commodity software is perfect to recreate in open source, there should be a baseline of functionality that is assumed.

I have lobbied for years to get rid of RFPs listing hundreds, if not thousands, of functional line items. Companies spend months writing them. Vendors spend weeks responding to them. But functional laundry lists don't help you determine if a vendor's products will help you solve your business problems.

If moving to open source means having to make sure the software behaves according to normally accepted industry paradigms, RFPs will only get worse. Companies will have to be even more specific about how they expect applications to behave, or else receive some ugly surprises after implementation.

Call me a luddite. But there are too many avenues for excellent customer support software, many costing very little (check out FrontRange and Numara, for starters). And here's the best part: no surprises. And when it comes to enterprise software, no surprises should be a requirement.