Showing posts with label data integration. Show all posts
Showing posts with label data integration. Show all posts

0 eglue Links Data to Improve Customer Interactions

Let me tell you a story.

For years, United Parcel Service refused to invest in the tracking systems and other technologies that made Federal Express a preferred carrier for many small package shippers. It wasn’t that the people at UPS were stupid: to the contrary, they had built such incredibly efficient manual systems that they could never see how automated systems would generate enough added value to cover their cost. Then, finally, some studies came out the other way. Overnight, UPS expanded its IT department from 300 people to 3,000 people (these may not be the exact numbers). Today, UPS technology is every bit as good as its rivals’ and the company is more dominant in its industry than ever.

The point of this story—well, one point anyway—is that innovations which look sensible to outsiders often don’t get adopted because they don’t add enough value to an already well-run organization. (I could take this a step further to suggest that once the added value does exceed costs, a “tipping point” is reached and adoption rates will soar. Unfortunately, I haven’t seen this in reality. Nice theory, though.)

This brings us to eglue, which offers “real time interaction management” (my term, not theirs): that is, it helps call center agents, Web sites and other customer-facing systems to offer the right treatment at each point during an interaction. The concept has been around for years and has consistently demonstrated substantial value. But adoption rates have been perplexingly low.

We’ll get back to adoption rates later, although I should probably note right here that eglue has doubled its business for each of the past three years. First, let’s take a closer look at the product itself.

To repeat, the basic function of eglue is making recommendations during real time interactions. Specifically, the system adds this capability to existing applications with a minimum of integration effort. Indeed, being “minimally invasive” (their term) is a major selling point, and does address one of the significant barriers to adopting interaction management systems. Eglue can use standard database queries or Web services calls to capture interaction data. But its special approach is what it calls “GUI monitoring”—reading data from the user interface without any deeper connection to the underlying systems. Back in the day, we used to call this “screen scraping”, although I assume eglue’s approach is much more sophisticated.

As eglue captures information about an on-going interaction, it applies rules and scoring models to decide what to recommend. These rules are set up by business users, taking advantage of data connections prepared in advance by technical staff. This is as it should be: business users should not need IT assistance to make day-to-day rule changes.

On the other hand, a sophisticated business environment involves lots of possible business rules, and business users only have so much time or capacity to understand all the interconnections. Eglue is a bit limited here: unlike some other interaction management systems, it does not automatically generate recommended rules or update its scoring models as data is received.

This may or may not be a weakness. How much automation makes sense is a topic of heated debate among people who care about such things. User-generated rules are more reliable than unsupervised automation, but they also take more effort and can’t react immediately to changes in customer behavior. I personally feel eglue’s heavy reliance on rules is a disadvantage, though a minor one. eglue does provide a number of prebuilt applications for specific tasks, so clients need not build their own rules from scratch.

What impressed me more about eglue was that its rules can take into account not only the customer’s own behavior, both during and before the interaction, but also the local context (e.g., the current workload and wait times at the call center) and the individual agent on the other end of the phone. Thus, agents with a history of doing well at selling a particular product are provided more recommendations for that product. Or the system could restrict recommendations for complex products to experienced agents who are capable of handling them. eglue rules can also alert supervisors about relationships between agents and interactions. For example, it might tell a supervisor when a high value customer is talking to an inexperienced agent, so she can listen and intervene if necessary.

The interface for presenting the recommendations is also quite appealing. Recommendations appear as pop-ups on the user’s screen, which makes them stand out nicely. More important, they provide a useful range of information: the recommendation itself, selling points (which can be tailored to the customer and agent), a mechanism to capture feedback (was the recommended offer presented to the customer? Did she accept or reject it?), and links to additional information such as product features. There is an option to copy information into another application—for example, saving the effort to type a customer’s name or account information into an order processing system. As anyone who has had to repeat their phone number three times during the course of a simple transaction can attest—and that would be all of us—that feature alone is worth the price of admission. The pop-up can also show the business rule that triggered a recommendation and the data that rule is using.

As each interaction progresses, eglue automatically captures information about the offers it has recommended and customer response. This information can be used in reports, applied to model development, and added to customer profiles to guide future recommendations. It can also be fed back into other corporate systems.

The price for all this is not insignificant. Eglue costs about $1,000 to $1,200 per seat, depending on the details. However, this is probably in line with competitors like Chordiant, Pegasystems, and Portrait Software. eglue targets call centers with 250 to 300 seats; indeed, its 30+ clients are all Fortune 1000 firms. Its largest installation has 20,000 seats. The company’s “GUI monitoring” approach to integration and prebuilt applications allow it to complete an implementation in a relatively speedy 8 to 12 weeks.

This brings us back, in admittedly roundabout fashion, to the original question: why don’t more companies use this technology? The benefits are well documented—one eglue case study showed a 27% increase in revenue per call at Key Bank, and every other vendor has similar stories. The cost is reasonable and implementation gets easier all the time. But although eglue and its competitors have survived and grown on a small scale, this class of software is still far from ubiquitous.

My usual theory is lack of interest by call center managers: they don’t see revenue generation as their first priority, even though they may be expected to do some of it. But eglue and its competitors can be used for training, compliance and other applications that are closer to a call center manager’s heart. There is always the issue of data integration, but that keeps getting easier as newer technologies are deployed, and it doesn’t take much data to generate effective recommendations. Another theory, echoing the UPS story, is that existing call center applications have enough built-in capabilities to make investment in a specialized recommendation system uneconomic. I’m guessing that answer may be the right one.

But I’ll leave the last word to Hovav Lapidot, eglue’s Vice President of Product Marketing and a six-year company veteran. His explanation was that the move to overseas outsourced call centers over the past decade reflected a narrow focus on cost reduction. Neither the corporate managers doing the outsourcing nor the vendors competing on price were willing to pay more for the revenue-generation capabilities of interaction management systems. But Lapidot says this has been changing: some companies are bringing work back from overseas in the face of customer unhappiness, and managers are showing more interest in the potential value of inbound interactions.

The ultimate impact of interaction management software is to create a better experience for customers like you and me. So let’s all hope he’s right.

0 Low Cost CDI from Infosolve, Pentaho and StrikeIron

As I’ve mentioned in a couple of previous posts, QlikView doesn’t have the built-in matching functions needed for customer data integration (CDI). This has left me looking for other ways to provide that service, preferably at a low cost. The problem is that the major CDI products like Harte-Hanks Trillium, DataMentors DataFuse and SAS DataFlux are fairly expensive.

One intriguing alternative is Infosolve Technologies. Looking at the Infosolve Web site, it’s clear they offer something relevant, since two flagship products are ‘OpenDQ’ and ‘OpenCDI’ and their tag line is ‘The Power of Zero Based Data Solutions’. But I couldn't figure out exactly what they were selling since they stress that there are ‘never any licenses, hardware requirements or term contracts’. So I broke down and asked them.

It turns out that Infosolve is a consulting firm that uses free open source technology, specifically the Pentaho platform for data integration and business intelligence. A Certified Development partner of Pentaho, Infosolve has developed its own data quality and CDI components on the platform and simply sells the consulting needed to deploy it. Interesting.

Infosolve Vice President Subbu Manchiraju and Director of Alliances Richard Romanik spent some time going over the details and gave me a brief demonstration of the platform. Basically, Pentaho lets users build graphical workflows that link components for data extracts, transformation, profiling, matching, enhancement, and reporting. It looked every bit as good as similar commercial products.

Two particular points were worth noting:

- the actual matching approach itself seems acceptable. Users build rules that specify which fields to compare, the methods used to measure similarity, and similarity scores required for each field. This is less sophisticated than the best commercial products, but field comparisons are probably adequate for most situations. Although setting up and tuning such rules can be time-consuming, Infosolve told me they can build a typical set of match routines in about half a day. More experienced or adventurous users could even do it for themselves; the user interface makes the mechanics very simple. A half-day of consulting might cost $1,000, which is not bad at all when you consider that the software itself is free. The price for a full implementation would be higher since it would involve additional consulting to set up data extracts, standardization, enhancement and other processes, but cost should still be very reasonable. You’d probably need as much consulting with other CDI systems where you'd pay for the software too.

- data verification and enhancement is done by calls to StrikeIron, which provides a slew of on-demand data services. StrikeIron is worth knowing about in its own right: it lets users access Web services including global address verification and corrections; consumer and business data lookups using D&B and Gale Group data; telephone verification, appends and reverse appends; geocoding and distance calculations; Mapquest mapping and directions; name/address parsing; sales tax lookups; local weather forecasts; securities prices; real-time fraud detection; and message delivery for text (SMS) and voice (IVR). Everything is priced on a per use basis. This opens up all sorts of interesting possibilities.

The Infosolve software can be installed on any platform that can run Java, which is just about everything. Users can also run it within the Sun Grid utility network, which has a pay-as-you-go business model of $1 per CPU hour.

I’m a bit concerned about speed with Infosolve: the company said it takes 8 to 12 hours to run a million record match on a typical PC. But that assumes you compare every record against every other record, which usually isn’t necessary. Of course, where smaller volumes are concerned, this is not an issue.

Bottom line: Infosolve and Pentaho may not meet the most extreme CDI requirements, but they could be a very attractive option when low cost and quick deployment are essential. I’ll certainly keep them in mind for my own clients.

0 Accenture Paper Offers Simplified CRM Planning Approach

As I’ve pointed out many times before, consultants love their 2x2 matrices. Our friends at Accenture have once again illustrated the point with a paper “Surveying and Building Your CRM Future,” whose subtitle promises “a New CRM Software Decision-Making Model”.

Yep, the model is a matrix, dividing users into four categories based on data “density” (volume and update frequency) and business process uniqueness (need for customization). Each combination neatly maps to a different class of CRM software. Specifically:

- High density / low uniqueness is suited to enterprise packages like SAP and Oracle, since there’s a lot of highly integrated data but not too much customization required

- Low density / low uniqueness is suited to Software as a Service (SaaS) products like Salesforce.com since data and customization needs are minimal

- High density / high uniqueness is suited to “composite CRM” suites like Siebel (it’s not clear whether Accenture thinks any other products exist in this group)

- Low density / high uniqueness is suited to specialized “niche” vendors like marketing automation, pricing or analytics systems

In general these are reasonable dimensions, reasonable software classifications and a reasonable mapping of software to user needs. (Of course, some vendors might disagree.) Boundaries in the real world are not quite so distinct, but let's assume that Accenture has knowingly oversimplified for presentation purposes.

A couple of things still bother me. One is the notion that there’s something new here—the paper argues the “old” decision making model was simply based on comparing functions to business requirements, as if this were no longer necessary. Although it’s true that there is something like functional parity in the enterprise and, perhaps, “composite CRM" categories, there are still many significant differences among the SaaS and niche products. More important, business requirements different greatly among companies, and are far from encapsulated by two simple dimensions.

A cynic would point out that companies like Accenture pick one or two tools in each category and have no interest in considering alternatives that might be better suited for a particular client. But am I a cynic?

My other objection is that even though the paper mentions Service Oriented Architectures (SOA) several times, it doesn’t really come to grips with the implications. It relegates SOA to the high density / high latency quadrant: “Essentially, a composite CRM solution is a solution that enables organizations to move toward SOAs.” Then it argues that enterprise packages themselves are migrating in the composite CRM direction. This is rather confusing but seems to imply the two categories will merge.

I think what’s missing here is an acknowledgement that real companies will always have a mix of systems. No firm runs purely on SAP or Oracle enteprise software. Large firms have multiple CRM implementations. Thus there will always be a need to integrate different solutions, regardless of where a company falls on the density and uniqueness dimensions. SOA offers great promise as a way to accomplish this integration. This means it is as likely to break apart the enterprise packages as to become the glue that holds them together.

In short, this paper presents some potentially helpful insights. But there’s still no shortcut around the real work of requirements analysis, vendor evaluation and business planning.

0 Beware Distributed Analytics (You Read It Here First)

What might be called the “standard model” of business intelligence systems boils down to this: many operational sources feed data into a central repository which in turn supports analytical, reporting and operational systems. A refinement of the model divides the central repository into a data warehouse structured for analysis and an operational data store used for immediate access. (Come to think of it, I don’t see the term “operational data store” used much anymore—have I just stopped looking or did I miss the memo that renamed it?)

No one has been attacking this model directly (unless I’ve missed yet another memo), but it does seem to be under some strain. Specifically, much more analytical power is being built into the operational systems themselves, reducing the apparent need for centralized, external business intelligence functions. Examples abound:

- channel-specific analytical systems for Web sites and call centers (see last Thursday's post).
- more extensive business intelligence capabilities built into enterprise software systems like SAP
- rule- and model-driven interaction management components built into customer touchpoint systems
- more advanced testing functions built into operational processes (okay, we haven’t seen that one yet, but I did write about it yesterday).

Generally speaking, more analytical capability in operational systems is a Good Thing. But if these capabilities replace functions that would be otherwise provided by a centralized business intelligence system, they reduce the incremental value provided by that central system and therefore make it harder to justify. The resulting fragmentation of analytics is preferred by many departments anyway because it increases their autonomy.

This fragmentation is a Bad Thing, especially from the perspective of customer experience management. Fragmentation leads to inconsistent customer treatments and to decisions that are optimal for the specific department but not the enterprise as a whole.

The problem is that analysts, consultants, journalists and similar entertainers are always looking for new trends to champion. (Yes that includes me.) So coining a phrase like “distributed analytics” and calling it the Next Big Thing is immensely attractive. (FYI, a Google search on “distributed analytics” finds 64 hits, compared with 410,000 for “predictive analytics”. So the term is definitely available.)

We must all resist that temptation. A consolidated, centralized data view may seem old-fashioned, but it is still necessary. (Whether the data must be physically consolidated is quite another story—there’s nothing wrong with federated approaches.) By all means, analytical capabilities should be extended throughout the organization. But everyone should be working with the same, comprehensive information so their independent decisions still reflect the corporate perspective.

0 Channel-Specific Analytics Are Doomed: Doomed, I Tell You

Did you ever have one of those crazy dreams, not quite a nightmare, where unrelated things get mixed up together? I felt that way this morning when I was looking at the Web site for one of the mobile marketing systems and saw they had alliances with Web analytics vendors. That rang a bell, but it took a while for me to realize that I had been writing about consolidation in the Web marketing space separately from mobile marketing.

The confusion is compounded by my recent look at non-Web analytics system including ClickFox (which gathers interaction logs from call centers and other systems) and Skytide (which gathers all kinds of data; I haven’t written about it yet).

There’s an obvious connection between systems that gather interaction data and those that manage marketing messages. As the Omniture / TouchClarity hookup I mentioned yesterday illustrates, some of the vendors are themselves bringing the two together. It’s no surprise that this would happen for Web systems, which tend to be internally integrated but isolated from other media.

Of course, the Web should not be isolated, and the trend is in fact towards cross-channel integration. Does it make sense, then, for Web analytics vendors to integrate tightly with Web targeting systems? You can see why an analytics vendor would want to do it—as a revenue-generating line extension and a way to help clients who lack an existing targeting solution. But the vendors (and I’m sure Omniture recognizes this) must also make it easy to integrate their systems with any other targeting product. Otherwise, they risk losing sales to prospects who already have a targeting solution and don’t want to change it.

From a broader perspective, though, interaction data from many channels needs to be combined for marketers to do the best job of analysis and targeting. This can be done by physically copying the data into a traditional data warehouse or by using some sort of virtual or federated structure. What’s important is that data from many sources must come together into a single location, where it becomes accessible to many execution systems. In other words—am I beating a dead horse here? —you don’t want direct connections between single-channel source and execution systems, such as Web analytics to Web targeting.

This has technical implications. In the cross-channel scheme, the role of the analytics system is just to gather and reformat data so it can be presented to the central storage facility. The actual analysis would be done in the central system or by a cross-channel analysis system that draws from it. This means that products which combine data gathering and analysis, like current Web analytics systems, need to decouple those functions and build open interfaces to reconnect them. These interfaces would allow users to substitute other products on either side of the relationship. In addition, vendors with specialized data storage technologies might offer a storage component with interfaces at both ends, one to accept feeds from multiple data-gathering systems and the other to allow access by multiple analysis and targeting tools.

This is not an appealing proposition for many vendors. Breaking their systems into components opens them up to more competitors and risks each component appearing to be a commodity. It also eases switching costs, placing further pressure on prices. In general, as I’ve noted many times, vendors seek to expand their footprint and increase integration, not the other way around.

But vendors who specialize in systems for one channel will increasingly find themselves frozen out of multi-channel opportunities. There are already many products to provide multi-channel data store, analysis and targeting. Data gathering still tends to be channel-specific, but that won’t last as new channels become better understood.

In short, vendors who seek to remain channel specialists are likely to find their business shrinking over time. This may seem like bad news, but the sooner they begin to adjust to it, the better off they’ll ultimately be.