Data flowing in
CRM, sequencer, dialer, calls, enrichment, marketing and product data, kept current in BigQuery, Snowflake, Postgres or one we stand up.
Your CRM, sequencer, dialer, calls, website, product and spend in one warehouse you own, defined so AI reads it the way your best operator does.
Which touches create meetings, why lead flow dropped, what your best rep does differently, answered in minutes.
A meeting held means the same thing in every report and to every agent.
Built in your accounts by default. Every agent reads it, and the history stays when you swap a tool.
Illustrative layout. The first play's tables come first.
| Table | One row per | Comes from |
|---|---|---|
| accounts | Company, with fit, tier and owner | CRM, enrichment |
| contacts | Person, with role and persona | CRM, enrichment |
| touches | Email, call, meeting, page visit or ad click, from any tool | Sequencer, dialer, calendar, web, ads |
| sequence_runs | Enrollment, with why it ended and what happened after a reply | Sequencer |
| calls | Recorded call, with transcript and speakers | Call recorder |
| opportunities | Deal, with every stage change and its date | CRM |
| signals | Job change, funding round, hiring surge or intent topic | Signal sources, web |
| play_runs | Which accounts got the play and which were held back, fixed at launch | Set at launch |
One entry per stage and metric, in a repo you own. Every report and agent reads it first. Illustrative:
metric: meeting_held
means: A first meeting with a buyer at an ICP account that took place
counts_when:
- the calendar event has an attendee from the account
- a call recording exists, or the rep marked it held
excludes: reschedules, internal meetings, partner calls
reads_from: [touches, calls, accounts]
owner: RevOps| Question | Which part answers it |
|---|---|
| "What has this account seen from us, and what did they do?" | Tools and warehouse |
| "Where in the journey is this buyer, and what usually comes next?" | The model of how your business works |
| "What does our playbook say to do here, and does our strategy still hold?" | Playbooks and GTM strategy |
| "What worked for buyers like this, and what didn't?" | The model, plus play history |
| "Which accounts have a new reason to talk this week?" | Signals |
| "Where in the funnel are we losing the most revenue?" | Reporting through the connector |
CRM, sequencer, dialer, calls, enrichment, marketing and product data, kept current in BigQuery, Snowflake, Postgres or one we stand up.
Rebuilt from raw events. Why a sequence ended, and what happened after a reply.
Every stage and metric written once, in a repo you own.
Your team asks in its AI workspace, Slack or a coding agent. Every agent reads through one connector.
Custom apps and MCPsThis is step 1, Connect your data.
We build the tables the first play needs, then add more as later plays need them.
The loss tree and signal back-tests run on these tables.
Agents read it before they draft or update a record.
play_runs makes every read against comparison accounts possible.
The bootcamp builds what its first play needs. A fuller build is an Implementation.
Your CRM holds records. It doesn't hold the activity from your other tools, or the definitions AI needs.
Then we build inside it. The GTM tables and definitions sit next to your models, reviewed by your data team like any other change.
The tables the first play needs are built in the bootcamp's first week. A fuller build is scoped as an Implementation.
Whoever your warehouse permissions allow. We'll walk your security team through access before kickoff.
30 minutes. We'll tell you which tables would answer it.
Book a call