Tutorial session · Onboarding course
Getting started with Virtual Data Models
A hands-on companion for your first VDM: the prompts to use, a ready-made plan for a 45-minute working session, and a gallery of recipes for B2B and B2C teams. For the concepts and the technical detail, start with the Virtual Data Models guide.
A VDM in one breath
A virtual data model is a reusable table Rig builds for you: it reads your data and has AI read every single row, filling in the columns you care about. Picture an assistant who listens to all of your calls — thousands of them, in any language — and quietly fills in a scorecard for each one. That scorecard is a VDM.
If you've used Clay for prospect enrichment, the motion will feel familiar: a table where each row picks up new columns as enrichments run across it. A VDM is that same motion turned inward. Instead of a third-party data provider filling in a company's headcount, it's an LLM reading your own internal data — a transcript, a ticket thread, a contract — with a prompt you wrote, and filling in the fields that matter to your business.
How a VDM works
The whole thing is one loop. Rig pulls the source data, walks it row by row, and applies your prompt to each row to fill in new columns. The enriched rows land in a single structured table you can query, chart, and build on — and the relationship with data apps runs both ways.
You don't build it — you ask for it
There is no configuration screen to learn. You describe what to look at and what to pull out, check a quick draft, and tell Rig to save it. A first VDM is three messages:
💡 Start small, then expand.
Ask for 20–50 rows first. It's quick and cheap, and it lets you tune what gets pulled out before running the whole back-catalogue. Once it's reading rows the way you want, say “now do all of them.”
What makes a good ask
- One clear thing per column. “Did the rep offer a discount?” beats “how was the pitch?”
- Prefer yes/no answers or a short fixed list of values. They're easy to count and chart later; free text is for the evidence column.
- Say what counts. “An objection is a real concern, not just a question.” Definitions in the prompt become consistency in the table.
- Give an example for judgement calls. One good and one bad example in the prompt settles most ambiguity.
- Ask for the evidence. Include a column for the exact quote or passage behind each judgement, so anyone can audit any row later.
A 45-minute session plan
This is the structure we use to onboard a team onto VDMs in one working session. It assumes one person driving Rig on a shared screen, and it works equally well remote or in a room.
| Time | What |
|---|---|
| 5 min | What a VDM is & why it matters |
| 10 min | Explore a VDM built on their data beforehand |
| 10 min | Build one from scratch — just by asking |
| 10 min | Map it to what the team wants to measure |
| 5 min | Keeping it fresh + next steps |
| 5 min | Questions & buffer |
Before the session
Three bits of prep make the difference between a demo and a working session: connect the data source in advance, pre-build one VDM on the team's own data as the star example, and ask for their scoring rubric ahead of time — the exact questions they'd want answered about every call, ticket, or document. Those questions become the columns you build live.
Recipes for B2B teams
Each recipe is a starting point: the shape of the table, the columns it fills in, and an ask to open with. Swap the column names for the language your team already uses.
Every sales call becomes a structured row: what the buyer is actually trying to solve, what stood in the way, and what happens next. Feeds pipeline reviews and rep coaching.
“Read each sales call transcript. Tell me the problem the buyer is trying to solve, any objections raised, competitors mentioned, whether a concrete next step was agreed, and quote the most revealing thing the buyer said.”
Every support ticket and QBR note tagged with its theme, severity, and churn signal — then rolled up per account so CS sees the pattern, not just the latest ticket.
“For each support ticket, classify the theme, rate severity, flag any churn signal (a real risk indicator, not routine frustration), list feature requests, and quote the evidence.”
A second-stage VDM that reads other tables — usage trends, ticket sentiment, invoice status, exec engagement — and produces one scored row per account with a reason and a recommended action. VDMs can read other VDMs, so this stacks on the two recipes above.
“For each account, read its usage trend, recent ticket sentiment, invoice status, and meeting notes. Score its health 1–10, name the top risk, explain your reasoning in one sentence, and recommend one action for the CSM.”
Point it at a folder of contracts or SOWs and get one row per document: the fields finance and legal keep re-reading PDFs to find. Feeds renewals and invoicing dashboards.
“Read each contract. Extract the customer name, signing date, headline value, billing cadence, payment terms, and renewal or end date. If a field isn't stated, say 'N/A' — don't guess.”
Recipes for B2C teams
A scorecard for every support conversation, across thousands of chats and calls in any language. Managers coach from the lowest-scoring rows instead of sampling at random.
“Score every support conversation: did the rep greet and introduce themselves, correctly diagnose the issue, and resolve it? Rate empathy, check the refund policy was followed, and record how the customer felt at the end.”
Classify orders, reviews, or social mentions by the occasion driving them — holidays, weather, gifting, life events — so demand spikes get an explanation and next season gets a plan.
“For each order with a gift note or review, work out the occasion behind the purchase (holiday, birthday, new baby, weather, none) and whether it reads planned or impulse. I want to see which events drive each product line.”
The real reasons customers leave, clustered from free-text survey answers, chat logs, and call notes — in their own words, grouped so the top three are unmissable.
“Read every cancellation conversation from this quarter. Classify the primary and secondary reason for leaving, judge whether the cancellation looked saveable, and quote the customer's own words.”
Every review and NPS verbatim tagged with what it praises, what it complains about, and what it asks for — rolled up per product so recurring themes surface automatically.
“Read all reviews and NPS comments per product. Tag the recurring praise and complaint themes, pull out feature requests, and quote one representative line for each theme.”
Good to know
- Nothing's permanent until you say so. Every VDM starts as a draft you can throw away. Leave it unnamed and it lives only for that run; name it and Rig keeps it.
- Keeping it fresh is cheap. Rig only re-reads rows that are new or changed, so a daily top-up costs a fraction of the first build.
- Your data stays yours. VDMs live inside Rig; nothing is written back into your warehouse unless you ask for it.
- No SQL required. Query the finished table in plain English, and if a number ever looks off, just ask — the evidence column means every judgement can be traced back to its source.
Ready for the deeper mechanics — persistence, incremental refresh, and how the tables work under the hood? Head back to the Virtual Data Models guide. And if you'd like us to run this session with your team, drop us a message in Slack — we'll bring the star example.