BigQuery integration
Maximus reads the tables and views you expose in BigQuery over a read-only connection, and reports the adoption signals it derives from them on the account timeline. The connection carries the Adoption checkpoint: reading the customer's own account model beside Maximus's product telemetry tells a real usage dip apart from a change in one of the two definitions of active, and checks seat activation against the seats the customer's own reporting counts.
BigQuery is one of the systems Maximus reads to run the Adoption checkpoint. Below: the exact objects it reads, how the connection is made, and what runs once it is live.
- Category
- Data
- Lifecycle checkpoint
- Adoption
- Access requested
- Read-only by default
- Write access
- Opt-in per action
Maximus reads your whole stack.
The exact objects and fields. This is the whole of what Maximus reads from BigQuery — a list, not a claim about a category of tooling.
| Object | Fields read |
|---|---|
| The tables or views you expose to Maximus | the column your rows identify an account by, the column they identify a user by, the usage or activity the row records, the date the row records it on |
Two-way sync with your CRM. Read access to everything else. No rip-and-replace.
Connect BigQuery
Four steps, and the first one is an OAuth handshake with read-only scopes. There is no import to run and no data model to migrate. Least-privilege integrations: read-only scopes by default; write scopes opt-in per action.
Step 1: Connect BigQuery
OAuth into BigQuery. Read-only by default, and most teams see their first risk scores within one business day.
Step 2: Map the lifecycle
Maximus builds a checkpoint timeline per contract — onboarding, first value, adoption review, QBR, renewal window, expansion trigger.
Step 3: Let the agents run
Agents monitor every signal, draft the follow-up, open the Jira ticket, brief the CSM in Slack, and escalate what actually needs a human.
Step 4: Report on revenue
NRR, GRR, logo and dollar churn, renewal forecast by confidence band — exportable, auditable, board-ready.
How BigQuery data reaches the lifecycle
Where the data goes after the handshake, and where it stops.
- SourceBigQuery — Data.
- Read path1 object and 4 fields, read with read-only scopes.
- CheckpointAdoption, on the account's lifecycle timeline.
- ActionAgents run the plays below: they draft the follow-up, open the Jira ticket, brief the CSM in Slack, and escalate what actually needs a human.
Five agent plays that run on BigQuery
Five of the prebuilt plays that run on this data, named as they appear in the product. Each one is a checkpoint, an owner, a deadline and a defined exit — not a notification.
Onboarding chase
Runs the onboarding project and its milestone SLAs, so a slipping step is chased the day it slips (§5 B.13).
Adoption dip
Fires on the day-30 adoption dip, with an owner, a deadline and a defined exit (§4).
Ticket-storm escalation
Routes the escalation by severity, segment or ARR band, and opens the Jira ticket with the context attached (§5 A.8–A.9).
Renewal prep
Runs the 180/120/90/60/30-day renewal countdown plays and auto-drafts the QBR deck in your brand voice (§5 B.12, A.7).
Expansion signal
Turns an expansion trigger into a play, with the evidence attached (§5 B.11).
Every run is logged — each action, its input, its output and the reasoning trace behind it — and approval gates are configured per action class (§5 A.5).
What Maximus is allowed to touch in BigQuery
Least-privilege integrations: read-only scopes by default; write scopes opt-in per action. Write access is granted by you, per action, not by the install.
| Object | Access requested | Write access |
|---|---|---|
| The tables or views you expose to Maximus | Read | Not requested by default |
SOC 2 Type II: In progress — not yet verified · GDPR and India DPDP: In progress — not yet verified · SSO/SAML · Data residency in United States, European Union, India
BigQuery and the customer lifecycle
The narrative this page carries about BigQuery and the Adoption checkpoint.
The adoption number your team already reports
Adoption starts after time to first value, is owned by the CSM, and exits on two measures: target seat activation and depth of use. Its recurring check is the monthly adoption-dip play, and that play fires on a drop. The first question after it fires is rarely whether usage fell — it is whether the number the customer reports and the number Maximus reports are counting the same thing.
BigQuery is where the second number tends to live. A data platform team already keeps the account model there: which entities belong to which customer, which of them the contract covers, and which seats were in use in the period the customer will point at. That model changes without a release, and reading it beside the product's own telemetry is what turns a dip into a decision.
What warehouse context adds to an adoption check
Seat numbers read from the customer's own model answer a question a licence report cannot: not how many seats exist, but how many were in use in the period under discussion. Read next to the contract dates, the same rows put the adoption number and the renewal countdown on one timeline, so the renewal conversation opens from the period the customer's own reporting used rather than from a second set of figures.
Where the two definitions have to agree
An adoption dip only one side can see is the expensive kind. The CSM sees a drop, the customer's dashboard does not, and the conversation becomes an argument about whose query is wrong. Reading both from the platform the customer already trusts, and landing the comparison on the account timeline, keeps the disagreement about a definition rather than about two dashboards.
What this connection does not do
- It does not write into the warehouse. The objects Maximus writes — plays, checkpoints, health scores — live in Maximus.
- It does not read tables or views outside the ones your administrator approves.
- It does not move your data out of your own cloud account.
Connecting it
Maximus reads with read-only scopes by default, there is no migration to run and nothing to move, and the connection is live the day your BigQuery administrator authorises it. The read surface starts at the tables and views your administrator exposes and stops where this page says it stops: nothing else in the project is read, and no column outside the list above is requested.
Questions about BigQuery
The three things buyers ask about this connection before they sign.
Where BigQuery fits
The integrations near this one, then the pages a buyer reads before buying.
- Snowflake integration
How Maximus reads product usage, billing and contract tables from Snowflake, and what that adds to adoption and renewal reporting.
- Segment integration
The Segment sources and events Maximus reads, how product usage reaches the health model, and what defines the first value milestone.
- Gong integration
The Gong objects and fields Maximus reads, how call evidence ends up in a business review, and what it does with a champion who goes quiet.
- Pricing
$189 per seat per month, $170 when billed yearly — every feature, every integration, unlimited managed accounts.
- Trust and security center
SOC 2 Type II: In progress — not yet verified · GDPR and India DPDP: In progress — not yet verified · SSO/SAML · Data residency in United States, European Union, India
Stop reacting to churn. Start running the lifecycle.
Most teams connect their stack and see their first risk scores within one business day. There is no implementation fee.
14-day money-back guarantee.