If your mission is to both reduce service costs and increase service revenue, you risk failing at both if you bundle them together. That is, if your customer chooses not to buy your offering, you have just eliminated your chance to reduce your own costs.

If you begin by “giving away” the portion that reduces your service cost, there are usually intrinsic benefits for the customer that gives them reason to allow you to install the service (get connected). And when I say, “give away”, I really mean to include in a service contract of some sort. The benefits necessary for the customer to allow you to connect is what we call the “minimum acceptance criteria” and is the basis of creating the value proposition when we work with clients launching a new service. Yes, you are giving away that value but it is the necessary trade off for your customer to allow you to connect. Any benefits you create that go beyond that “minimum acceptance criteria” should be reserved for a value added offering subsequent to getting connected to the install base.

If reducing service costs is not the priority (or you are beyond this and ready to sell a fee based service), then the approach is different. Assuming the offering is truly value add for the customer, then it is necessary to quantify the value of the offering and communicate that value in terms the customer can understand. Most companies screw this up and is often an area where we help.

Creating a value based pricing scheme is the best-in-class method here. The key to being successful with this is understanding your customer’s costs well enough to put a pricing mechanism together that your customer believes in - and you can prove it to them. There are of course many other challenges with value based pricing such as how to sell it. But it all starts with being able to calculate the value (real money) the service adds and then just negotiate how you are going to split it up.

This post hits right down into a discussion I recently had!

Your views above are without doubt valid and correct, but what if your focus of your base offering is on providing value internally as well as externally? And if an offering is free, does it (at least as perceived value) provide any value to the customer at all?

My rule of thumb: Free means no value! Switching from free to cost based is impossible!

From your experience; what different pricing scenarios are used by best-in-class implementers of remote services?

I actually know of one large company who states that their support fees are based upon the customer allowing remote support. The support contract states the vendor can apply a 30% surcharge if the customer fails to enable call home and remote access. (I don’t think they ever did though. Sales would have objected)

I find it interesting that customers do not seem to request a reduction in support fees when a vendor rolls out e-support. It seems this would have the same effect on lowering direct support costs as would remote support. I believe the reason for this is that e-supprt is less intrusive and requires virutally no customer resources to implement.

I like the Seeing Stones blog and your comments on customer engagement. I am completely aligned with the proposition that a fully engaged customer ( I refer to it as an empowered customer) will be less likely to ‘jump ship’

This is a position I have maintained when developing e-service solutions. While most support organizations veiw e-service as a mechanism to deflect calls and lower operational costs, I see e-service as a vehicle to empower the customer and make their use of your respective product critical to their business. Cost avoidance is an outcome of an effective e-service strategy and should not be the objective.

I realize this may be a bit off the remote service topic but the ojective of both is customer retention and the path to retention is though customer engagement/empoerment.

I understand your perspective; however, how the support and services groups are aligned from an organizational perspective should not raise barriers to collaboration between the teams. Each should be focused on maximizing the value they deliver to the customer. Granted their success criteria (margin dollars for PS or cost avoidance for support) may differ but customer loyalty is the end result for both groups.

My major point here is that as long as companies view remote capabilities as the domain of product support, it will not capture the ‘hearts and minds’ of the executives. There needs to be a linkage which demonstrates how these technologies can be applied to both organizations. For example, assume the PS organization used the remote support technology to deliver consulting services or performance and tuning services from a remote facility vs. being onsite. Now the technology is not just being leveraged for remote support; rather, it is viewed as a mechanism for remote services (Smart Services). This is a more compelling business case.

Value-added services are not intended to be a short term fix for revenue shortfalls, they need to be a component of an overall customer support and services strategy aimed at meeting customer needs. I can see where customers would get confused with a slew of new services being thrust at them.

I would also add that the role of the support organization should be expanded beyond break/fix efforts to problem prevention. To the extent that remote technology is an enabler, the greater the customer’s perceived value of the support effort overall. I understand this is dependent upon the company’s overall philosophy on the role of product support

The most interesting examples are ones where a company has been able to generate revenue from smart services. Cost avoidance is great, but nothing gets budget approval like increasing the top line.

- Security is a convenient excuse both for an end user who doesn’t see the value and an OEM who hasn’t really figured out that this is a product that must benefit the end user, not just the OEM’s service department. That isn’t to say that security concerns aren’t real. They are real and legitimate, but given the right value proposition it is extremely rare that they can’t be overcome.

- While I wouldn’t say things are plug and play since there are always integration issues with the device software (and any technology vendor that says there isn’t is either dreaming or lying), the technology works and next generation connectivity models will make it even better. The biggest problem is in applying technology for technology’s sake and not understanding what the users (both internal and external) of the system really want/need. Or even worse, being locked in to a vendor’s view of what applications your end users and customers want/need.

- Finally, the biggest single hurdle is OEMs lack of understanding that delivering value added services (not just customer support) through the device is one of the best paths to revenue growth. As one reinforcing example, take a look at Michael Treacy’s book on Double Digit Growth(http://www.amazon.com/exec/obidos/ASIN/1591840058). He lists 5 strategies for growth:
Maintain Your Base
Gain Market Share
Find Market Growth Areas
Attack Adjacent Markets
Enter New Businesses

I’d submit that a good connected device strategy can be used to address 4 out of those 5. I think the task for all of us in this space is to get the folks in the executive suite to make that mind/body connection between revenue growth and value added services enabled by the device connection.

Let’s say they do that. Why is remote services still so hard? Because of end customer IT security concerns. If companies don’t promote the business value of their solution, and the trust value of their existing relationship, it is too easy for IT to just say no.

Yet it can be overcome. Look at Microsoft Windows updates or any of the anti-virus vendors. They deliver remote services to millions of computers every day. Why? Because people want the value that these services provide.

Creating customers doesn’t always mean increase profits. Your example above of expanding the scope of the product is a great example of how thinking has to evolve as it gets harder and harder to make margin just by “shipping boxes.”

Tightly coupled with this is that any remote service system (both the code on the embedded system and the host system at the factory) have to go through a product development cycle as part of a regulated medical device. Given the tight R&D budgets and never ending connectivity product requirements, remote service rarely makes it above the threshold to get budgeted.

Finally, while providers want the benefits of remote service, they’re very particular about providing vendors with remote access to their products. This can - and has been - overcome, but not without hand wringing and additional costs.