Triaging Customer Requests (How to decide what to ask next!)
Following on from my previous article “Configuration Driven Interactions with watsonx Assistant” I’ll expand on the approach I touched on prevously to support “traiging” customer requests.
First, let me recap what I mean by “triaging” request. This is best done by using an example so lets use a fictitious“refund” journey for a bank named OFN. Here, the customer wants to secure a refund on a payment they made. In order to do this we need more information for example, how was the payment made, who was the payee target, could the payment be fraudulent etc. The level of information that we need to collect will depend on how the payment is made. If the payment is made using “PayPal” thats all we need but if was done by a card or a direct debit we need to know the payment target. Finally if it was a transfer we need to ask if the transfer was to a closed account. The flow continues to expand in the case of card and direct debit payments as shown below.
The important thing is that the information that the refund journey requires is “informed” by the responses the customer provides i.e. the journey is dynamically configured to ask for only what it needs not the complete set of potential data items.
With the requirement covered let's look at how we solved the problem.
As explained in my last article this “dynamic” behaviour is an extension of the solution we created to handle the “Open Request” interaction pattern. In the base pattern we describe each element of data we need to acquire from the customer and we proceed to collect them all [we refer to this as a “static” collection]. With the “dynamic” approach we introduced the concept of “required” data. This is the key information required to determine the inital path to follow. In the case of the flow described above this would be “payment mechanism”. The following shows the journey configuration. You can see that the “payment_mechanism” variable is set to required whilst the rest are marked as not required.
{ "A2-refund-for-actions": {
"action": {
"type": "rulesDefined",
"name": "rulesDefined"
},
"captureType": "dynamic",
"default": {
"action": null,
"confirm": "",
"clarify": "",
"response": "I can help you with a refund.",
"repeat": "",
"example": "",
"paraphrase": "",
"verify": false,
"complete": false,
"validation_question": "",
"rules": "refund-For-Actions",
"dataCapture": {
"numberOfItems": 5,
"dataToCapture": [
{
"action": null,
"variableName": "payment_mechanism",
"description": "How payment was made",
"justification": "So I can route the right way",
"confirm": false,
"response": "How did you pay?",
"repeat": "How did you pay?",
"example": "Card, Paypal, Transfer, Direct Debit.",
"paraphrase": "What did you use to pay?",
"type": "A2-payment-mechanism",
"options": [
"card",
"transfer",
"paypal",
"direct debit"
],
"collected": false,
"always_ask": false,
"required": "yes"
},
{
"action": null,
"variableName": "payment_target",
"description": "Target of the payment",
"justification": "I need this information so I can assess best approach for a refund.",
"confirm": false,
"response": "Who was the payment to?",
"repeat": null,
"example": null,
"paraphrase": "Where did the payment get sent to?",
"type": "A2-llm-payment-target",
"options": [
"NWG",
"other",
"unknown"
],
"collected": false,
"always_ask": false,
"required": "no"
},
{
"action": null,
"variableName": "payment_suspicious",
"description": "Payment is suspicious",
"justification": null,
"confirm": false,
"response": "Do you think the payment was suspicious?",
"repeat": null,
"example": "Answer with 'yes' or 'no' ",
"paraphrase": null,
"type": "D-yes-or-no",
"options": [
"yes",
"no"
],
"collected": false,
"always_ask": false,
"required": "no"
},
{
"action": null,
"variableName": "closed_account",
"description": "Target account is closed",
"justification": null,
"confirm": false,
"response": "Was the payment to a closed account?",
"repeat": null,
"example": null,
"paraphrase": null,
"type": "D-yes-or-no",
"options": [
"closed",
"closed account"
],
"collected": false,
"always_ask": false,
"required": "no"
},
{
"action": null,
"variableName": "direct_debit_paid",
"description": "Direct debit has been paid",
"justification": null,
"confirm": false,
"response": "Has the direct debit already left you account?",
"repeat": null,
"example": null,
"paraphrase": null,
"type": "D-yes-or-no",
"options": [
"yes",
"no"
],
"collected": false,
"always_ask": false,
"required": "no"
}
]
}
}
}
}After the required data has been captured it is passed to a set of rules deployed to IBM Automation Decision Services. The rules figure out what the journey needs to do next and will return one of two potential outcomes:
- Details of the next data item to collect
- Journey to “jump” to to fullfil customers needs
The outcome from the rules is used to update the data collection configuration JSON. This is then passed back to watsonx Assistant to execute. So if the customer states that their “payment_mechanism” was a “card” the configuration JSON would be updated to mark the “payment_target” variable as required. When the end of a collection path is reached the target journey to “jump to” is set in the “action” section.
In addition to this stepwise collection of information the customer could provide a set of information as part of the initial utterance. For example they may ask for a refund as follows: “I need a refund for a card payment I made to you”. In this case the framework “sweeps” the utterance for “potentially required” information and stores it in the journey memory area. This marks the data as “collected” in the configuration JSON. All the collected data is passed to the rules to process. In this case the rules will direct watsonx assistant to as “if the payment was suspicious” skipping the need to ask for the “payment_mechanism” and “payment_target” which were provided in the initial utterance.
With the technical side of the solution addressed we started to look at how to create the rules. The focus was to make this simple such that it could be easily used without the need to understand how to actually write rules in IBM Automation Decision Services. The approach we landed on was to enhance the tool we created to capture journey definitions. Here we added the capability to describe a “dynamic” jouney visually as a “flow”. An exmple of this is shown above. The tool we were building on already manages the defition of data types, variables and journeys. The “flow” tool used this information to support a “visual construction” approach where variables and journeys are added to the canvas and wired together. For a variable the potential “values” of the variable are represented as points a wire could be drawn from. In situations where the requirement is purely to collect the data there is an “any” option. Let's look at this step by step.
First we create a journey
We are then presented with the initial “empty” canvas.
We start by collecting the payment mechanism. To do this we select the “Data Collection” option and use the “search” field to find the question that asks for the information we need. We select it and then click add.
The canvas is updated to show this element along with potential values which we can draw wires from.
To define the next question to ask if “card” is specified as the “payment mechanism” we drag the circle next to the “card” data option and “drop” it on the canvas. This displays component selection pane.
From here we select “Data Collection” and add the next question to ask. If we want to define a “jump to” for a journey we follow the same steps but select “Journey”
The selection method for a journey follows the same approach as “Data Collection” [you can search for the journey you need and then select it].
A journey (at least currently) represents the end of the “flow” and hence no follow on wire points are shown.
When the full jouney has been defined we have tree representation of the “flow” held within the tool. The tool the uses this to generate the rules to be deployed to IBM Advanced Decision Services along with the configuration JSON to be used by the “Natural Conversation Framework”.
This approach provides a rapid way for business people to describe complex journeys which can rapidly deployed for testing [in our testing we were able to define, generate and deploy and journey with 40 potential questions within 30mins].
That concludes this post but in my next post I plan to cover how we are using a Large Language Model to enhance the extraction of information from customer responses.
