Editor’s note: The build versus buy decision is visited often by loyalty program sponsors.  Formal market studies by COLLOQUY and others have arrived at the conclusion that “internal IT” might be the market share leader among loyalty software providers.  Jim Kuschill is the architect of one of the original – and still market leading – platforms in the industry. He has been asked every question about loyalty software that could be asked and is so well versed that, if you bore him, he’ll go ahead and answer the questions you forgot to ask! This is the first 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.

I’ve spent a lot of time over the years studying loyalty system technology. This includes the consumer touch points such as the web site and IVR, the data touch points that drive accruals and perform fulfillment, and everything between.

At first, second, and third blush, each of the systems looked very different, the only thing in common seeming to be that they all cost too much to operate and never really seemed able to (easily) do what marketing wanted. As a result, I started to wonder if there really weren’t patterns, whether it would be possible to identify and make some sense of them, and if there might not be substantial benefits in teasing them out. In particular, I wanted to see if there might be a way to understand how loyalty systems “grew up,” to be able to predict operating capabilities and costs, and then to leverage this knowledge into more flexible and efficient systems, but most of all, into more cost-effective systems.

An interesting truism relative to loyalty processing software is that they seem alluringly simple to build. After all, tracking points is merely a matter of addition and subtraction and tracking names and addresses is pretty basic functionality as well.  I would go so far as to say that if you sat down with 100 bright software analysts or software engineers that had not previously worked with loyalty systems, fully 90% of them would confirm they could build just what you needed!

While this isn’t a good thing for loyalty software vendors and ultimately it isn’t a good thing for those that operate programs, it turned out to be a really good thing for my analysis. Partly because so many different systems existed and partly because it was easy to see that the vast majority of loyalty software systems started with pretty much the same kernel – typically a little member management, a little points accrual, and a little redemption support.

Then they grew.

And new parts were added.

And they grew some more.

And then parts had to be rewritten.

And those parts started to grow.

This approach to development appears haphazard, but it is actually driven by market forces that influence the needs of the marketer. This in turn drives the software requirements and ultimately the form of the software. Given that market requirements, particularly in the same vertical, will in large part be similar, it’s not unreasonable to assume that the solutions within a vertical will exhibit a good deal of consistency as well. That is, every loyalty system within a vertical should provide similar core functions, albeit perhaps in different ways and to a different degree.

A subsequent comparison between several systems within a number of different verticals confirmed that functionality wasn’t highly variable, but it did not immediately yield insights into the operational cost drivers, much less how such costs might be reduced. This was somewhat of a disappointment, but should not have been unexpected. To some extent I had fallen into the “loyalty systems are simple” trap by trying to categorize at too high a level.

At this point, some functional decomposition was in order and so I took inventory of the major functions performed by loyalty systems. For example, point expiration is a common major function. Similarly, and much more complex, redemption is an obvious “must-have” function. People often refer to these as modules, that is, the points expiration module, the redemption module, and so on.

While modules are readily identifiable, loyalty (and other) systems generally include a large amount of supporting code. In terms of software design, this code is often identified as “shared services” or “service modules”, because the functions are needed (shared) by a number of different modules. For example, handling batch files, logging of data changes, and so on, are typical of shared services.

After a re-review of the systems with an eye towards functional decomposition, 16 major modules and 7 major shared services were identified. Of the 16 modules, 4 were large enough that they could have undergone a similar decomposition process, but rather than complicate the process further, this was simply noted, with an expectation that any findings may not be quite as applicable for these modules.

Now it seemed that some progress was being made as it was possible to break down the formerly monolithic systems into a manageable number of readily identifiable parts. The next interesting question was whether there was a discernable “lineage” associated with the parts. Without a lineage, without correlation, it would be much more difficult to show what type of investments would yield more cost-effective systems.

In our next installment we’ll review each loyalty system against the identified modules and shared services and see if  clear relationships exist between investment in specific sets of modules and more cost-effective loyalty marketing systems.