Customer Satisfaction Survey
This case study will show you how to inject a random customer satisfaction survey into the user experience on a site.
We will use a flight recorder to graph the responses and collate comments from the users.
Planning the rules
The first step in implementing our customer satisfaction survey is to create a plan of what we intend to do, and how we wish to go about it. It is often a good idea to write this down in plain English and then use that text as a guide whilst designing the rule structure. In this case, the plan reads like this:
We want to ask random customers about their experience with our site.
We want to have the survey appear on our main page after log-in.
We want to make the survey experience as quick and painless as possible to get the maximum potential responses.
We are going to use the Tomorrow Software flight recorder feature to graph and view the responses.
Getting started
In this case study we are going to split the decision points into three discrete components, following the recommendations mentioned elsewhere in this manual. So, start by adding a new repository called "Customer survey" and create three blank rule sets:
"SurveyLoad", which is the rule set that will pre-check our survey and make sure all of the data we need is collected before we start the survey process.
"SurveySelection", which is the rule set that will determine if a user is selected for a survey.
"Survey", which is the rule set that will contain the survey logic itself.
Designing the user interface elements
The plan involves injecting a customer survey on top of the user experience. We can do this as a pop-up window or we can simply overlay it on top of the site using JavaScript. Given that most users block pop-ups these days by default, the later seems like the better option. We want to keep the survey itself as pure HTML, so a little bit of basic JavaScript will take care of it:
You can copy and paste the above JavaScript code into a file named "showsurvey.js" and upload it to the "Data Files" section of the "Customer survey" repository.
The above JavaScript will essentially grey out the application itself and overlay a HTML file on top that is named "survey.html".
Now we need to create the survey HTML itself. Once again this involves basic web design skills. The end goal is a page that looks something like this:
The easiest way to create the HTML is to follow these steps:
Create a subfolder under the "Content Files" section of the "Customer Survey" called "Qwerty".
Add a new file under the "Qwerty" folder named "survey.html".
Copy the following HTML code to your clipboard:
Update the "survey.html" file from the console. The embedded HTML editor will open.
Click on the Update button to go to the HTML text.
Paste the HTML shown above into the editor and click Save.
The page should now look something like this:
Now we have all of the components we need and are ready to begin writing rules to present our survey.
Creating the survey selection rules
We will begin by creating the survey selection rules. In this case, the rules are very simple. We use a random number generator to determine if a user should be asked to complete the survey or not.
In this example we want the opportunity to complete a survey to be fairly frequent.
So, we start by updating the "SurveySelection" rule set to look as follows:
The properties for these rules are:
Effectively we create a random number between 0 and 9 (1 digit) and provided the number is below 4, we proceed to perform the survey.
Creating the survey load rules
The purpose of the "SurveyLoad" rules is to prepare any data that may be needed by the other rule sets in the repository. It is often beneficial to do it this way to isolate or prepare data needed by other rule sets, yet at the same time keeping those other rule sets as generic as possible.
In our case, there are a couple of generic things we need to do and check:
We need to start the usual HTTP Request tracking.
We need to ensure a session has been started (meaning a user is logged on).
We need to obtain the customer account number so we can log it (no anonymous data here!).
Once everything is done, we need to proceed with the survey itself.
All of these tasks are very simple, so we show them here as a single step:
The only rule that has any non-default properties is the HTTP Session Object reader. This rule allows us to read the customer account number from the Qwerty session. The properties are as follows:
Creating the survey rules
We are now ready for the actual core process itself with all data and user interface components prepared. So, lets update the "Survey" rule set.
The first issue is to place the survey in the right place in the navigation process, which, in our plan, is to inject the survey on top of main page.
We start by finding out what the name of the page that is being requested is:
The name splitter rule is extremely useful for this as it allows us to split a text string based on a separation character. The separation character in a URL is always "/", so we can find the requested page by using the following properties:
Then we can use a Switch rule to determine how to direct flow:
In this case the Switch variable is URL and adding new chain points to the switch rule determines when logic flows down a certain path.
Note the use of survey.jsp. That page does not exist in the Qwerty application. It is the name of the page that the HTML form in "survey.html" posts its data to. The X Agent simply intercepts this request and deals with it before it ever reaches the application itself.
We are now ready to determine what happens when the user reaches the main page, the first step is to make sure we haven’t already presented a survey to the user in the current session:
The properties for this look as follows:
Basically, we check the session to see if a flag named "DoneSurvey" has already been set. If not, we proceed to see whether we need to present the survey by using the already created "SurveySelection" rule set:
If the response comes back that we need to perform the survey, the next action is very easy. We read the already prepared JavaScript "showsurvey.js" file and add it to the response being sent back to the user:
Once again, the properties are shown here:
This takes care of presenting the survey to the user. Now we just need to handle the response from the user to the survey, the first step of which is to record whether the user has in fact responded to (or denied taking part in) the survey:
We record this in the session using the following properties:
Next, we check if the user hit the "Submit" button and if yes, we record the answers in the flight recorder. If no, we simply return the user to the main page, using a little bit of JavaScript to remove the survey.
The properties are as follows:
Optional index fields: ProductRange,Pricing,EaseOfUse,Delivery,Comments
Response data: "<script>parent.document.location='main.jsp';</script>"
The little piece of JavaScript used here reloads the "main.jsp" page. As the survey flag is now set to "X", the survey will not re-appear, and the user can continue as normal.
Creating the survey configuration
The configuration for this example is very easy. Simply create a new configuration in the Customer Survey repository and name it "SurveyTest". The following shows all of the relevant parts that must be completed for the configuration:
Testing
You are now ready to test the survey rule set. Deploy your new configuration to the Qwerty demo server and start it. Then log into Qwerty. There is approximately a 1 in 3 chance of you getting a survey request. To quickly invoke a survey, click on the "Set up 3rd party" button and then "I'm finished", until a survey request appears. Once you have completed or rejected a survey request, log out and log back in to be presented with another one.
Make sure you answer 4 or 5 surveys at this point.
Setting up the flight recorder definitions
We now have some data in the flight recorder, so we need to set up a definition for it in order to view the data from within the console.
The following shows the definition used in this example:
Seeing the survey results
Once you have done this, select Flight Recorders from the console menu and click on SURVEY:ANSWERS. Leave all of the fields as default and click on Search (tip: if you only wish to see survey answers with comments, put an uppercase "A" into the "Comments:" from field and a lowercase "z" into the to field).
The survey results submitted will be shown:
You can now click on the graph of one of the questions. The result is a pie chart showing you the answer distribution:
Using the flight recorder search filters, you can now use the responses to better understand your customer satisfaction ratings. For example, you can see if Firefox users generally rate the ease of use of your site higher than Internet Explorer users or vice versa.
Potential improvements
The sample created here is fully functional, but for production purposes, you may wish to add a few things. Some possible improvements are:
JavaScript validation to ensure the customer has completed the form before submitting it.
Logic in the SurveySelection rule set to ensure that the same customer does not get the survey more than once every 6 months (The History Summary rule or the History Recorder rule are both useful for this purpose).
Last updated
