How do you create compelling value on top of something that is no longer a problem people will pay to solve?

Long title but it gets the point across – how do you stay commercially viable when your offering is not something people are willing to recognize as a problem worth paying you to solve?

I’ve been on record stating that I believe the SPAM / Virus filtering is something that is rapidly losing value and will be free. Later this year we will be launching a barebones antispam/antivirus cloud solution that is a fraction of the cost of whats currently out there and aim at making it free eventually.

The response of the security vendors has been to nickel and dime the client base because there is still a lot of value in filtering and lots of money can be made on the things like encryption, web filtering, etc. Our response has been to eliminate wasteful resources and reallocate them to those features that the users are actually willing to pay for. Here is a concern one of our partners voiced in our portal:

During these financially stressed times, it gets harder and harder to provide justification to a customer on why they should spend the slightest penny on anything. With that said, after the upgrade to ED5 and the induction of “SMTP Tempfail,” the numbers of SPAM messages being filtered out by ED servers and listed in our customer’s daily reports has dropped dramatically. This is great for both OwnWebNow, by reducing the loads on the ED servers, and our customers, for having to filter through less junk in their ED quarantines and daily reports. But the unintended result is that we, as OWN partners, find it harder to justify to the customer why they need to have or maintain the ED service. The reason being is that the numbers on the Domain Security and the SPAM Trend Reports have dropped dramatically. These reports gave us the numbers and graphical proof that our customers needed to wrap their minds around to see the service working and made it easier on us to justify the need for the ED service. The feature request in all of this: Even if the message is dropped via the SMTP Tempfail, couldn’t those messages be counted, and listed on the reports, as being filtered in the total number of messages for that domain? Or maybe adding a section within the report for the SMTP Tempfail that list the number of messaged dropped.

Here is my response:

Dear Steven & Nathan,

Unfortunately, the tempfail is something that is issued during the SMTP transaction and we do not know the destination of the email – it could be heading to any email address or domain on the network. Logging that information is not just pointless, it would only require more resources and cause users to be even more unhappy with the service and the amount of junk they are dealing with.

I will tell you both that this is not the first time I’ve had to answer this question.

I will also admit that I share your concern, however, I have chosen to address it in a different way.

I can’t build a company on top of a fear for something that the technology has already addressed. That is to say, I can’t sell a solution to a problem that has already been largely solved that shouldn’t have existed in the first place.

Now, how do you create a compelling value offering considering that the original problem is already a component of the solution? Grow the solution. Add web filtering. Add business continuity. Add encryption. Add large file web sharing. Add it all for free.
That’s been my answer. Honestly, if a user is so unaware of the widespread SPAM problem that keeps on growing year over year, and all it takes to aleviate their fear is a chart, we’re not really dealing with sophisticated people. The kind that will likely not place value on the rest of the stuff we do either. So I can’t address them.
However, I can grow the sophistication and the value in my product by giving them more security, not just the illusion of it.

Please feel free to email me at vlad@ownwebnow.com, I don’t want to be insensitive to your concerns Steven because I’ve had to answer them and the above is what we came up when it came to the product design. I hope it also helps you in your discussions with your clients and gives a better footing for your managed services solutions because this goes hand in hand with the total solution.
-Vlad

There is a larger question here that the managed services providers have to answer to remain in business and address the pricing pressures from the big boys. I’ve been doing a series of “cloud” presentations with MSPU trying to explain to people all the vectors that need to be considered here because the truth is: When you are paid to solve the problem, and you solve it, the client no longer experiences the pain and their willingness to pay for it diminishes the further they are removed from the problem.

Basically, there is a diminishing value of providing managed services. Response? “Screw them, if I stop doing what I do for a day their network will explode.” Ok, guess that would work but I don’t know that it’s great customer service. From experience, bunch of charts and graphs isolating the problem don’t work either – When you are not directly experiencing a pain, charts and data points do not have an emotional impact which makes the client wonder why they shouldn’t consider an alternative (cheaper) solution.

Now, I think I wrote a blog post or two about commoditization of services 😉 Remember, it’s too late to think about this stuff after you’ve lost a client. You need to do it now because I can guarantee you they are being bombarded with alternatives. You can’t call me a day after Microsoft swiped your client and you want to get into Hosted Exchange business but you never introduced it to your clients before because you’re a LAN guy. You have to be faster, better informed, less biased than Google, Microsoft or _____.

Bottom line is: Ignorance As A Service doesn’t work. And as painful as it may be, we need to approach our clients with different set of collateral and value propositions than we did in the past. What that entails and how effective it is going to be is a matter of trial and error.