Your SlideShare is downloading. ×
Rewriting the rules
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Rewriting the rules


Published on

Insights and best practice regarding RightNow CX business rules, focused around incidents. The document is written informally to enable administrators who might not be comfortable or familiar with the …

Insights and best practice regarding RightNow CX business rules, focused around incidents. The document is written informally to enable administrators who might not be comfortable or familiar with the rules engine to make their first steps at making improvements.

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Rewriting the rulesBy Mark Kehoe, April 2013© MI Consulting1Save Harbour StatementThis document may include predictions, estimates or other information that mightbe considered forward-looking. While these forward-looking statements representour current judgment on what the future holds, they are subject to risks anduncertainties that could cause actual results to differ materially. You are cautionednot to place undue reliance on these forward-looking statements, which reflect ouropinions only as of the date of this presentation. Please keep in mind that we arenot obligating ourselves to revise or publicly release the results of any revision tothese forward looking statements in light of new information or future events.Throughout today’s discussion, we will attempt to present some important factorsrelating to our business that may affect our predictions.Pre-requisitesIn order to get the most out of this document you will have had someadministrator 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 writingrules. I’m focusing on incident rules within this document, but the concepts applyequally 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 ratherthan as a formal training document. If you would like to receive training on rules,administration or any aspect of Oracle | RightNow CX contact us or on 1300 732 783 or via LinkedIn.IntroductionThere are many examples of how to write rules found within the RightNowforums, communities and within the product. Head to orthe LinkedIn forums that specialise in RightNow (Luis Melohas written the bestdocumentation I’ve seen in a long while).Rather than provide more documentation on how to write rules I’d like toexplain what, in my humble opinion, makes good rules. I’ve met many RightNowconsultants and customers since 2006 when I started using the product and eachone has found a different approach to the same problem. What I’ve tried to boildown 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 itseems really hard to take another stab at them based on what you’ve learned. Infact, Oracle | RightNow seem particularly reticent to change the input designbecause the look and feel of this part of the system has its roots way back inversion 6.5 (I’m reliably informed that Greg sold this release to Noah for animalrelationship management).
  • 2. Rewriting the rulesBy Mark Kehoe, April 2013© MI Consulting2What We’re CoveringI’m making this document an introduction to writing great rules.It’s written toallow you to pick the parts that you need, but based around incident rules. If youcan cope with this document, there’ll be another deeper document around rulesto further your understanding.1. Basic rule writing concepts2. Moving away from IF THEN ELSE3. Queue assignment examples4. Catchall rulesBasic Rule Writing ConceptsWhile on my travels around Europe with RightNow, I’ve needed to conveycomplex ideas to people who don’t use English as a first language. Try tellingsomeone what IF THEN ELSE does in Swedish and you soon realise that clarityand 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 helpfuloften starting the confusion.Consequently I have a method of writing rules that I think is clear and simple tounderstand 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-readableHow do we do this? Let’s start with a typical incident rule that assigns incidentsto queues. We might start with a queue function, add some rules to allocate aqueue and allow the rules to continue:
  • 3. Rewriting the rulesBy Mark Kehoe, April 2013© MI Consulting3Figure 1: Call Queue FunctionFigure 2: Queue functionSo this all works and let’s assume that it assigns to a queue (I’ve not shown the IFTHEN conditions for each of the four queues shown). How does this look in ouraudit and rule log?
  • 4. Rewriting the rulesBy Mark Kehoe, April 2013© MI Consulting4Figure 3: Incident rule logAs we can see, the log viewer shows that the function has been called ‘Call queuefunction’, and assigned us to the ‘Tier 2’ queue.Let’s try and think about what we have done. We have called a function, testedthe 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 functionNow 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:
  • 5. Rewriting the rulesBy Mark Kehoe, April 2013© MI Consulting5Figure 5: New Incident StateFigure 6: What queue do we need ruleFootnote on states: When writing states it’s best to prefix the name of the statewith a number, because the system will automatically rearrange your statesalphabetically. Also, try to be more prescribed than ‘initial’ or ‘in progress’ forrule 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 areon the sharp-end of our rule changes so if something goes wrong they areprobably going to be the first to point out the problem. By creating clear rules,they are also in the best position to help us.
  • 6. Rewriting the rulesBy Mark Kehoe, April 2013© MI Consulting6Figure 7: What queue do we need?Now we can see what the rule and function starts to make more sense. Whatqueue do we need? Tier 2. Isn’t that easier to read? Now in this simple examplethe concept doesn’t really shine so let’s add a few more real-world examples tothe rule base and check out the audit log.Figure 8: Detailed audit logThis contains more functions than the first example. See how easy it is to read?Let’s walk through it:Smart assistant is a function, and gets used with an email response. The priorityis another function call, but to make it more human I’ve called it serious. Next upis assigning an SLA and then queue comes in a readable format.
  • 7. Rewriting the rulesBy Mark Kehoe, April 2013© MI Consulting7I use (default) queue as a catchall rule so that every incident gets this queuebefore going through assignment. A catchall rule looks like this:Figure 9: Catch-all queue ruleThe rule is placed at the beginning of the list so the rules engine always catchesit:Figure 10: Queue functionThe catchall rule concept means that as a systems administrator I know ifanything is in the ‘default’ queue then something has gone wrong.
  • 8. Rewriting the rulesBy Mark Kehoe, April 2013© MI Consulting8ConclusionsHopefully these examples help clarify how to rewrite the rules you might havewithin your system. If they don’t make sense to you – how is anyone else going tounderstand them?Notice that I’m not really fixing anything – just renaming the rules to make themclearer to read; both in the rules engine, in the log viewer and incident audit log.