Creating a Real-Time Decisions Project : Day 5

OK, back to the drawing board a bit. After having worked through the first four sessions putting together an RTD Inline Service to select the most appropriate manufacturer for the Order Bookings BPEL process, it became increasingly clear that trying to put this particular scenario together for my first RTD project was a bit ambitious.

The problems boiled down to two things: firstly, the only full-scale, keypress-by-keypress example I had was the Oracle By Example CRM cross-selling project available for download on OTN, which although thorough didn't map too well to the scenario I was working on. I do have a demo around order allocation using RTD, but it's undocumented and a bit tricky to "reverse-engineer" when I've not put a proper, full-scale RTD system together before. So, rather than press on with things not being too clear, I thought I'd restart, but with a slightly simpler scenario that mapped easily onto the OTN Cross-Selling example.

So, in this revised scenario, our customer who has placed the order through the Order Bookings SOA Suite demo, gets a call from our customer service team after the order goes through. The aim of this call is to cross-sell them something, which they may or may not accept. We will use RTD to firstly, model the reasons the customers give for placing the order (a gift, a business purchase, a personal purchase, other), the various cross-selling things we might offer them (express delivery, free gift-wrapping, a voucher off their next purchase, an extended warranty, rechargeable batteries), and whether or not they take up the offer. Each offer will have a revenue figure and cost associated with it, and our performance goals will aim to maximize revenue and/or minimize cost, with different weightings given to these goals depending on which segment they belong to (gold, silver and bronze). So, still a fairly interesting scenario, but one that also maps well to the detailed steps on OTN, albeit with different data and choices so I'll still need to think about how it gets implemented.

Going back to the start again, this time I define my data source as pointing to a CUSTOMER table, which brings across details of the customer status, credit card type, number of previous returns, previous highest order and the customer ID. I then define an entity which I map to this data source, like this:

I then define another entity, called CALL, that records the name of the agent, the length of the call, and the reason for the order. This entity, together with the customer entity, are then added as attributes to the session entity, whose key is defined as being the customer ID, like this:

I now create two External systems references, once for the Interactive Voice system (IVR) that calls the customer after they've placed the order, one for the CRM system that records details of the call.

Next I create three informants:

1. One to record the start of the call
2. One to record the reason for the order,length of call etc at end of customer service section ("Did the order go ok for you, is there anything else we can do" etc) and the name of the agent.
3. one to close the call off, at the end

For the moment, I don't add any logic to these, although for the second informant, I map the order reason, agent name and length of call to the Call element of the session entity, so they're available to the rest of the process.

So now, I'm at the point where I was yesterday, but I'm putting an inline service together that's more in line with RTD's main purpose - making real-time marketing offers to customers, basing the offer on a model, and feeding their response back into the model at the end to make it more accurate. Later on in the week, I'll come back to the original manufacturer selection problem and see how this can fit back to that.

So, now to move on. The next thing to do is to create the first of the two Choice Groups i'll be working with. The first is the set of order reasons that the customer will provide, the second is the list of cross-selling offers I can present to the customer.

To do this, I create an Order Reason choice group, then associate the four order reason choices with it, assigning each of them an ID number that will eventually get stored in the order reasons model:

Then I create the first of the models, in this instance one that I'll use to store the reasons that customers place orders. I create the model as a Choice Model, associate it with the choice group I just defined, and tell it to get its input from the Call Complete informant, using the Learn Location tab.

Now I need to add some Java code to load values into this Choice Model. I go back to the Service Complete informant and add the following Java code to the logic tab:

logInfo ("Integration Point – Service Complete. ");
logInfo ("  Order Reason: " + session().getCall().getOrderReason());
logInfo ("  Agent: " + session().getCall().getAgent());
logInfo ("  Length: " + session().getCall().getLength());
int code=session().getCall().getOrderReason();

switch (code) {

case 17:

ReasonAnalysis.addToChoice("Gift");

logInfo ("  Gift was added to the model");

break;

case 18:

ReasonAnalysis.addToChoice("Business");

logInfo ("  Business was added to the model");

break;

case 19:

ReasonAnalysis.addToChoice("Personal");

logInfo ("  Personal was added to the model");

break;

default:

ReasonAnalysis.addToChoice("Other");

logInfo ("  Other was added to the model");

break;

}

When I deploy the project and then run a test on it, I can see that it's working ok and adding the order reason (Business, corresponding to code 18) to the Reason Analysis model.

So now I'm in a situation where calls are being processed, and we record the order reason, length of call and the handling agent into an order reasons model, which I'll refer back to later on when working out which cross-selling offer to make (on the basis that, if someone says their order was for business, they're more likely to take up an express delivery offer, whilst if the order is a gift, they'll be likely to go for a gift wrapping order, although that might not make as much money for us).

Now, I need to use another RTD tool, the Load Generator, to create a script that will simulate calls coming in, customers giving us their order reasons, and the reason for call, call length and agent name being recorded in the Reason Analysis model. This step involves working with a load generator tool, creating variables and assigning them to the various informants in place in the RTD Inline Service, and then running the load generator to simulate in this case 2000 calls coming into the call centre.

Now I'm going to start up my Web browser and take a look at the results of the generated load. I start up the RTD Decision Center application, log in and take a look at my Inline Service.

Looking at the diagram, I can see the four informants within my Inline Service, and down the left-hand side, the various choices and informants that I created earlier.

If I then look at the correlation between each choice, and the various customer attributes, by far the strongest correlation is between the order reason, and the choice - which is fairly obvious if you think about it.

When I need to do, then, is to take Order Reason out of the predictive model, as it'll always have a 1:1 correlation between it and the Order Reason choice. I do this via the RTD Studio application, redeploy the Inline Service and clear down the existing model values, then run the load tester again and check the output.

That's more like it, there's a weak correlation between the various customer attributes and the order reason, but no huge correlation between the order reason given and the order reason recorded, which would skew the figures. Of course, any correlation that there is, is purely random as the load generator used random figures. Later on, we'll use proper customer responses, and skew the data a bit, to show how the model works.

Well that's it for today; we've got the various entities set up, together with the main informants, and created a model to record the reasons that customers give for placing an order. Tomorrow, we'll look at generating cross-sell offers based on various performance goals we set the system, and the day after that, we'll feed customer responses back into the model to make it more accurately predictive, over time.