2 min read
In this technical blog, we explore how accessing databases can unlock the next level of automation of conversational processes built on the Spixii CPA platform. Gaining access to databases should not be taken for granted, as it requires a robust security framework which, if missing, requires heavy support for the software provider, which can not only involve large costs but, most importantly, slows down continuous improvement and innovation.
Transparency
One might argue that SaaS platforms often lack transparency.
They are like backboxes, hard to configure and protected by several layers of IP and secretness. In particular, it's barely possible for users to get access to the central SQL Relational Database Management System (RDBMS) of the SaaS platform: software suppliers rarely allow direct access to the RDBMS for security constraints (and sometimes to avoid the client seeing some low quality and inaccurate database objects, which might carry unpleasant surprises).
At Spixii we always believe that true automation demands transparency and clarity throughout all steps of any process, especially in regulated industries like finance and insurance. For this reason, we had no concern about exposing directly to our customers the Python source code of their conversational processes in the Function Manager module.
This is great, but not enough.
We created a segregated database for each client but, until today, it was hidden behind some access layer, which is not familiar outside of the Spixii developers' team. It's known that many software companies take advantage of the structural inaccessibility of their RDBMS to ask their clients for more applications and more maintenance tasks: this increases the cost of the solution drastically and pulverizes the number of tools used by the operation team of the client, generating inefficiency and constant frustration.
For our Advanced and Premium clients, we now offer direct access to their RDBMS with the versatile and enterprise-designed Python framework SQLAlchemy.
SQLAlchemy is an Object-Relation Mapping (ORM) that allows your script built on the Function Manager to access and manipulate database tables directly with Python objects.
For example, it's possible to retrieve all the variables collected in your process, like name, surname, policy id, etc ... with the following code fragment:
But the native SQL language is also available: a simple SQL query can be executed and the result fetched and manipulated.
For instance, the same result of the previous example can be obtained with the following SQL query:
Given the total control of data on the database through Python ORM objects or native SQL queries, it's possible to expand further the automation power of the Spixii CPA platform. In particular, in the Function Manager of the Spixii CPA platform, a user can:
The following examples should give a better understanding.
Example 1 - Improve the UX on recurring users
Let's consider a typical claim FNOL (First Notification of Loss) journey, starting with the authentication of the policyholder who is about to notify of a crack on his mobile screen. Unfortunately, the phone has been left at home, and the policyholder can't submit any picture of the broken screen. Therefore the conversation is dropped, and no notification is sent to the insurer.
Once back home, the policyholder restarts the chat: once authenticated, the conversational process can be instructed in the Function Manager to look up the previous conversations and recognise if the user is a recurring one. If so, replies already given can be retrieved without asking them again, and the process can proceed from the last unanswered question.
Example 2 - Real-time AI best decision
A quote & buy journey chooses randomly between two conversational paths: they have different wording, but both capture the same variables and bring new customers to buy the same insurance product.
The SQLAlchemy functionality can be used to count the number of customers that eventually bought the product split by the chosen path and then automatically redirect the new incoming conversations to the most performant path.
In other words, the conversational process learns from past conversations and automatically takes the optimal decision to maximize the result.
As mentioned in the introduction, exposing the database to the client requires a deep understanding of the security implications and performance constraints that might be impacted by many queries running simultaneously.
For this, we leverage the combination of two enterprise reliable frameworks:
OVPD enforces security directly on the database level, which means that any application or user can't bypass security policies. Also, it guarantees data segregation on multiple instances of the platform.
As we can see, accessing the database takes the flexibility of the conversational process to the ultimate level.
Developers, business analysts and operation departments can now access their database straight without dealing with wraps of software layers. And business managers can allocate their budget to improve the services instead of wasting it on more applications.
Let's start your journey on the Spixii CPA platform with your first 14 days free trial now!