Support can be a thankless role. Support agents deal with the full spectrum of human reactions to “I have a problem and I need it fixed now!” When a case arrives, the race is on to solve that customer’s problem as quickly and efficiently as possible.

Agents are really data detectives 🕵️‍♀️ 

No matter what industry, a service agent needs to access data. The longer it takes for each agent to connect the dots, the slower resolution times and the fewer customers a team can support. 

Most data that support agents need originates from outside of the CX platform itself, be it financial, product or marketing related. A crucial driver of efficiency is bringing that data to an agent, not sending them on a hunt for information. 

But, what data do they need? 

💁‍♂️ There are two broad categories of data that a service team needs to answer different questions. 

Types of data 

Category 1: data that should exist on the ticket or case

For example, I’ve collected this user’s email but I need to know what company they work for, what timezone they are in, or what customer segment they are in. 
This data tends to have a one-to-one relationship with the person and it doesn’t change all too often. In the destination system, an object and field needs to be populated. 

Category 2: data that is related to my case, but it doesn’t belong in the CX platform

For example, transactions, payments, or product metrics and logs. 
This category tends to have a one-to-many relationship with a customer. A customer may have hundreds of payment or thousands of error logs. It means an agent is searching for a few rows from a dataset of thousands or millions. It also changes often. Not just the data itself, but the structure of the data. This is especially so when we start getting into SaaS product metrics that change often. It is awkward to fit this data onto a platform object or custom fields. 

How to bring this data to my agents? 

As companies modernise their data stacks they are centralising and modelling all data in cloud data warehouses like Snowflake, BigQuery and Redshift. Originally they tackled analytical use cases, but then people realised that they could actually send this single unified view of data out to applications instead of integrating each system point-to-point.

Overall, it simply doesn't make sense to store a copy of operational data like transactions on the target platform.

Category 1: Replicate data or Reverse ETL

Reverse ETL became the product category for this process of replicating data (think of it like regular ETL but from data warehouse to app, hence the ‘reverse’). 
Reverse ETL is the solution for the first category of data. A customer identifier, like an email, can be used to enrich tickets with fields from your data warehouse. These fields might have originated in 10 different systems, but modern tools allow you to to unify and model this data. 

Category 2: Real-time operational integration

The second category is more challenging. 
Overall, it simply doesn't make sense to store a copy of operational data like transactions on the target platform. You'll likely hit several roadblocks trying to replicate these large and changing datasets.

1. You can’t keep it fresh enough 
2. It’s too big for storage or API quotas 
3. Changing the integration creates a slow backlog of deleting and repopulating fields 

To solve these challenges, you need to do one key thing differently. You don’t load the data onto the target platform. This way:

1. Data is fetched on-demand and always fresh 
2. You reduce demand for platform storage & API limits 
3. You can change your mind about what data you show easily 

🔗 Read more about the evolution of integration architectures 🔗 

How does Omnata help?

Category 1: Push data

Omnata Push lets you load data from your Snowflake data warehouse to applications. It uniquely uses SQL functions run and managed within Snowflake, not in a middleware platform. You can easily integrate it into your dbt runs with pre-built packages.

Reverse ETL run as another SQL task

Category 2: Connect to data

Omnata Connect live-queries tables in your data warehouse directly from the target application. It returns the query to the agent view in real-time. You can create parent-child relationships between tables so agents can drill-down to granular records like Account ➡️ Orders ➡️ Shipping Updates. 
You can quickly and easily experiment with what data is most useful for agents. Perhaps you are changing fields or adding new ones, or changing what are the key product metrics to display. This can be done without the baggage of the previously loaded fields. 

Connect to related data without the challenges of replication

Customers use Omnata for use cases like pathology results in healthcare, real-time SaaS metrics for sales teams and bringing critical external data into priority support tickets.

Omnata Connect is available for leading CX platforms.

Find us on the:
Salesforce AppExchange
Zendesk App Marketplace