Frontier · Prompt library

AI Adoption Across Tools Prompt

AI Adoption Across Tools

← Back to Prompt Library

📋 Review the schema first. Before running this prompt, confirm your column names and the Copilot/agent action taxonomy against the Schema Documentation.

🗂️DataPerson / Consumption / Agent queries 📅Min data1 common week; 8+ recommended 💻LanguageR or Python 📦OutputStatic HTML report 🎯LevelIntermediate

Purpose

Create a static HTML report showing observed AI adoption, high-usage cohorts and differences in tool use across organisational groups.

Audience

People analytics leads, AI adoption teams and business leaders.

When to use

When Person, Consumption and Agent query exports are available and you want to understand AI use across the products they measure, rather than M365 Copilot alone.

Required inputs

• Query exports in the workspace’s data folder. Use a weekly Person Query as the population spine, with PersonId, MetricDate and any available organisational attributes.
• Person Query metrics: Total Copilot actions taken, Cowork tasks submitted and User-initiated Cowork tasks submitted.
• Consumption query: PersonGitHubCreditsMetrics.csv, containing Total GitHub AI Credits used. M365 credits and service metadata are optional.
• Agent query: PersonAgentActivityMetrics.csv, containing PersonId, AgentId, MetricDate and Conversational agent sessions. Agent metadata is optional.
• Configured population, date grouping, week start and product filters for each supplied query. One complete common week supports a snapshot. Eight or more common weeks are recommended for trends.

Missing sources or metrics reduce the report’s scope. They must not be interpreted as no use.

Assumptions

• Person identifiers are compatible across the selected queries, and each source is validated at its native grain before joining.
• Actions, tasks, credits and sessions are separate units. Their totals cannot be combined into an overall AI usage score.
• The report describes observed activity within the supplied sources. It cannot establish use of unmeasured AI tools, task intent, proficiency or productivity.
• Heavy usage is a relative, metric-specific description. Published results contain cohorts and group summaries, not individual rankings.
• This is a guided analysis prompt, without a completed end-to-end data trial or a verified report adapter.

Recommended output

A self-contained output/ai-adoption.html report, with reproducible R or Python source, privacy-protected aggregate tables and a validation log alongside it. Lead with the answers, then show tool-specific evidence, group comparisons and methodology.

Quick prompt (short version)

Use the viva-insights-analysis skill to create a self-contained static HTML report answering: how many people use the measured AI tools, which cohorts have the heaviest usage, and how tool use differs by organisational group.
Read the supplied queries from the workspace's data folder and save all generated files under its output folder. Do not write to filesystem-root /data or /output.
Use the weekly Person Query as the population spine. Prioritise Total Copilot actions taken, Cowork tasks submitted, User-initiated Cowork tasks submitted, Total GitHub AI Credits used from Consumption, and Conversational agent sessions from the Agent query.
Inspect actual headers and source configuration first. Follow https://microsoft.github.io/viva-insights-sample-code/query-join-guide/ for native keys, aligned weeks, aggregation before joins and scoped missing-row rules. Keep omitted sources and failed joins unresolved.
Report distinct observed users for each tool and the union across tools, never the sum of tool user counts. A known positive establishes observed use. Without any positive, classify as no observed use only when every selected source is resolved for that person-period, otherwise unknown. Withhold an overall rate if selected-source coverage is unresolved.
Keep actions, tasks, sessions, M365 credits and GitHub credits in separate units. Do not add User-initiated Cowork tasks submitted to Cowork tasks submitted without a verified disjoint definition. Positive GitHub credits establish metered usage, not every GitHub interaction.
Use distributions and metric-specific upper-decile cohorts to describe heavy usage. Show their aggregate group mix, never names, identifiers or person-level leaderboards. Do not infer productivity or value.
Use available HR fields for group comparisons and continue with overall results if none are suitable. Use a common reporting window and show denominators and missingness. Distinguish population reach from licensed adoption, which needs product-specific eligibility.
Use the stricter organisational minimum or 10 distinct people for every published cell, including high-usage cohorts, complements, charts, embedded data and downloadable aggregates.
Produce a summary-first report with tool reach, overlaps, separate usage-intensity panels, group comparisons and trends where supported. Include the source-to-metric mapping, skipped analyses and executed validation results. Embed assets locally with no CDN, external runtime or server dependency.

Prompt

Build an AI Adoption Across Tools report using the viva-insights-analysis skill and its shared analysis policy. Use R or Python according to the installed environment. Inspect available package functions and installed signatures before writing custom analysis.

QUESTIONS
1. How many distinct people use at least one of the measured AI tools?
2. Which high-usage cohorts account for the heaviest recorded usage, and how are those cohorts distributed across groups?
3. Which tools and recorded features are used, and how does that mix differ across groups and over time?
Treat "across the board" as across the supplied sources, not all AI activity.

INPUTS AND OUTPUTS
Read exports from data relative to the workspace root. Save all generated reports, scripts or notebooks, aggregate CSVs and logs under output relative to that root, creating it if needed. Do not modify the source exports or write to filesystem-root /data or /output.
Create output/ai-adoption.html as a single self-contained HTML file. Keep person-level working data local and out of published files.

VALIDATE AND JOIN
Inspect file contents and actual headers, including CSVs inside query ZIPs, rather than relying on filenames alone. Print a file inventory, row counts, date ranges, distinct-person counts, candidate organisational fields and a metric mapping. Preserve raw headers in the report, mapping imported underscore names back to them.
Prioritise these measures:
- Person Query: Total Copilot actions taken, Cowork tasks submitted, User-initiated Cowork tasks submitted.
- Consumption query: Total GitHub AI Credits used.
- Agent query: Conversational agent sessions.
Add other verified measures only when they help answer the questions. Examples include active days, unlicensed Copilot Chat activity, M365 credit consumption by service and agent categories when their definitions and metadata are available.

Follow https://microsoft.github.io/viva-insights-sample-code/query-join-guide/ and its downloadable JSON for current source keys and join rules. If the guide cannot be read, use a supplied copy or record the affected cross-query analysis as unavailable rather than guessing keys or additivity.
Confirm the configured population, date window, grouping and week start for every query. Use the weekly Person Query as the population spine and select a common complete reporting window. Do not shift already aggregated weeks to a different week start. Aggregate compatible daily flows to the Person Query weeks only where the contract permits it.
Validate native keys before summing. Reduce Agent facts from person-agent-week to person-week before joining. Keep GitHub credits separate from M365 credits. Validate service and spending-policy additivity before aggregating M365 credits.
Preserve Person Query row counts and unique person-week keys after every left join. Log unmatched keys, out-of-scope periods, duplicate-key conflicts and known coverage failures. Stop the affected join for an explicit resolution if keys or cardinality are ambiguous.
Within each supplied query's configured scope, absent activity rows contribute zero. Unavailable sources, join failures, null cells and out-of-scope periods are separate states. Apply product-specific native-null licence rules only to verified fields, without inferring an M365 licence from credits or Agent sessions.

MEASURE ADOPTION AND REACH
For each tool and week, flag positive observed use from its verified activity metric. Count distinct people, not fact rows. Positive GitHub credits measure people with recorded metered usage and do not capture every GitHub interaction.
For the combined indicator, known positive activity in any selected tool establishes observed use. With no positives, classify as no observed use only if all selected tools are resolved for that person-week, otherwise unknown. Never turn unresolved sources into inactivity.
Report source-specific users and their union, with privacy-protected overlaps. Tool counts overlap and must not be added. If a source is absent, name the reduced scope in the headline.
Population reach is distinct observed users divided by the in-scope Person Query population over the same window, only when selected-source coverage is resolved. If unresolved, report observed user counts and unknown coverage separately, withholding the affected overall rate. Product-specific licensed adoption is a separate measure and requires a resolved eligibility denominator.
For window-level reach, count each person once. For weekly trends, count each person once per week. State treatment of population entry, exit and partial observation.

DESCRIBE INTENSITY AND TOOL MIX
Keep actions, tasks, sessions and credits in separate panels with their native units. Do not create a total AI activity score by adding or normalising unlike metrics. Do not add task subcategories to totals without verifying disjointness.
Within each metric's positive users in the common window, summarise each person's mean usage per complete observed week. Report cohort medians and distributions, suppressing disclosive tails and small cells. Define high usage as strictly above the reference population's 90th percentile for that metric, with ties at the threshold outside the cohort. Show thresholds and cohort sizes. If too few people remain, omit the cohort breakdown.
Keep these reference thresholds fixed for any comparison periods. Do not rank named or pseudonymised individuals, expose person-level maxima, or treat heavy use as superior performance.
Compare tool reach and intensity by available HR attributes, with group sizes and comparable observation windows. Use dated organisational assignments for weekly views and state the assignment rule for whole-window summaries. A person using several tools may appear in several tool cohorts.
Only describe tasks or use cases where documented metrics or metadata identify them. Tool activity alone does not reveal what people were trying to accomplish.

REPORT AND VERIFY
Lead with a short answer to each question and the measured scope. Follow with source coverage, distinct-user reach and overlaps, separate intensity panels, group comparisons and trends where at least two comparable complete periods exist.
Use a restrained palette, clear units, contextual explanations and progressive disclosure for methodology. Embed charts, styles and any scripts in the HTML with no external runtime dependencies.
Apply at least 10 distinct people, or the stricter organisational minimum, to every published cell and high-usage cohort. Protect complementary cells, intersections, embedded data and aggregate downloads. Omit unsupported group views and explain why.
Keep an evidence ledger linking every headline to its source, population, dates, numerator, denominator and calculation. Save a validation log distinguishing executed checks from skipped analyses. Reconcile union counts against the population spine, confirm joins do not multiply rows, check output assets load offline and inspect desktop and mobile layouts.
Do not fabricate metrics, missing sources, task labels, cost savings or productivity claims.

<!-- analysis-policy:start -->
Use product-specific licence evidence. For documented native licensed-only M365 Copilot metrics, null means unlicensed and zero activity means licensed but inactive. Prefer Copilot Enabled User or Total Copilot enabled days. Do not extend these semantics to unlicensed Copilot Chat or Consumption credits.
Investigate conflicting licence evidence. Keep affected eligibility or activity unresolved, and withhold affected rates or estimates until resolved.
Within a supplied complete query's configured scope, absent activity rows contribute zero. Keep failed joins, unavailable sources, out-of-scope periods and known coverage failures unresolved with reasons.
Use configured grouping, week start and metric windows; date gaps do not establish cadence. State grain, units and estimand. Count distinct people; do not sum stocks or overlapping windows.
Use max(organisation requirement, workflow floor): 5 distinct people for general analysis and 10 for joined-query, dashboard, causal or process workflows. Protect complementary cells and embedded data; never publish individual rankings.
Use only HR attributes present in the export. If none suit a requested breakdown, omit it, explain why, and continue with supported overall results.
Treat low-activity flags as review candidates, not verified holidays, employment status or job classifications. Value scenarios require explicit conversion and realisation assumptions.
Default to association. Make causal claims only with a supported design and compatible estimators. Record unavailable checks and label synthetic data.
Check installed API versions, signatures and return types. Separate executed results from expectations and do not silently fork upstream bugs.
<!-- analysis-policy:end -->

Adaptation notes

• Supply the actual workspace-relative data and output paths if they differ.
• Export the selected queries grouped by week with aligned week starts where possible. Daily Consumption facts need compatible aggregation before joining.
• Add unlicensed Copilot Chat as a separate activity family if present. M365 licensed activity does not describe that population.
• Optional tool categories should come from verified metadata. Any experimental usage archetypes need their own eligibility and window rules.
• Use a higher privacy threshold where required. Omit cohort views if the high-usage tail cannot be published safely.

Common failure modes

• A universal AI user count is claimed. The report can describe only supplied products and metrics. Name that scope.
• Tool users are added together. The same person can use several tools. Count the distinct-person union.
• Actions, tasks and credits are combined. These have different meanings and units. Keep separate intensity measures.
• Agent rows multiply the population. Aggregate facts at the native grain before a validated person-week join.
• A heavy-user leaderboard exposes people. Publish sufficiently sized cohorts and group mixes, including protection for complementary cells.
• Missing queries become non-users. Unavailable or unresolved sources reduce the measured scope and can prevent a combined rate.

🔒 Responsible use & data privacy

• Suppress small groups. Apply the stricter of your organisation's minimum group size and the selected workflow's privacy floor to every breakdown, segment and chart.
• Never expose individuals. Do not print raw UPNs or email addresses. Hash, truncate or report only aggregates. Person Query PersonId is already de-identified, but Purview UserId is not.
• Report group patterns. Use these outputs to understand cohorts and trends. Do not evaluate, rank or monitor named employees.
• Keep data in approved environments. Follow your organisation's policies when choosing an agent and deciding which data it may access. Validate every agent output before sharing.

← Previous: Dashboard Overview Next: Executive Summary →