Virtual Data Models: turn thousands of calls into one structured roll-up
Virtual data models let Rig read through every sales call, support ticket, or transcript you have, pull out the things you care about, and save them as a clean, structured table your team can query. It is built for customer success, sales, and support teams who sit on large volumes of conversations and want reliable insights out of them, not a best guess.
The problem it solves
Large language models are very good with a handful of documents and very bad at large volumes of text. Once you point a model at hundreds of transcripts, its context window fills up and it stops paying attention evenly. Ask it to find the themes across 400 support conversations and it will read a random subset, weight them unevenly, and give you a different answer every time you run it.
The fix for a probabilistic problem is more deterministic data work. Instead of asking the model to hold every conversation in its head at once, Rig summarises each conversation into structured fields, saves them in a table, and then runs ordinary data queries over that table. You get an answer that reflects the full picture of every call, not a sample of them, and it comes out the same way each time.
How virtual data models work
A virtual data model is a step you add inside a Rig workflow. It works in three moves:
- Pull the raw data. The workflow starts from your conversations, tickets, or calls, triggered on a schedule or by an API call, and picks a primary key to work on, for example a conversation ID.
- Summarise row by row. Rig goes through the data one record at a time, applying a prompt you write. For each call it pulls out exactly the fields you ask for: a key quote, the sentiment, the churn risk, the churn reason, and anything else specific to your business. Those fields become a new, aggregated model.
- Query the summary. Because the model is now structured, the workflow runs a normal aggregation over it, then hands the result to a report or dashboard. The analysis happens on the tidy summary, so it covers every call rather than a sample.
You decide whether the model is saved. Give it a name, like support intelligence, and Rig keeps it so you can top it up each day instead of rebuilding the whole table. Leave the name blank and it lives only for the length of that one run, then disappears.
| call_id | sentiment | churn_risk | meddpicc_gap |
|---|---|---|---|
| C-4012 | Negative | High | Economic buyer |
| C-4013 | Mixed | Medium | Decision criteria |
| C-4014 | Positive | Low | none |
An example: support intelligence
In the walkthrough above, a workflow runs across 400 customer support conversations. The virtual data model reads each one and pulls out the key themes plus the data categories the team cares about, then rolls them up into a single view. From there a dashboard ranks the themes by churn impact and financial risk.
The output is a roll-up you can act on: categories like unauthorised transactions and transfers not arriving, each one summarised across every conversation, with representative quotes and the risk attached. That is the kind of report a head of customer success can read top to bottom and trust, because it was built from all the calls, not a lucky handful.
For technical audiences
For technical audiences
Think of a virtual data model as a materialised view created in flight inside the workflow. Under the hood Rig builds a DuckDB materialised view from the row-by-row LLM summarisation, joined on the primary key you select.
That view can be persisted to the database, or stay disposable and run in process. If you leave the model unnamed, it never lands anywhere: it exists only for the duration of the run, in memory, and is thrown away when the workflow finishes. If you name it, Rig persists it so it survives across runs.
A saved model loads and unloads from Postgres as needed. On each run Rig hydrates the existing model from Postgres into DuckDB, appends or updates the new summarised rows, and writes it back, so you incrementally top it up day by day rather than regenerating the whole table from scratch. Downstream aggregations are plain SQL queries against that view.
Build one yourself
You do not have to assemble any of this by hand. Virtual data models are live today, and Claude can build the whole thing for you through the Rig MCP. Just tell it to build a virtual data model to summarise your transcripts or your calls, and it will wire up the workflow, the summarisation prompt, and the dashboard.
If you get stuck or want a hand building your first one, the Rig team is happy to help. Drop us a message in Slack and we will build it with you.