The team self-serve analytics setup checklist
Sixteen checks across access, context, visibility, rollout, and maintenance before you hand your Claude analytics setup to the team.
Setting up Claude for analytics happens in two phases. Phase 1: get it working for yourself. Connect the database, ask questions, sanity-check the SQL. Takes an afternoon. Phase 2: roll it out to the team.

These sound like step one and step two of the same project. They're not. In phase 1 you're technical, you know the schema, and you catch wrong answers because you read the SQL. In phase 2, your ops lead is asking the questions. She won't maintain a markdown file of table notes or review generated SQL, and she probably shouldn't be able to query every table you can.

This is the checklist for phase 2. It's the list I go through with every team we onboard, and it works whether you're building the setup yourself or using a platform. Five groups: access, context, visibility, rollout, and maintenance.
Access
Every person authenticates individually. No shared connection string, no API key in a team wiki. If the database only ever sees one service account, you've lost who-asked-what forever, and offboarding means rotating a secret everyone has.
Table access is scoped per person or group. Ops can see order tables, not payroll. This isn't only a security control; it's an accuracy control. An agent choosing between the 12 tables relevant to your job gets confused less often than one choosing between all 200.
The AI's database role is read-only, against a replica. The agent can never write, and a runaway analytical query can't slow production.
Context
Tables and columns have descriptions the AI can use. Not just names. What the status enum values mean, which timestamp to use for reporting, which of the three revenue-ish columns is the real one. The best source is where this knowledge already lives: your schema, your source code, your internal docs.
Core metrics are defined once, in writing. Revenue, active user, churn. If the definition isn't written down, the model re-derives it every session, and two people asking the same question get different numbers.
The questions each team asks most have curated, vetted queries. Before Quark Expeditions opened access to their marketing and ops teams, they curated the common questions those teams ask, so day-one answers came from vetted SQL instead of fresh guesses. Ten canonical queries cover a surprising share of any team's real questions.
Visibility
Every question and every query is logged, with the human attached. “The service account ran 400 queries yesterday” is not an audit trail. You want: who asked, what they asked in plain English, what SQL ran, what came back.
Errors are monitored, not just logged. Failed queries cluster into patterns (wrong column guesses, permission denials, timeouts), and the patterns tell you what context is missing.
Users can flag a wrong answer. The people asking questions will spot wrong numbers before you do. Give them a one-click way to say “this looks off” that lands somewhere you'll see.
Rollout
Start with one team, not the whole company. Pick the team with the most repetitive question load. Curate their questions first, then open access.
Meet people in the tool they already use. If the team lives in Claude, roll out in Claude. Asking people to adopt a new interface and a new habit at the same time kills adoption.
Someone owns the setup. Usually whoever owns the data. Not a full-time job, but wrong answers need a name attached to fixing them.
Maintenance
Phase 2 doesn't end at rollout. The setup you launched with degrades quietly: schemas change, questions evolve, definitions go stale. Maintenance is the loop that keeps it trustworthy.
Review what people are actually asking. Weekly at first. The questions tell you what context to add next, and which teams are ready for access.
Watch where the agent fails. Wrong column guesses point to missing table context. Repeated permission errors point to someone who needs access they don't have. Inconsistent numbers point to an undefined metric.
Keep context in sync with the schema. A column rename silently breaks every saved query and description that referenced it. Schema sync should be automatic; if it isn't, put a recurring reminder on the calendar, because nobody re-audits docs voluntarily.
Retire what's stale. Deprecated tables, old metric versions, queries nobody runs. Stale context doesn't just sit there, it actively misleads the model.
How Contextflo covers this
We built Contextflo because most of this list shouldn't be your job to assemble. Individual OAuth for every user, per-user and per-group table scoping, context generated from your actual sources (schema, source code, docs), shared metric definitions and saved queries, full question-and-query logging per user, error monitoring, and daily schema re-sync.
Setup takes about 15 minutes, so you can run phase 1 on it and have phase 2 already wired when you're ready.
Whatever you use, run the checklist. The teams that skip it don't find out until a wrong number reaches a decision.
Contextflo is free for one user and one data source, so phase 1 costs nothing.
Related reading
- How to connect Claude or ChatGPT to your company data: the full picture of the options and where each one breaks
- You connected your warehouse to Claude, now what?: the phase 1 to phase 2 gap, in narrative form
- Access control in agentic analytics: the access group of this checklist, in depth