Empowering intermediaries with conversational process automation

3 min read

All Posts

Access to your own SQL database

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.

You can use ORM objects or native SQL queries

For our Advanced and Premium clients, we now offer direct access to their RDBMS with the versatile and enterprise-designed Python framework SQLAlchemy.

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:

orm

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:

sqlnative

Why is it so important?

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:

  • Manipulate any accessible table of the database using Python objects or SQL queries
  • Look up data from other conversations belonging to your organization, which is particularly useful for identifying optimal paths
  • Fetch advanced statistics generated in real-time by our Data Model and make decisions based on them, including customer's psychometric and behavioural insights
  • Define custom database objects and tables accessible only within your organization and more

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.

How we can do it in a secure way?

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:

  • Oracle Virtual Private Database (OVPD)
    OVPD enables the creation of security policies to control database access at the row and column level. OVPD adds a dynamic WHERE clause to a SQL statement issued against tables, views, synonyms, or any other database object.

    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.

  • Fine-grained Access Control (F.G.A.C.)
    F.G.A.C. is a sophisticated paradigm for deploying transparent security policies on tables, views, synonymous and other objects, which the database will use to "rewrite" the predicate of the submitted query. It is a scalable and reliable mechanism for implementing security straight at the database layer and requires no change to the applications, APIs, web tools and other products that depend on the database.

Conclusion

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!

spixii ebook

Grab your Spixii eBook free copy!

How to enable true self-serve in insurance

➡ What are the main pain points in the insurance customer journey?

➡ What is self-serve and what technologies are available?

➡ How is Spixii improving operations and customer experience at once with Conversational self-serve?

Recent Posts

Empowering intermediaries with conversational process automation

3 min read Intermediaries such as financial advisers and brokers are often the first point of contact for banking, wealth, life and retirement product...

Read more

Access to your own SQL database

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...

Read more

Why self-serve improves the customer experience

8 min read   Before any discussion about how insurers can enable true ‘self-serve’ in the insurance industry, it’s imperative to define what it means....

Read more

How to unlock self-serve through Conversational Process Automation

8 min read   To avoid any loss, automation needs to better serve the insurance customer and not become a barrier to communication with the insurance p...

Read more