How to: Auto Solve Workflow Template

A common customer service task is to close conversations with clients when they have been unresponsive for a certain amount of time. Creating a few workflows inside of Kustomer can help automate this process for your organization.

Before moving on it is recommended that you have experience building workflows in Kustomer, or have read these three help center articles, Workflows Overview, Callable scheduled workflows, and Test and debug Workflows by viewing logs. For our example we are going to create a flow that will send two messages. One after 4 days from the time the conversation is snoozed, and another 8 days from the time the conversation is snoozed. The flow will also close the conversation by setting a custom required attribute to a specific value indicating that this conversation was closed by the automation. 

The first thing to build when creating callable workflows are the callable workflows themselves. This makes the process of creating the workflow that will be calling the other workflows more seamless. Create two workflows titled “Auto Solve Workflow Template Part 2” and “Auto Solve Workflow Template Part 3”. Make them callable, and give them the required input parameters of “conversationId” and “snoozeCount” with their types being string and number respectively. Now we can get to creating the first workflow that will set the chain in motion.

To start these workflows we’re going to create a new workflow titled “Auto Solve Workflow Template Part 1” and use a “Conversation Updated” trigger. A good practice is to have a dedicated Snooze substatus configured that will be the determining factor about if this conversation is eligible to be automatically closed. You can create that sub status by heading to Settings > Workspace > Conversation Status under the Snooze tab. Now we can use the change in the conversation status along with the change in substatus relationship as the conditions for our automation to run. To do this we are going to take advantage of the “Changes” attribute on the conversation updated trigger. This attribute allows us to target anything on the conversation that has been changed and will make sure the rest of the workflow only runs when we want it to! After the first condition we will then add two actions. Both action apps are “Scheduler” and the action events are “Schedule a Workflow”. In the first action we will choose “Auto Solve Workflow Template Step 2”, set a relative time to run in 4 days, set the Conversation Id to be “/#steps.1.id” and the Snooze Count will be “/#steps.1.changes.attributes.snoozeCount.after”. The second action will be the same attributes with the only difference being that the time will be 8 days. If these are configured correctly you will see the number 1 on a blue circle background with the associated attributes filled in. 

Now that we have the trigger workflow created, it’s time to build out our callable workflows with all the steps they need. Both will look very similar with the only difference being in the “Part 3” workflow where we will add some conditional logic that will mark the conversation as complete. When these workflows are called we want to make sure that the client has not followed up. We can do that by having a condition that will check to see if the conversation status is still snoozed, and that the snooze count on the conversation is the same as the snooze count that was passed in to the callable workflow. We can find the associated conversation by using a “Conversation: Lookup (By Id)” workflow action using the conversationId we passed in to the callable workflow. The condition will compare the current snoozeCount of the conversation we find from that action to the snoozeCount we passed in to the callable workflow, and will check to see if the conversation’s status is snoozed. If those conditions are true we know the client has not followed up in the past few days and the workflow should continue, if the condition doesn’t pass the condition will stop the workflow. 

Next we will create a condition branch that will determine if the conversation was on the email channel, and has the appropriate meta-data but if it doesn’t we still want to try and send a message to the end customer. Ideally, we want to send an email to the last email address who sent a message. By using the action app “Postmark” and the action event “Message Send” we can send an external email and will create a message in Kustomer on the timeline (If using the Gmail app in your org use that action app instead). Now if the meta-data/channel condition evaluates to false we still want to try to send the customer a reminder that we are waiting on their reply. On the right branch we will make a condition that always evaluates to true by checking if the string “true” exists. We could use any string of characters, but our convention is to use the word true. Immediately after that condition we want to see if the customer has an email, and if they do not, we will make a branch that will create a note on the conversation so the agent can take appropriate action. To find the customer’s information we can use the Customer associated with the conversation we found earlier by “Customer: Lookup (By Id)” action and taking the “customer” attribute of the conversation. Then we can use another condition to see if that customer has an email address by accessing the emails attribute. Because the emails attribute is a list of values we will try to get the first in the list. We will access that with the accessor “emails.0.email” which will take the “emails” array, get the first item, “0”, and get the “email” of that item. If it does not exist on the other branch we will make a note and reopen the conversation to let the assigned user know that the conversation is not eligible for the automation. This is where the similarity between the two workflows ends, and the final workflow will get some extra steps.

In the last workflow we want to end each branch with a conditional branch checking to see if any/all of the required custom attributes are set. If they are set we can use a conversation update step to automatically close the conversation. If they are not set we need to update the custom attributes with a value before we mark the conversation as done.

The information necessary to configure in the workflows for your organization is in ALL CAPS in the Github Gists. You will need to configure the first workflow with the time, and the callable workflows that are part of this chain. For that reason it is recommended that if you are copying and pasting you copy the callable workflows first. 

Gists:

Auto Solve Part 1: https://gist.github.com/michaeliacono6/5e8fb69b1bc24cb79ac1ece1d7d68232

Auto Solve Part 2: https://gist.github.com/michaeliacono6/b4229a6a9a11a96376d3246ca0d4ce4f


Auto Solve Part 3: 

https://gist.github.com/michaeliacono6/b2e72e67988abeacd12f93d683c8d9ec