--- title: "VDM tutorial — getting started with Virtual Data Models" description: "A hands-on onboarding course for Virtual Data Models: the prompts to use, a ready-made 45-minute session plan, and enrichment recipes for B2B and B2C teams." canonical: "https://rig.so/guides/vdm-tutorial" format: markdown --- Search guides, references, playbooks…⌘K Browse guides 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](https://rig.so/guides/virtual-data-models). ## 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. Get the data Calls, tickets, reviews, documents, CRM rows — anything with one row per thing you care about repeat for every row AI reads the row with your prompt “Did the rep offer a discount? What objection came up? Quote the customer’s exact words.” New columns get filled in topic · sentiment · risk · key\_quote · … — then it moves on to the next row The virtual data model A clean, structured table — name it to keep it, query it like any other table Data app / dashboard Roll-ups, scorecards, coaching views — built on every row, not a sample Flowchart: source data flows one row at a time into a loop where an AI reads each row with your prompt and fills in new columns, repeating for every row. The enriched rows land in a single virtual data model table, which feeds data apps and dashboards — and data apps can write inputs back into the VDM. ## 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: You Read our support conversations from the last 90 days. For each one tell me: the main topic, whether the customer's issue was resolved, how the customer felt at the end, and whether we offered a refund. Start with the first 30 so I can check. Rig Here are the first 30 conversations scored that way — take a look. Did I read them the way you'd expect? You Close. Two changes: make “topic” one of billing / bugs / onboarding / other, and add a column with the customer's exact words. Then run it on everything and save it as support\_qa. 💡 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 | Why | | --- | --- | --- | | 5 min | What a VDM is & why it matters | The one-breath version, with an example from the team's own domain. | | 10 min | Explore a VDM built on their data beforehand | A live table to slice together — filter it, chart it, follow one row back to the raw source. | | 10 min | Build one from scratch — just by asking | Draft on 20–50 rows, check the output, tune the prompt, save it. The whole loop, live. | | 10 min | Map it to what the team wants to measure | Their rubric, in their words — turn each question they care about into a column. | | 5 min | Keeping it fresh + next steps | How it tops itself up, who can query it, and one thing to try this week. | | 5 min | Questions & buffer | Anything on their mind. | 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. Sales call enrichment 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. Columns it fills in buyer\_problemobjectionscompetitor\_mentionsnext\_step\_agreedmethodology\_gapskey\_quote Try asking “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.” CS & account enrichment 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. Columns it fills in themeseveritychurn\_signalfeature\_requestssentimentevidence Try asking “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.” Account signals → health score 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. Columns it fills in health\_scoretrendtop\_riskreasonrecommended\_action Try asking “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.” Contract & document extraction 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. Columns it fills in customersigned\_datecontract\_valuebilling\_cadencepayment\_termsrenewal\_date Try asking “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 Support rep QA 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. Columns it fills in greeted\_properlydiagnosed\_issueresolvedempathypolicy\_followedcustomer\_sentiment Try asking “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.” Seasonality & event analysis 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. Columns it fills in occasiondriverproduct\_categorygift\_purchaseplanned\_vs\_impulse Try asking “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.” Cancellation & refund reasons 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. Columns it fills in primary\_reasonsecondary\_reasonwas\_saveablecustomer\_words Try asking “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.” Review & NPS mining 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. Columns it fills in praise\_themescomplaint\_themesfeature\_askswould\_recommendquote Try asking “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](https://rig.so/guides/virtual-data-models). 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. Was this guide helpful? Yes No --- - [This page as HTML](https://rig.so/guides/vdm-tutorial) - [Site map for language models](https://rig.so/llms.txt) - [API and agent documentation](https://rig.so/developers)