Chris Skinner wrote a nice little piece on the Future Call Center over on the swift community. He had some nice examples, though he was focused on how the future call center might be using video. What struck me, though, was that decision making is critical to his example. Neither the avatar nor the video-linked person can be effective without automated decision making. If they don’t know what decisions can be made, if they are not told what is allowed/not-allowed, if they don’t have access to the decisions about personalized offers then they cannot deliver the experience he discusses. Passive presentation of information will not cut it - the person is unlikely to be able to be sufficiently responsive without decision automation (it will take them too long to review everything and then decide manually) and the avatar can’t do anything unless it is programmed to make decisions.

It also struck me that going overdrawn should have triggered a response - a decision should have been made about how to treat him when he went overdrawn and, for a good customer, this should have included a proactive promotion of the short term loan. Combining becoming more event-driven (a critical need for most financial institutions) with decision automation gives new meaning to proactive customer service (one of the recommendations of The Best Service is No Service, an excellent book).

If making your call center more effective is on your list of things to do I have written a number of posts on using decision management in the call center.

Note: This post was prepared earlier and posted this week while I am on vacation.

David Rance had a nice piece on CustomerThink called Great Service Has to Be Institutionalized if It Is to Become the Norm. In this post he identifies decision making as important, which I think is true. Now his focus is on culture (very important) but mine is different. What if you used your systems to institutionalize great service?

Think about it. You could define what you mean by great service, identifying the moments of truth (decisions) where your staff need to decide to treat customers well and specifying the “rules” for many of these interactions. Embedding these decisions into your CRM systems would mean that your staff would automatically make the decision that represented great service. Furthermore, embedding these decisions into your website, IVR system, kiosks and ATMs would mean that your automated channels would also automatically make decisions that deliver great customer service.

Now I am not pretending you can automate your way to great customer service but I do think that failing to do so will handicap any effort to improve customer service and that automating customer service decisions can make a big difference. I wrote a piece a little while ago on decision management and loyalty and another about bad decision making in systems resulting in bad customer service.

Note: This post was prepared earlier for use this week while I am on vacation.

Well I am off to the mountains for a vacation with no email, no cell phone, no twitter and no blogging. I have queued up some posts for you so you won’t miss me too much but don’t expect a reply until after the 25th.

Have fun

Chris Berg wrote a nice piece on Pressure Points that seemed like it was worth highlighting. Chris outlines some great reasons for using business rules and he seems to Believe in business rules (as I do).

Got another question about a job today. This time Jim Fahy sent me this one:

Director, Insight and Innovation Advanced Capabilities

The Insight and Innovation group combines a customer analysis group; research and targeting; and the analytics reporting and technology team formerly housed in a corporate customer service excellence structure.  The customer and market insights that are created will drive the improved innovation, product development, brand differentiation and customer loyalty with the goal of propelling revenue growth and driving customer acquisition through a world-class insight and innovation center of excellence.  The Insight and Innovation Advanced Capabilities Director will provide strong leadership promoting teamwork and building on strong collaborative relationships with cross functional partners.

The individual selected for this role will provide strategic thought leadership with regard to statistics/modeling and targeted marketing areas for Wachovia.  He/she will manage Insight and Innovation resources dedicated to targeted marketing modeling/optimization and advanced modeling efforts such as pricing, ROI and media mix modeling.  This professional will lead the development of cross-enterprise customer/prospect contact strategies in order to maximize Wachovia’s return on targeted marketing investment.

Here are the details, contact Jim if you are interested.

I have been an iRobot customer since Christmas. Much as I like their products, their customer service decision making leaves a lot to be desired. This particular post was prompted by their inconsistent warranty decision management. iRobot has outsourced its call center, as many companies have, and sound like they want to deliver excellent customer service. Certainly the folks from the Jay Group (their outsourcing partner) do. Yet the complete inability of iRobot to deliver consistent warranty decisions or to put their business experts in control of critical customer service decisions makes this impossible. As a result my customer experience has gone steadily downhill - for want of a decision the customer was lost. I would point out that some time ago I posted on iRobot’s silly return process and the contrast of this with its apparently award-winning CRM (here’s another post that picked up mine and that has a comment proving I was not an isolated instance). That time, as now, the problem is one of decision making. Clearly customer service and warranty decision making is not their strong point.

So here I am, once again, engaged in dealing with iRobot’s customer service. This time my Dirt Dog has gone wrong. This robot was always my favorite - the one that had the clearest ROI - but some days ago it started misbehaving. After some intelligent back and forth debugging it by email, I got this from the customer service folks:

Based on the information you have provided us, we have determined that your robot needs to be replaced. We have all the pertinent information, so at this time all we need from you is permission to set up the exchange and we can process the exchange through email.

Because we are not requiring you to return your current unit to us, we ask that you dispose of the robot. This Dirt Dog has been permanently deactivated in our records

Very nice customer service - rapid debugging, clearly a problem with the unit, don’t worry about sending it back we’ll replace it. Lovely. The new unit arrives but, sadly, never works right. Back to customer service.

This time the debugging interaction is not so good. The first couple of responses have pretty clearly not bothered to actually read what I wrote in the problem statement and suggest trying things that I have already tried and that, anyway, don’t match the symptoms I am describing. Clearly this decision making is not really under iRobot’s control.Eventually I get a response as follows:

Please place your Dirt Dog in a plain cardboard box. …
In the box, please include a note with the following information …
Please ship the box to the address below. We recommend that you ship this parcel via UPS or FedEx, because they provide you with tracking and insurance…

So the first time my Dirt Dog went wrong it is replaced at no cost to me. The replacement never works but now I have to pay to send it back? When I ask the customer service folks this question they tell me:

We do not offer to reimburse shipping charges for the return of items to us to be replaced

But surely they do not always require things to be returned? I can’t imagine the policy has changed in the few weeks since I last interacted with them. Clearly iRobot has a consistency problem - the customer service folks are not able to make consistent warranty decisions.

After a little research I discover that iRobot uses RightNow’s SaaS CRM offering to run their call center which they outsource to The Jay Group. I even found a podcast from the Voices of CRM series in which iRobot and the Jay Group describe their relationship. In the podcast the iRobot and Jay Group representatives make some interesting points:

• They stress the need for dynamic troubleshooting of robots - the outsourced reps must know how
  Yet my experience is that the quality of debugging varies significantly between reps.
• Engineers need access to these conversations to see what can be fixed and they talk of documentation about problems stored in the CRM application
  Yet the engineers don’t seem to be able to change the interaction directly, only indirectly through the documentation they provide
• They outsource because the call center is not their core competency
  Which is fair enough but isn’t determining what’s wrong with a robot a core competency? How about defining the warranty policy and returns criteria? Surely those ARE core competencies?
• The idea is to allow users to choose a channel and then interact consistently
  Well I have only used one channel but so far they are not managing consistency even within the channel
• Finally they talk about automating returns at some point in the future to reduce wait times and improve efficiency
  But the conversation is about the process of generating return ids and managing the process, not about consistently correct returns decisions which seem likely to remain dependent on training of reps.

It would be easy to blame the outsourcing for the inconsistent customer service but frankly I don’t think that’s the problem. It is clear to me that iRobot has not thought about how it wants to handle some critical decisions:

• Deciding what is wrong with a robot
• Deciding if a robot should be replaced
• Deciding if a broken robot should be returned before it can be replaced
• Calculating the refund due for a return (previous post)

If it had then I would be getting consistent, and consistently accurate, responses from the Jay Group reps and I am not. Replacing an outsourced service with an in house one would not address the problem - the decisions would still be up to individual reps based on their understanding of what’s wrong and what the return policy is.

The moral of the story is that, if you want consistently excellent customer service, make sure you retain control of and effectively automate the critical decisions that affect your customers - debugging, refund and warranty decisions, for example. My process experience would have been quite different if these decisions were being managed explicitly, especially if they were being managed in a way that allowed the domain experts (engineers for the debugging, business owners for refunds and return policies) to control the rules and policies in the decisions directly. Then the decisions would be driven by the actual policies and actual experiences, not through the reps interpretation of those policies and experiences.

iRobot, automate these decisions!

A reader sent me an interesting question after watching the ILOG seminar on scorecards and rules in which I participated earlier this week (recording of this rules and scorecards seminar is available). Here’s a summary of what he said:

One immediate comment I would have is that scorecarding seems to insert an extra unnecessary step. Rather than have an extra level of modeling and human intervention, you can directly include data and knowledge and the framework basically generates the model for you in such a way that it guarantees that the information content of the model is equal to the information content of the inputs. Scorecarding represents an opportunity for either loss of useful information, or addition of artificial information. Depending on how you assign attribute score values and how that is then mapped to probabilities, the scorecard would almost certainly have a different information content from the original inputs. That’s important, because the value of decisions is a function of this information about the future. If your model of the future is bogus, so is the value, and you certainly stand to lose value one way or another.
There’s more on this topic here: Scorecards and Shareholder Value.

I think Dave makes some good points in his post, though I think the ability of scorecards and decision rules to be validated by regulators is not one that should be underestimated. Hopefully some of my readers will post some comments here or there and we can get a debate going.

Disclosure: I am an advisor to Provisdom.

I saw this piece on DSL and MDE, necessary assets for Model-Driven approaches and it made me think about DSLs. First, here’s the definition of a DSL from the article

DSL is a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain.

I notice some pieces of advice about DSLs in this article that make me think business rules would work better. First he suggests that you:

Implement DSLs in a way that they are directly executable on a specific platform. For making them executable on another platform the generator or interpreter needs to be rewritten

Well a business rules management system handles this for you. In fact several commercial BRMS products allow you to execute as COBOL, Java or .Net from the same rules. Next he says:

Make DSLs extensible by existing GPLs [General Purpose Languages], programmers can formulate the necessary additions in a language they know.

Most BRMS products do this inherently, allowing business rules to access functions written in C# or Java or whatever. He goes to quote someone who:

emphasizes that for tackling the complexity of software development a language is needed understandable by both developers and domain experts.

This, of course, is a key value of using a business rules approach and a BRMS. Now thinking about DSLs and how often a business rules approach and a BRMS could (and should) be used instead made me remember an article on Business Natural Languages (a better name IMHO for DSLs) I saw some time ago in which Jay Fields said:

The more business specific logic you can abstract out of an application the less programmer involvement you will need to alter the business logic.

Then, more recently Jay had a post on Designing a Domain Specific Language in which he talked about building a system that allowed the

director of finance for the client bank to edit, test, and deploy the business rules of the system without any assistance from IT

Hmm. So far this all sounds like the kind of thing for which business rules are ideal. Not only are they declarative and clear for business users, they typically act against an object model in a way that allows more business-friendly names to be used - essentially hiding the objects and their complexity. If you like you can even use various web-based editors (with most commercial products) that hide even the structure of the rules themselves, allowing a point-and-click interface. Taking a business rules management system and building a domain-specific environment on top seems to me much more efficient than creating a whole DSL from scratch.

DSLs come up a lot, especially in the context of model driven engineering or development or architecture (MDD/MDE/MDA). Personally I think business rules work better and do so without you having to write a bunch more code. Models and business rules, perfect together.

A reader asked me last week about how I saw business rules engines fitting in with UML, SOA and Microsoft. The article discusses whether Microsoft’s Oslo strategy for SOA will be based on UML or merely offer support for it among many standards.

First, let me say that I think it is increasingly clear that application development is going to change a lot in the coming years (and is already doing so). To the point where I don’t think it will really be what we call application development any more. From what I know of Microsoft’s strategy they are trying to make sure that they support their core audience (developers) while also adapting to this reality. UML is part of that, so is support for process-centric standards like BPEL and BPMN.

Regardless of which modeling standards and approaches a developer uses, I think the case for externalizing and managing business rules remains compelling. Business rules, especially those implementing decisions, must be owned by the business and IT in collaboration and so code is a non-starter. A declarative, verbose, business-friendly approach to specifying business logic is a must today and will be even more so in the future. Microsoft has a fairly aggressive approach to its business process ecosystem and has included business rules vendors in that for a while. Their own support for rules and process and the support of their partners makes me think that rules, rule engines and rule management will be either part of the vision or at least very compatible with it.

I blogged about how I see business rules fitting with model-driven approaches (I think they complement each other) and wrote an article about SOA, rules and decision services before. If you are interested I will also be speaking at the SOA Symposium in October on Decision Services.

One last thing - domain specific languages. These come up a lot in Microsoft discusions and I am going to blog about them tomorrow.

I got a briefing last week from IBM as part of my researching of the IBM/ILOG acquisition (I blogged about this here). Back when I was at IMPACT it became clear that IBM was getting focused on events, rules and policies - they talked about Points of Agility, points in a business where variability is critical to success. Rules, analytics, business events and policies were all identified.  While today’s briefing could not cover any future plans, I did get an overview of IBM’s current relationship with ILOG.

IBM has been partnering with ILOG for over 10 years in various parts of IBM. When IBM made the 2005 announcement of their SOA stack for WebSphere, including WebSphere Process Server, this relationship was stepped up a notch. IBM’s architects had a vision of the importance of business rules within the process and within the broader application development environment. Within WebSphere Process Server is a Business Rules Manager with some rules capabilities for rule sets and basic decision tables. This is designed to strengthen the value proposition around abstraction - with a BPEL engine, human task management support, state machines and business rules to deliver abstraction. This was always designed to support external rules management products, especially when a customer needed end to end rule management and support for the whole business rule lifecycle. The partnership with ILOG has been designed to make this straightforward. A couple of other areas of partnership include:

• The original WebSphere Business Events product and the acquisition of AptSoft put a focus on business user tooling is targeted at agility. I blogged about a joint IBM/AptSoft presentation when I was at IMPACT
• The Information management group, especially in the context of enterprise content management and FileNet - considers business rules a complementary technology for document-centric process management. I wonder what IBM is thinking about in terms of rules-driven case management?
• Master Data Management - InfoSphere MDM - is very complementary with business rules.
• Tivoli (and Business Events) uses ILOG’s visualization product
• IBM’s Center for Business Optimization is using ILOG’s new optimization stuff (Optimization Decision Management) as well as CPLEX

I blogged recently about the role business rules has to play in IBM’s SOA methodology and my conversation today simply reinforced my view that IBM was already taking business rules seriously when it announced the ILOG acquisition. I look forward to finding out more as time passes.