Frontier · Prompt library

Copilot Adoption Executive Summary Prompt

Copilot Adoption Executive Summary

← 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 Query 📅Min data8+ weeks 💻LanguageR or Python 📦OutputHTML / Markdown memo 🎯LevelBeginner

✓Last validated June 2, 2026 against vivainsights R 0.7.2 / Python 0.4.2.

Purpose

Summarise Copilot adoption metrics, trends and recommended actions in a memo for senior leadership.

Audience

VP/C-suite executives, senior leadership team, IT steering committee

When to use

For monthly or quarterly updates on Copilot adoption progress to senior leadership, after collecting at least 8 weeks of Person Query data.

Required inputs

• Person query CSV with columns: PersonId, MetricDate, Copilot metrics (e.g., Copilot_Actions, Copilot_Assisted_Hours), and optional HR attributes (e.g., FunctionType, Area, Country, or Organization)
• At least 8 weeks of data recommended (12+ weeks preferred for trend analysis)

Assumptions

• Data is at person-week granularity
• PersonId is a consistent anonymized identifier
• MetricDate is a date field representing the start of each week
• Licensing follows documented native M365 Copilot null/zero semantics, with enabled-user or enabled-days evidence preferred
• The vivainsights R or Python package is available in the environment

Recommended output

A 1–2 page executive summary in HTML or Markdown, formatted as a professional memo suitable for distribution to VP/C-suite audiences.

Quick prompt (short version)

Use this shorter prompt for a fast first pass that adapts to your data.

Help me produce a concise executive summary memo for senior leaders that explains Copilot adoption progress, risks, and recommended next actions from a Viva Insights person query export.
Start by loading the real CSV and printing row count, column names, data types, date range, and unique people so you can map the actual Copilot and HR fields.
Adapt the column names dynamically rather than assuming the defaults, and ask me for the file path, preferred output format, or any ambiguous field mapping before you proceed.
Prefer Copilot Enabled User or Total Copilot enabled days per person-week. Native licensed-only M365 Copilot nulls mean unlicensed and zero activity means licensed but inactive. A verified metric with those semantics is a valid fallback without explicit licence fields. Keep failed joins and genuinely unresolved licence status separate.
Read configured grouping, week start and metric windows. Date spacing is only a diagnostic. In a supplied complete query's configured scope, absent activity rows contribute zero. Unavailable sources, out-of-scope periods and known coverage failures remain unresolved.
Calculate every reported number directly from the data, with distinct-person denominators and an explicit person versus person-week estimand.
Compare recent adoption and usage trends using the amount of history actually available, and call out when the dataset is too short for the preferred comparison window.
Keep the tone balanced and executive-friendly, include specific numbers in findings and recommendations, and avoid unsupported claims.
Suppress groups below max(the organisational requirement, 5 distinct people), including complementary cells and embedded data. Use floor 10 if this memo is part of a dashboard or joined-query workflow. Never publish individual rankings.
Use only available HR attributes for group findings; if none are suitable, omit group comparisons and report overall results.
End by listing any assumptions you made about activity metrics, comparison windows, or segment mappings.

Use the detailed prompt below for a reproducible, exact-structure output. Use the quick prompt above for a faster first pass that you refine through follow-up turns.

Prompt

You are a senior people analytics consultant. Your task is to generate an executive summary memo about Microsoft Copilot adoption, based on a Viva Insights person query export. Write for a VP or C-suite audience. Keep the memo concise, support findings with numbers and recommend specific actions.

LANGUAGE CHOICE
Choose R or Python based on what is already installed in your environment to minimize setup.

DATA LOADING AND PREPARATION
Read the configured weekly grouping, period and metric windows before calculating rates. Apply the shared analysis policy below to eligibility, missingness and privacy.
1. Load the person query CSV using `import_query()` from the `vivainsights` library (R or Python). This handles variable name cleaning and type parsing automatically.
2. Identify Copilot metric columns by checking for columns containing the word "Copilot" in their name. Reference the taxonomy at https://github.com/microsoft/viva-insights-sample-code/blob/main/examples/example-data/copilot-metrics-taxonomy.csv to classify and validate the detected metrics. Use `Total_Copilot_actions_taken` as the primary activity metric. Print the detected columns and the date range for verification.
3. Identify HR / organizational attribute columns with `extract_hr(df, return = "names")` in R or `vi.extract_hr(df, return_type="suggestion")` in Python. Use the returned names for all organizational breakdowns instead of hard-coding column names.
4. Classify person-weeks using the shared eligibility policy. Prefer explicit enablement or dated licence evidence, then a verified native licensed-only M365 metric. Mark a person active when licensed and `Total_Copilot_actions_taken` is positive. Keep unresolved eligibility separate and do not calculate affected rates.
5. If any expected HR attribute columns are not found by `extract_hr()`, note which ones are unavailable and proceed with what is present.

HEADLINE METRICS (compute these for the memo)
5. Current adoption rate: In the most recent complete week, what percentage of licensed users were active? Report as "X% of licensed users actively used Copilot in the week of [date]."
6. Adoption trend: Compare the average weekly adoption rate over the last 4 complete weeks to the prior 4 weeks. Calculate the percentage-point change. Classify as "improving", "stable" (within ±2pp), or "declining".
7. Usage intensity: Average Total_Copilot_actions_taken per active user per week over the last 4 weeks. Compare to the prior 4-week period. Report the direction and magnitude of change.
8. Breadth of adoption: Total unique users who have been active at least once in the last 4 weeks as a percentage of all licensed users in that period.
9. Select an available HR attribute for group comparisons, such as FunctionType, Area, Country or Organization. Rank the top and bottom three groups by the latest 4-week average adoption rate. Require at least max(the organisational requirement, 10) distinct licensed people per group. Count distinct people per week, and distinguish average weekly rates from a pooled period rate.
   If no suitable attribute is available, omit group rankings and state why.
10. Copilot_Assisted_Hours: Average weekly assisted hours per active user (last 4 weeks). Convert to a relatable figure (e.g., "X minutes per user per week").

KEY FINDINGS (synthesize the metrics into 3-5 bullet points)
11. Identify the most important story in the data. Is adoption growing? Plateauing? Declining? Which groups are leading and which are lagging?
If no suitable HR attribute is available, focus on overall results and do not infer group differences.
12. Look for notable patterns:
    - Is there a gap between license deployment and actual usage?
    - Are certain functions, areas, countries or other available groups adopting faster than others?
    - Is usage intensity growing even if adoption rate is flat (deepening engagement)?
    - Are there signs of churn (users who were active but stopped)?

RECOMMENDATIONS (generate 2-4 actionable recommendations)
13. Based on the findings, generate specific, actionable recommendations. Examples:
    - "Target [specific group] for enablement workshops, as its adoption rate is X pp below average."
    - "Investigate why [available HR group] has low adoption despite high licence deployment."
    - "Celebrate and share practices from [top group], which has achieved X% adoption."
    - "Consider a re-engagement campaign for the estimated N users who were active in weeks 1-4 but inactive in the most recent 4 weeks." Recommendations should reference specific numbers from the data.

AREAS OF CONCERN (flag 1-3 risks or issues)
14. Flag potential concerns:
    - Low overall adoption relative to license spend
    - Declining trends in any major segment
    - Segments below the applicable reporting minimum (withhold protected cells, including counts)
    - Data quality issues (e.g., missing weeks, unexpected nulls)

MEMO GENERATION
15. Create the executive summary as an intermediary document first, then export to HTML:
    - R: Create an RMarkdown file (.Rmd), then knit to a self-contained HTML file (output: html_document, self_contained: true).
    - Python: Create a Jupyter notebook (.ipynb), then export to a self-contained HTML file (e.g., `jupyter nbconvert --to html`). Keep the intermediary .Rmd or .ipynb file alongside the HTML output for troubleshooting and iteration.
    - Fallback: if you cannot create or execute a notebook/RMarkdown in this environment (e.g., the toolchain is unavailable), write the computed numbers directly into a single self-contained **HTML or Markdown report**. Note in the output that the intermediary notebook step was skipped. Use the following structure:

    HEADER:
    - Title: "Copilot Adoption: Executive Summary"
    - Subtitle: "Reporting period: [start date] to [end date]"
    - Date generated: [today's date]

    SECTION 1: "At a Glance" (summary statistics in a clean table or card layout)
    - Current adoption rate
    - Adoption trend (with directional arrow or indicator)
    - Active users (last 4 weeks)
    - Average Copilot actions per active user per week
    - Average Copilot-assisted time per active user per week

    SECTION 2: "Key Findings" (3-5 concise bullet points, each 1-2 sentences)

    SECTION 3: "Group Breakdown" (if an HR attribute is available; otherwise state why it is omitted and continue with overall findings)

    SECTION 4: "Recommendations" (2-4 numbered recommendations, each 2-3 sentences)

    SECTION 5: "Areas of Concern" (1-3 flagged items)

    SECTION 6: "Methodology" (brief paragraph)
    - Explain: data source (Viva Insights person query), how "licensed" and "active" are defined, the time period used for trend calculations, and any caveats (correlation ≠ causation, missing data handling).

16. Style guidelines for the memo:
    - Use professional, executive-friendly language. Avoid jargon.
    - Lead with the most important finding.
    - Every metric should be accompanied by context (e.g., "up from X% last month").
    - Use bold text for key numbers.
    - Keep the total length to 1-2 pages when printed.
    - Use a clean, professional design with a sans-serif font if HTML.

17. Save the output file with a descriptive name like "copilot_executive_summary_YYYYMMDD.html".

IMPORTANT NOTES
- Do NOT fabricate numbers. Every statistic must be computed directly from the data.
- If the dataset has fewer than 8 weeks, state that limitation and use a shorter trend window only when the data supports a like-for-like comparison.
- Keep the tone balanced. Report successes and genuine concerns without overstating either.

<!-- 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

• If your leadership prefers Markdown over HTML, add “Output as a Markdown file” at the start of the prompt.
• Organisation rankings use at least 10 distinct licensed people or the stricter organisational requirement; increase rather than lower that floor. For very large organisations, 20 or more keeps rankings comparable.
• Add company-specific context by prepending: “Our Copilot deployment started on [date] and currently covers [N] licenses across [divisions].”
• If you want the memo to reference specific business goals (e.g., “target 60% adoption by Q3”), include that context before the prompt.
• Change the trend comparison window (default: 4 weeks vs. prior 4 weeks) to match your reporting cadence.

Common failure modes

• Agent fabricates insights not supported by data. The prompt instructs the agent to compute every statistic from the data, but always verify headline numbers independently.
• Agent uses overly technical language. The prompt specifies executive-friendly language, but review the output for jargon like “person-week panel structure” and simplify.
• Agent double-counts users across weeks for “total active users.” Ensure breadth metrics use distinct PersonId counts, not row counts.
• Agent flattens missingness. Native licensed-only M365 Copilot nulls mean unlicensed, rather than licensed inactivity. Failed joins and unavailable sources remain unresolved. Never invent an adoption denominator.
• Recommendations are too generic. If the agent produces vague advice (“increase adoption”), ask it to regenerate with specific org names and numbers from the data.

🔒 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: AI Adoption Across Tools Next: Segmentation & Churn →