Traditionally, workflows have been way a to present simple information in an organized and logical manner. They are very helpful in communicating the structure of a complex system or an organizational hierarchy. However, that is all they do; statically display visual information to another person. One of the main goals when originally developing the SpiceCSM Process Workflows was to be able to present complex and dynamic information. We wanted to give users with a specific skill set the ability to convey their knowledge to a large number of less skilled users in a structured, dynamic and logical way. Additionally, we needed the ability to import data into the process so that the less skilled user did not have to use a separate system to look up information. Those original requirements gave the process workflows an enormous amount of power and flexibility. As the years passed, we saw the way processes were being used had evolved in ways we had never imagined when originally designing the SpiceCSM Process Workflows.
Our process workflows are slightly different than traditional workflows. The information for the process workflow is stored within the nodes (the building blocks of a process) and require a 'reader' to display the information to the end user. The main reader that our customers use is located in our Unified Agent Interface and is normally used in a relatively simple way; to visually convey expert level subject matter to less skilled users. This is still a very powerful way to use the process workflows; to help diagnosis issues with anything from people (health care) to computers. Processes used in this way are mainly setup in a question and answer format in an attempt to intelligently route the process down the correct path to resolve the issue. When using this approach in Contact Centers, it is a great way to standardize a support process and improve first call resolution.
Like with any application, as our customers used the process workflows we could see more and more ways we could improve features and functionality. The SpiceCSM Embedded Reader was born out of a need to display a process outside of our Unified Interface. This gives our customers the ability to embed the process workflows directly into their website or web application. If a web application can display an iframe, then it can display a SpiceCSM Process Workflow. Some of our Contact Center customers are using this in a similar manner to a self service portal. Their clients can go right to their website and click through a support process without having to talk to an agent.
As a programmer, I find the more exciting application of the Embedded Reader is using the process workflows as a development environment. We currently have someone using the Embedded Reader to display a sales process. A customer can go to their website, click through a workflow, fill out form data and the process submits the data in the background to their billing system. The main advantage of this is that the process workflows are low-code; just drag and drop the nodes and fill in the desired information. There was still some minor programming needed in this example. Someone had to write the code to interact with the billing system but using the workflows reduce the number of lines of code from potentially a thousand lines to only a few hundred. The specialized nodes (Generate Email, for example) take the headache out of programming so the focus can be on the overall process.
After seeing the value of the process workflows as a development environment in the Embedded Reader, the logical next step was to create the Automated Reader. This reader executes Automated Processes which require no human interaction. The addition of server nodes (Request and Response) lets the process workflows behave like server programming languages, without the need to actually write code. The process has access to the GET and POST variables, headers, request method and request path. Automated processes can be created that act like REST APIs; routing based on the request method and the GET/POST variables to return the desired information. The Response node lets you select from the standard response codes and return appropriate data for the selected content type.
Automated Processes can be an endpoint for a web call. For example, I completed a seamless integration with our sales and marketing software using Automated Processes and the SpiceCSM Automation Suite. The integration uses OAuth authentication and webhooks. OAuth requires endpoints for saving the access and refresh tokens while the webhooks call the specified URL with POST data. The same process URL was used for all of the integration points. This particular sales and marketing application did not have the ability to send an email when a lead was added or updated (contract value, expected close date, etc). The was very easy to accomplish with the process workflows using the Generate Email node. We also wanted to save the information for the lead so we could do our own custom reporting. So along with sending an email, we update our database with the lead information.
For our custom reporting, we hopped on the voice bandwagon and created an integration with Amazon Alexa. The integration consists of a single AWS Lambda function which executes an Automated Process. That process gets the report data from our database and formats the information to be read back by Alexa. Now we can ask Alexa for 'the total pipeline' and 'number of deals closed' as well as a number of other valuable data points. Being able to visually create a low-code process workflow that acts as the back end for Alexa makes developing Alexa skills extremely easy.
We know we are only scratching the surface in terms of what is possible with the SpiceCSM Process Workflows. Our original desire to display dynamic expert level information has evolved into a low-code front and back end with the Embedded Reader as well as a visual back end development environment with the Automated Reader. Only time will tell what comes next.