The Right Type of Authoring Environment

I would like to talk to you about authoring environments for Digital Care because they aren’t all born equals and there is often an assumption that, in order to create use cases, all you need is a dialog workflow editor to create a decision tree.

I won’t elaborate in this post on some of functionalities (covered in part in a precedent blog post or this one) such as:

• Personalization
• History
• Multichannel support
• Multilingual support
• No-code environment
• …

They are all relevant and important and should be part of your list of requirements if you really want to have the tools to succeed in your customer care digital transformation. Instead, I would like to focus on that notion of decision tree and why this is an over-simplification.

You have logic. You make decisions.
In one case, you apply the following steps – in the other, you apply these other set of steps and voila!

Not so fast.
The above statement is true except that the use cases are, oftentimes, extremely complex. This makes the great initial idea of a decision tree turn into a tentacular monster that no one knows how to maintain. Even in a no-code environment, only a handful of people will know where to find the information and how to make modifications.

To avoid creating an unmanageable mess, you will need a system that creates some hierarchy to organize your thoughts.

This is where Sweepr’s Multi-level Logic starts coming into play. Indeed, if your logic is not organized, you will end up with unwieldy flat workflows that are just a few steps above code. Sweepr introduces the notion of Clarifications and Resolutions. Clarifications are used to gather data about the issue and the customer’s context by querying backend systems, equipment in the house or asking direct questions to the customer while Resolutions are focused on the steps needed to apply a fix. On top of this, and to help you manage it all, Sweepr’s authoring environment is entirely version-controlled so you can roll back changes in case a mistake was made.

The other thing to consider is that in a big decision tree, the logic you create is not reusable. I am not only thinking about saving a function so it can be inserted at any point in the decision tree which is very important but requires planning and careful design. I am talking about the ability to apply an entire Resolution in multiple use cases and having it available to various parts of your organization.

A flat workflow is not ML-ready because ML models will not have a common inflection point to make their decision.

Finally, a lot of vendors claim that their system can learn from outcomes and use ML to optimize the choice of the next best resolution. However, a flat workflow is not ML-ready because ML models will not have a common inflection point to make their decision. For that reason, a lot of these solutions will require you to refactor your workflows in order to “turn on” ML. This is a huge endeavor to undertake and this is why Sweepr will make you implement within a paradigm that supports ML out-of-the-box. The Clarification/Resolution approach paired with a helicopter view of each intent will clearly delimit when you are gathering information and where decisions need to be made setting up the stage for multi-level logic.

Then, when you drill into the details for each individual resolution, you will be presented with  no-code decision trees that are completely modular in the sense that they can be swapped in and out and be prioritized in real-time using Dynamic Decisioning.

This layout will prevent your organization from implementing the “wrong way” and will also organically support ML and all your A/B testing needs.

As you can see, there is far more complexity in this topic than it first appears and you will need to carefully consider this in your platform choice. A dialog workflow editor is helpful but will not cut it when it comes down to it because it is designed to handle simple interactions.

Insist on multi-level logic if you want
a solution built for the future.