Rewriting the rules

Save Harbour StatementThis document may include predictions, estimates or other information that might be considered forward-looking. While these forward-looking statements represent our current judgment on what the future holds, they are subject to risks and uncertainties that could cause actual results to differ materially. You are cautioned not to place undue reliance on these forward-looking statements, which reflect our opinions only as of the date of this presentation. Please keep in mind that we are not obligating ourselves to revise or publicly release the results of any revision to these forward looking statements in light of new information or future events. Throughout today’s discussion, we will attempt to present some important factors relating to our business that may affect our predictions.

Pre-requisitesIn order to get the most out of this document you will have had some administrator training and/or experience in the Oracle | RightNow CX product. You’ll also be familiar with what rules do, and might have had a go at writing rules. I’m focusing on incident rules within this document, but the concepts apply equally to other aspects of rules such as contact and chat.

The CX version used for this document is Feb ’13.

This document has been written an informal style, to impart experience rather than as a formal training document. If you would like to receive training on rules, administration or any aspect of Oracle | RightNow CX contact us at mail@miconsulting.net.au or on 1300 732 783 or via LinkedIn.

IntroductionThere are many examples of how to write rules found within the RightNow forums, communities and within the product. Head to http://cx.rightnow.com or the LinkedIn forums that specialise in RightNow (Luis Melo has written the best documentation I’ve seen in a long while).

Rather than provide more documentation on how to write rules I’d like to explain what, in my humble opinion, makes good rules. I’ve met many RightNow consultants and customers since 2006 when I started using the product and each one has found a different approach to the same problem. What I’ve tried to boil down is the best that I’ve seen and what I’ve learned.

Rules are often neglected by the system because once you get them in place it seems really hard to take another stab at them based on what you’ve learned. In fact, Oracle | RightNow seem particularly reticent to change the input design because the look and feel of this part of the system has its roots way back in version 6.5 (I’m reliably informed that Greg sold this release to Noah for animal relationship management).

By Mark Kehoe, April 2013© MI Consulting

1

Rewriting the rules

What We’re CoveringI’m making this document an introduction to writing great rules. It’s written to allow you to pick the parts that you need, but based around incident rules. If you can cope with this document, there’ll be another deeper document around rules to further your understanding.

1. Basic rule writing concepts2. Moving away from IF THEN ELSE3. Queue assignment examples4. Catchall rules

Basic Rule Writing ConceptsWhile on my travels around Europe with RightNow, I’ve needed to convey complex ideas to people who don’t use English as a first language. Try telling someone what IF THEN ELSE does in Swedish and you soon realise that clarity and purpose take on a whole new meaning. To make matters worse the out-of-the-box rules that come pre-configured with a new system aren’t very helpful often starting the confusion.

Consequently I have a method of writing rules that I think is clear and simple to understand that I’d like to share with you.

Let’s start with some basics.

1. Put similar rules into a function2. Don’t think IF / THEN, think question / answer3. Make it human-readable

How do we do this? Let’s start with a typical incident rule that assigns incidents to queues. We might start with a queue function, add some rules to allocate a queue and allow the rules to continue:

By Mark Kehoe, April 2013© MI Consulting

2

Rewriting the rules

Figure 1: Call Queue Function

Figure 2: Queue function

So this all works and let’s assume that it assigns to a queue (I’ve not shown the IF THEN conditions for each of the four queues shown). How does this look in our audit and rule log?

By Mark Kehoe, April 2013© MI Consulting

3

Rewriting the rules

Figure 3: Incident rule log

As we can see, the log viewer shows that the function has been called ‘Call queue function’, and assigned us to the ‘Tier 2’ queue.

Let’s try and think about what we have done. We have called a function, tested the incident and assigned it a queue. How else can we think about this function?

“What queue do we need?”“Set the queue to…”“Tier 2”

Let’s rewrite the rules. Here is my queue function. Note that the name isn’t ‘queue function’ because I want to make this has human-readable as possible:

Figure 4: Set the queue function

Now for the rule that calls the function. See that the name of the rule is called ‘What queue do we need?’ to make this as readable as possible:

By Mark Kehoe, April 2013© MI Consulting

4

Rewriting the rules

Figure 5: New Incident State

Figure 6: What queue do we need rule

Footnote on states: When writing states it’s best to prefix the name of the state with a number, because the system will automatically rearrange your states alphabetically. Also, try to be more prescribed than ‘initial’ or ‘in progress’ for rule states. I like to use ‘1. New incident’ or ‘2. Updated incident’.

Let’s take a look at the audit log against the incident. Remember our agents are on the sharp-end of our rule changes so if something goes wrong they are probably going to be the first to point out the problem. By creating clear rules, they are also in the best position to help us.

By Mark Kehoe, April 2013© MI Consulting

5

Rewriting the rules

Figure 7: What queue do we need?

Now we can see what the rule and function starts to make more sense. What queue do we need? Tier 2. Isn’t that easier to read? Now in this simple example the concept doesn’t really shine so let’s add a few more real-world examples to the rule base and check out the audit log.

Figure 8: Detailed audit log

This contains more functions than the first example. See how easy it is to read? Let’s walk through it:

By Mark Kehoe, April 2013© MI Consulting

6

Rewriting the rulesSmart assistant is a function, and gets used with an email response. The priority is another function call, but to make it more human I’ve called it serious. Next up is assigning an SLA and then queue comes in a readable format.

I use (default) queue as a catchall rule so that every incident gets this queue before going through assignment. A catchall rule looks like this:

Figure 9: Catch-all queue rule

The rule is placed at the beginning of the list so the rules engine always catches it:

Figure 10: Queue function

The catchall rule concept means that as a systems administrator I know if anything is in the ‘default’ queue then something has gone wrong.

By Mark Kehoe, April 2013© MI Consulting

7

Rewriting the rules

ConclusionsHopefully these examples help clarify how to rewrite the rules you might have within your system. If they don’t make sense to you – how is anyone else going to understand them?

Notice that I’m not really fixing anything – just renaming the rules to make them clearer to read; both in the rules engine, in the log viewer and incident audit log.

By Mark Kehoe, April 2013© MI Consulting

8