Quick warm up: your analytics scene

• How often do business users request new reports from your analytics team? Options: Daily, Several times a week, Weekly, Monthly, Rarely
• Tell me about the last time a business user built a spreadsheet to replace a dashboard, what happened?
• In your current setup, who is most likely to create an unofficial spreadsheet of record? Options: Regional sales leader, Supply chain planner, Finance analyst, Product manager, Other
• Which departments are building reports outside the analytics team today? Options: Sales, Finance, Operations / Supply chain, Marketing, Customer success, Other
• Walk me through a recent case where two leaders presented different numbers and the fallout that followed.
• State the single reason someone on your team would block a pilot. Options: Security or compliance risk, Insufficient budget, Lack of executive buy-in, Data quality concerns, Other

Where the system breaks trust

• If a single dashboard number were wrong tomorrow, which metric would cause the biggest operational problem?
• Who typically first flags a discrepancy, and how is it escalated? Options: Direct manager, Regional leader, Central analytics team, Finance, Automated alert
• Name the tools or extracts people reach for when they do not trust the dashboard. Options: Spreadsheets, Ad hoc SQL queries, Exported CSVs, Third-party BI, Internal reports
• How long does it usually take from the first flag to an agreed correction? Options: Same day, 1-3 days, One week, 2-4 weeks, Longer than a month
• Which dashboards are certified as a single source of truth, and where is that certification recorded? Options: Data catalog, Wiki or documentation, Not documented, Within the analytics tool, Other

Who's driving decisions and who gets left out

• Who, if anyone, would cancel the project if they lost confidence in the metrics? Options: CFO, VP of Analytics, Head of IT/Security, Business unit leader, No single person
• List the people who must sign off on pilot success, and their functional titles.
• When decisions are needed fast, where do regional leaders go first for numbers? Options: Central analytics, Their local analyst, Spreadsheets, Operational apps, I don't know
• Describe how non-technical power users currently get quick answers without writing SQL.
• On a scale of 1 to 5, how much would improving self-service reduce ad hoc ticket volume? Options: 1 - No impact, 2 - Small impact, 3 - Moderate impact, 4 - Large impact, 5 - Transformational

What's getting in the way of a clean pilot

• What single technical roadblock would stop a pilot before it starts?
• Name the data sources or systems that must be connected for the pilot to validate your workflows.
• Tell me where control of credentials lives today, and the person or team responsible.
• Do you have row-level security or masking rules already defined that must be preserved? Options: Yes, fully defined, Partially defined, No, Not sure
• Estimate the engineering or analytics hours per week you can commit to the pilot. Options: 0-5 hours, 6-15 hours, 16-40 hours, More than 40 hours
• If the pilot cannot access a live warehouse for any reason, would you pause, change scope, or proceed with extracts? Options: Pause the pilot, Reduce scope and proceed, Proceed with extracts, Other

The other options you're weighing

• What would have to be true about your current approach for you to decide to keep it instead of switching?
• Are you currently evaluating any of the following options? Options: Existing enterprise BI platform, Build an internal solution, Embed analytics in apps, Continue with spreadsheet processes, Other vendor
• Has anyone on your team proposed solving this problem internally without an outside vendor? Options: Yes, formal proposal, Yes, informal plan, No, Not sure
• Describe the changes that would make you comfortable staying with your current approach over the next 90 days.
• When an incumbent exists, list the main shortfalls that would need addressing before you could keep it.

If this worked for you, what would change

• Imagine business users could build accurate dashboards without help, name the immediate business decisions that would change.
• List up to three metrics you'd prioritize for certification in the semantic layer.
• Specify the metrics and thresholds you would use to declare the pilot successful.
• Imagine the pilot frees analysts from 50% of ad hoc requests, what's the first thing the data team would do with that capacity? Options: Build more models, Improve data quality, Focus on advanced analytics, Create more dashboards, Other
• Would a successful pilot that meets your acceptance criteria remove the need for any current reporting licenses or tools? Options: Yes, partially, Yes, completely, No, Not sure

Practical limits and compliance we must respect

• Suppose a security auditor demanded a change tomorrow, which requirement would force you to pause deployment?
• Do you have a documented data classification or sensitivity matrix that maps owners and access rules? Options: Yes, centrally documented, Partially documented, No, I don't know
• Identify the team or role that owns the main warehouse schemas the pilot relies on.
• Are APIs, service accounts, or connector options already approved for third-party access? Options: All approved, Partially approved, Not approved, Not sure
• Rate the maturity of your data catalog or lineage tracking on a 1 to 5 scale, where 1 is none and 5 is enterprise grade. Options: 1, 2, 3, 4, 5
• Estimate the headcount or contractor budget you can allocate to integration and testing during the pilot. Options: No dedicated headcount, 1-2 FTEs or equivalent, 3-5 FTEs, 6+ FTEs / significant contractor budget
• Provide your typical regulatory review cycle in business days. Options: 5-10 days, 11-20 days, 21-40 days, More than 40 days, Not applicable

The pilot that accelerates decision day

• Suppose the pilot proves the metrics match your board-reported numbers, what would stop you from signing that week?
• Provide the measurable acceptance criteria you would require to consider the pilot a commercial success.
• State the day-to-day contact for pilot execution and the person who makes final go or no decisions.
• Give the minimum pilot window length you consider sufficient to validate dashboards built by non-technical users, in weeks. Options: 1 week, 2 weeks, 3-4 weeks, 5-8 weeks, More than 8 weeks
• Specify the budget holder who will sign off on pilot expenses like connectors or services.
• Would you be open to a short technical readiness checklist completed before kickoff to avoid late surprises? Options: Yes, Maybe, No
• Explain the internal steps you will take to expand to other teams if the pilot succeeds, and who will lead that cadence.

• Solution Walkthrough Session

• Confirm the current state and its cost
• You confirm the demonstrated workflow eliminates the manual requests and reconciliation you described.
• Prepare a live demo connected to the provided sample dataset and deliver the demo link and connector details before the session.
• You confirm that governed metrics produce matching executive numbers for the workflow shown.
• Map a critical business workflow end-to-end
• Grant read-only access to a representative warehouse schema or provide an exported sample of the tables used in the chosen workflow.
• Live proof, author a dashboard from governed metrics
• You agree on specific, measurable pilot acceptance criteria and the evidence required to validate them.
• Identify two business users who will act as dashboard authors during the pilot and confirm their availability for the live walkthrough.
• Validate the future state
• Document the draft pilot acceptance criteria including exact queries or dashboard views that must be reproducible during pilot validation.
• You identify the next decision owners and a target timeline for pilot kickoff.
• Agree pilot acceptance criteria and next steps

• Solution Walkthrough Session
• Solution Experience Deck
• Solution Brief

• meeting
• slides
• document

• stakeholders
• current_state
• success_criteria
• decision_readiness
• desired_state
• gaps
• current_state
• decision_readiness
• stakeholders
• gaps
• desired_state
• success_criteria
• gaps
• decision_readiness
• current_state
• stakeholders
• current_state
• decision_readiness
• decision_readiness
• decision_readiness
• decision_readiness

• Provision platform environment (cloud or VPC)
• Connect cloud data warehouse via live query
• Configure extracts and scheduled data syncs
• Build governed semantic layer and metric definitions
• Publish and certify data sources and datasets
• Implement row-level security rules
• Configure column masking and data redaction
• Enable natural language search and insight generation
• Create pilot department dashboards and reports
• Embed analytics into operational applications
• Activate usage analytics and dataset telemetry
• Migrate and map legacy reports to platform datasets
• Onboard power users with dashboard authoring training
• Configure role-based access and permissions

Provision platform environment (cloud or VPC)

• Do you plan to deploy the platform inside your cloud account or require a vendor-hosted instance? Options: Your cloud account, Vendor-hosted cloud, VPC with dedicated subnets
• Which cloud region or VPC CIDR will be used for the deployment (provide region code or CIDR)
• Who will own the cloud account and approve required infrastructure changes (name or role)
• Provide the compliance baseline required for this environment (for example SOC 2, ISO 27001, GDPR constraints) Options: SOC 2, ISO 27001, GDPR/Local Data Residency, Custom compliance checklist
• Specify expected concurrent dashboard authors and end users that the environment must support Options: <50, 50-200, 200-1000, 1000+

Connect cloud data warehouse via live query

• Which cloud data warehouse hosts the authoritative tables for the pilot (reference the database/schema name)
• Identify the network or private link mechanism required to allow live queries from the platform to your warehouse Options: Private VPC peering, Public internet with IP allowlist, Dedicated private link, Other
• Indicate the target warehouse cluster or compute size we should validate for live-query SLAs (e.g., analytics cluster X)
• Confirm the maximum acceptable query latency for interactive dashboards against the warehouse (milliseconds/seconds) Options: <500 ms, 500 ms-2s, 2s-5s, >5s
• Provide the names of three representative tables or views (for example sales_orders, customer_master, monthly_revenue) that we should validate via live queries

Configure extracts and scheduled data syncs

• Which datasets do you want extracted for offline dashboards (list table names and expected refresh cadence)
• Specify the acceptable extract window and maximum lag for scheduled syncs relative to source system events Options: Near real-time (<5m), Hourly, Daily, Weekly
• Provide the ETL/ELT job names or orchestrator used for current scheduled syncs that will need mapping
• Are there transformation jobs we must run before extract (for example materialized aggregates used by your demand model spreadsheet)? Options: Yes, No
• Identify any tables that must be excluded from extracts due to size or compliance (provide table name and reason)

Build governed semantic layer and metric definitions

• Which canonical business metrics must be defined first (for example revenue_recognized, closed_won_amount, on_time_delivery) — list metric names and one-line definitions
• Identify the source-of-truth table or view for each metric you listed (database.schema.table or view)
• Specify the acceptance criteria that will validate metric parity between the semantic layer and your finance board deck (for example match within 0.5% for last closed month) [acceptance/evidence question] Options: Match within 0.5%, Match within 1%, Match within 2%, Other
• Describe any existing business logic or SQL snippets used to compute these metrics today that must be preserved in the semantic definitions
• Indicate which roles must be allowed to edit metric definitions versus which roles require metric certification

Publish and certify data sources and datasets

• List datasets that must be certified during pilot (provide dataset name and primary owner)
• Identify the dataset custodians who will receive notification to certify published datasets (name or role)
• Which operational workflow or approval document do you require before a dataset is marked certified (for example change approval board ticket ID pattern)?
• Are there SLA targets for dataset freshness that must be displayed on the dataset catalog entry (for example refreshed within 1 hour of source load)? Options: Yes, No
• Provide any tagging taxonomy required for datasets (for example domain:finance, sensitivity:PII)

Implement row-level security rules

• Which business entities require row-level restrictions (for example region_id, account_id, business_unit) — list the column(s)
• Who will own the mapping from user identity to restricted entity (for example HR group, identity provider attribute)
• Describe any exceptions to standard RLS rules (for example auditors who need cross-region access) and the approval document that enables them
• Are there existing identity provider attributes or group names we should use to enforce RLS (provide attribute or group examples)
• Confirm how you will validate RLS during pilot (for example test user A cannot see territory B) [acceptance/evidence question] Options: Documented test cases, Sample accounts verified by compliance, Manual spot checks

Configure column masking and data redaction

• Which columns contain sensitive data that must be masked or redacted (list table.column pairs, e.g., customer.email)
• Specify the masking policy for each sensitive column (for example full redaction, partial tokenization, hash) Options: Full redaction, Partial tokenization, Hashing, Pseudonymize
• Who approves exceptions to masking for analysts (provide role or approval workflow)
• Indicate whether masked columns should be audited in dataset telemetry when accessed Options: Yes, No
• Provide any regulatory controls that drive masking choices (for example PCI, HIPAA, local data residency) and cite the controlling document

Enable natural language search and insight generation

• Which user personas should be able to use natural language search (for example regional sales managers, supply chain planners)
• List three example queries your business users would ask in plain language (for example "show pipeline by territory last quarter")
• Specify any vocabulary or synonyms we must map into the semantic layer (for example 'ARR' maps to annual_recurring_revenue)
• Identify any data privacy constraints that would prevent certain fields from being surfaced in generated insights
• Indicate whether automated insight emails or summaries should be enabled for specific dashboards (list dashboards and cadence) Options: Daily, Weekly, Monthly, No automatic summaries

Create pilot department dashboards and reports

• Which department will participate in the pilot and what are their top three use cases (for example regional sales: territory pipeline, quota attainment, closed deals)
• List the specific dashboards or reports to build for the pilot with target audience and primary KPI (for example Territory Pipeline dashboard — Regional VP — open_pipeline_value)
• Specify pilot acceptance criteria for user self-service capability (for example a non-technical power user must build the agreed dashboard unaided within 2 hours) [acceptance/evidence question] Options: Non-technical user builds in under 2 hours, User completes with up to one help call, Requires data team intervention
• Identify source-of-truth comparison artifacts to validate dashboard numbers during pilot (for example monthly close spreadsheet, CRM closed_won report)
• Provide the target refresh cadence and scheduled delivery method for each pilot report (for example daily dashboard refresh, weekly emailed PDF) Options: Real-time, Hourly, Daily, Weekly

Embed analytics into operational applications

• Which operational application(s) require embedded analytics and what embedding surface is needed (for example the order management UI header)
• Identify the integration mechanism supported by the application (for example iframe, SDK, server-side API) Options: iframe, JavaScript SDK, Server-side API, Other
• Specify authentication method for embedded views (for example single sign-on via your identity provider) and provide SSO protocol Options: SAML, OpenID Connect, API key, Other
• Describe the expected latency and availability requirements for embedded visuals inside the operational workflow
• List any operational events that should trigger embedded analytics updates (for example order state change, inventory refresh)

Activate usage analytics and dataset telemetry

• Which telemetry signals are essential to capture during pilot (for example dashboard views, query errors, dataset popularity)
• Provide the retention period required for telemetry and audit logs for compliance purposes Options: 90 days, 1 year, 3 years, Other
• Identify the reporting cadence and recipients for usage reports (for example weekly usage summary to VP of Analytics)
• Are there specific query patterns or datasets you want alerts on (for example heavy-cost queries against raw event table)? Options: Yes, No
• Specify any dataset telemetry fields that must be suppressed for privacy reasons (for example user identifiers)

Migrate and map legacy reports to platform datasets

• List legacy reports to migrate with owner and report location (for example sales_territory_report.xlsx in shared drive)
• Provide the mapping from legacy report fields to semantic layer metrics or dataset columns (attach mapping document or list key field mappings)
• Identify legacy report complexity level to estimate migration effort (for example simple table, calculated metrics, complex joins) Options: Simple table, Calculated metrics, Complex joins/SQL
• Are there archival or historical reports that will remain in the legacy system and should be considered out of scope? Options: Yes, No
• Specify the success criteria for a migrated report (for example numbers match legacy within 1% for last 3 months)

• Subscription Agreement
• Order Form / Pricing Schedule
• Data Processing Agreement (DPA)
• Security & Compliance Addendum
• Mutual Dependencies & Preconditions
• Pilot Acceptance Criteria
• Master Services Agreement (MSA) (assumes professional services)
• Statement of Work (SOW) (assumes professional services)

• Go-live Health Check (weeks 1-4)
• First Outcome Measurement (weeks 4-10)
• Acceptance Gate Review (around day 90)
• Quarterly Success Review (ongoing quarterly)

• Update dataset certification and row-level security documentation for any changes applied during the quarter.
• Execute the agreed remediation tasks and publish status updates ahead of the Acceptance Gate meeting.
• Validate that dashboards counted as 'business-authored from governed metrics' reference certified semantic layer objects.
• Restate acceptance criteria and numeric targets
• Produce a documented pass or fail decision for each acceptance criterion recorded in Solution Scope.
• Capture a formal acceptance decision with the required named signatory or documented buyer confirmation.
• If applicable, finalize the incumbent decommissioning plan and confirm archival or migration completion.
• Publish the acceptance decision record with supporting evidence and the remediation plan for any failed criteria.
• If decommissioning the incumbent, execute the archival and contract-closure tasks and publish a completion report.
• Schedule the follow-up verification checkpoint for any remediation items with clear verification criteria.
• Adoption and usage trends
• Confirm adoption is stable or improving by reviewing weekly active dashboard authors and the percent of dashboards using certified semantic metrics.
• Ensure the operational ticket backlog is decreasing and critical blockers have dated remediation plans.
• Agree the prioritized enhancement items to be scoped in the next quarter.
• Publish the quarterly adoption report with metric trends and the current enhancement backlog prioritization.
• Execute the top three operational commitments and report status before the next quarterly review.
• Re-confirm success criteria and owners
• Confirm production connectors and environments are operational within acceptable thresholds.
• Document and schedule remediation for all severity-high blockers identified during cutover.
• Verify user provisioning and initial onboarding tasks completed for the pilot group.
• Publish a deployment health summary with connector logs and incident list for asynchronous review.
• Run a data access verification checklist for the pilot datasets and report any mismatches.
• Schedule a follow-up checkpoint once remediation items are marked complete.
• Present first outcome data
• Establish whether hours per week spent on manual reporting and the count of business-authored governed dashboards are progressing toward targets recorded in Solution Scope.
• Create a prioritized remediation plan for any metric shortfalls with clear resolution dates.
• Confirm the data sources and methods used to measure each metric so future comparisons are consistent.
• Deliver a measurement-pack that documents metric definitions, data queries, and the baseline calculations for each measured metric.
• Deployment and environment validation
• Persistent issues and ticket burn-down
• Present outcome data against each criterion
• Diagnose gaps and root causes
• Early operational signals
• Enhancement request triage
• Document pass or fail per criterion
• Agree corrective actions and timeline
• Governance and certification status
• Blockers and incident triage
• Confirm path and date to acceptance gate
• Acceptance decision and signatory documentation
• Immediate remediation and next steps
• Short operational commitments and next checkpoint
• Incumbent wind-down confirmation
• Remediation plan for unmet criteria