Beyond the Checkbox - Part IV

Chris Tyler from Cognos will be joining us for a series of Blogs focused on driving performance for ISVs and OEMs. We will be publishing his Blogs on Thursdays for the next four weeks. Chris is a subject matter expert on getting his clients to elevate value to their customers.

This is the final part of this series. In Part III, we discussed the typical way vendors address their customers reporting needs, by simply checking the reporting box and delivering little or no value to their customers. Here will discuss a better way.

A Better Way - How to change the game

The customer should word their requirement “Do you have an analytical application which proves your application improves the performance of my organization as it relates to increasing our win rates by 7% year over year, reducing sales cycle times by 13%, and increasing our deal sizes by 5% year over year?” I’m sure the vendor would have a much tougher time checking that box, but, that is what the customer truly needs to know.

Figure 2 – An example of an analytic report which shows the business impact and provides context as to what it means to the business, what else to look for and what to do next.

Most enterprise purchases are fairly significant investments and the vendors are often very willing to present case studies where the return on investment, ROI, is achieved in, say, 14 months. Few vendors can actually prove it with their reporting solutions. If the vendor has gone through the process to measure the ROI and understand how it achieves the ROI, why not take that same thought process and put it into an Analytical Application that can be delivered? These types of analytical applications tend to increase customer satisfaction and stickiness, and become a significant, additional revenue stream.

What should the vendor be doing to deliver the value proof? How can the vendor go Beyond the Checkbox? Here are several ways. All of these should leverage and highlight the intellectual property and knowledge of the customer the vendor has.

Identify the value points

Identify 3-7 reasons why customers should buy your application. These become the value points which translate into metrics. These should be SMART (Specific, Measurable, Actionable, Realistic and Time-based).

Domain	Value Statements	SMART Metrics
CRM	Reduce sales cycle times Increase deal sizes Increase win rates Reduce cost of sales	Days to closure Average deal size growth Win/loss rates Cost of sales
Security	Reduce risk exposure Decrease intrusions Improve Data Governance and Compliance	# of threats identified/thwarted as it relates to system criticality and sensitivity % of critical systems adhering to corporate standards
Human Capital Management	Decrease attrition rates of high value employees Improve employee satisfaction Properly manage talent pool Increase successful recruiting rates	Attrition rates for top performers Employee satisfaction % of employees within 1-2 years of retirement Tenure / attrition rates of employees by recruiting source

Define the metrics

Build a business glossary to define the metric. This should contain what we refer to as the “What?, Why?, So What?, Now What?” This should be able to explain the intent of the metric. All metrics should relate somehow back to the value points identified earlier. If they don’t, there is typically no reason to track it.

Setting targets

The vendor should allow the customer to set targets for the various metrics and if applicable, any tolerances which may be acceptable. Comparing the actual values from the transactional data to the targets set by the customer, allows the user to see if they are on the right track to achieve their results.

Simplify taking action

There may be a need to share the content with another user, a user may want to comment on the performance, there may need to be some action plan set in motion to improve the performance, a user may want to subscribe to the content, or there may be a need to drill into the detail behind the metric.

Content should be in context

Content in context can imply that it is related to the logged in user or is specific to the current view within the vendor’s application. There are a variety of ways to accomplish this ranging from a tight API-level integration to a loosely-coupled web-based integration using URL’s, all depending on the capabilities of the vendor application.

About the author

Chris Tyler has been working for the past 4+ years with Independent Software Vendors (ISV’s) and Business Process Outsourcers (BPO’s) to help them address the specific needs of embedding BI into their platforms. He has seen some great successes and some dismal failures. Some commonalities with the successes are that the vendor delivering the application actually put some thought and intellectual property into their content. The failures typically did not.