Loyalty Truth

Editor’s note: The build versus buy decision is visited often by loyalty program sponsors. Jim Kuschill is the architect of one of the original – and still market leading – platforms in the industry. This is the Second in a several part series about loyalty software and it will be sure to fascinate loyalty junkies whether working for software vendors or internal IT teams.

In the first installment of this series, we saw that it was possible to decompose loyalty software systems into 23 separate major functional areas – 16 modules and 7 shared services.

In this installment we’ll take a look at how shared services impact modules and whether a developmental lineage can reasonably be established across a wide variety of loyalty software systems.

In general terms, modules interact with users while the shared services support the modules and interact with the operating environment (e.g. the database system). As a consequence, the capabilities provided by (and observable in) a system are largely dependent on the modules. But, how (well) those capabilities are provided is often highly dependant on the shared services. In particular, if a shared service does not exist, is poorly implemented, or minimally implemented, then the capabilities, reliability, or some other aspect of the system will be compromised.

Because shared services can affect large portions of a system, some correlation always exists between overall system flexibility and efficiency and the depth/quality of the shared services. However, if there was little correlation between shared services implementations, we’re again in a position where it would be difficult to show how investments would yield more cost-effective systems.

At this point, it was time to revisit each of the loyalty systems and identify whether they implemented a module or shared service, and if so, how. As this work progressed, it was possible to see patterns across systems that once appeared to have very little in common. Not only were there patterns, but there were also common approaches to the implementation of modules and services. Certainly not with 100% correlation, but with fundamentally similar approaches.

Upon a review of the results it also seemed as if there were 23 timelines, each illustrative of the lineage of a separate technology. In essence, each of the 23 timelines contained a version 1, a version 2, and so on. Each of the versions essentially indicated how “mature” the functionality of a module or shared service was.

This seemed a little too good to be true, so further research was done on the history of some of the systems. To do this, I spoke with developers and others who had insight into the modules and services of previous versions with any eye toward whether those versions fit the patterns identified. There was not 100% correlation, but the patterns were unmistakable, with well correlated progressions in every area.

Once the maturity levels were identified, it was then possible to consider the associated operational characteristics to understand the benefits, problems, and most importantly, the costs of operation for being at a specific maturity level. It was also possible to anticipate what more advanced maturity levels would look like, functionally and operationally, even if they had not yet been seen in a deployed system. Finally, it was possible to estimate the cost of enhancing a system from one maturity level to the next, a critical component of any ROI analysis.

Even with all of this, it was not yet possible to evaluate whether a particular loyalty system was inefficient at handling the job it was tasked to do. For that, it was necessary to understand the demands on the system, which requires us to consider such things as the vertical market, membership size, and program complexity.

By observation is was clear that each vertical market had a fairly distinctive pattern of needs and these tended to correlate with membership size and program age. This provided a baseline read but analysis of the following elements was especially useful:

• Reviewing the current software to identify its level of maturity
• Survey the loyalty program’s recent operating history for insight into the functions being performed and the associated costs
• Scan the strategic plan for the loyalty program (ideally a 2 or 3 year vision) to understand what maturity level of software is required to reliably and cost effectively implement the vision

The form of analysis yields a reasonably quantitative illustration of how well a loyalty system aligns with marketing realities and also where any gaps exist relative to the future marketing vision. Comparison of the gaps against the frequency of the needs and the cost of enhancement provides good insight into the areas into which investments should be made.

In Part III of this series, we’ll look at why a loyalty software maturity model is a necessary step and explain why being able to configure 95% of a solution is still not enough.

Stay tuned.