30 Claude Prompts for Looker Studio

You are a Looker Studio calculated field specialist who writes exact formula syntax. <context> I know what metric I want but I do not remember the correct Looker Studio calculated field syntax to produce it. </context> <inputs> - Plain description of the metric: [DESCRIBE WHAT YOU WANT CALCULATED] - Field names available in the data source: [LIST FIELD NAMES] - Data source type: [E.G. GOOGLE ANALYTICS 4, GOOGLE SHEETS, BIGQUERY] - Any edge case to handle, such as division by zero: [DESCRIBE OR "NONE"] </inputs> <task> Write the exact Looker Studio calculated field formula that produces the described metric, using the field names given. </task> <constraints> Use only functions that exist in Looker Studio's formula language. Handle the stated edge case explicitly with a CASE WHEN or IFNULL wrapper rather than ignoring it. Do not use pseudocode, the formula must be pasteable as-is. </constraints> <format> Return the formula in a code block first, then explain what each part of the formula does in 2 to 3 short sentences below it. </format>

You are a Looker Studio troubleshooting expert who fixes broken calculated field formulas. <context> I wrote a calculated field and it is either throwing an error or returning a value that clearly looks wrong, and I need to find out why. </context> <inputs> - Current formula: [PASTE THE FORMULA] - Error message shown, if any: [PASTE ERROR OR "NO ERROR, JUST WRONG NUMBERS"] - What the field is supposed to calculate: [DESCRIBE INTENDED RESULT] - Sample of what it is actually returning: [DESCRIBE OR PASTE SAMPLE OUTPUT] </inputs> <task> Identify the likely cause of the error or wrong output and provide a corrected formula. </task> <constraints> Explain the root cause before giving the fix, do not just paste a new formula with no explanation. Consider common Looker Studio pitfalls such as aggregation mismatches, data type mismatches, and blended field naming collisions. If more information is needed to diagnose confidently, say what it is. </constraints> <format> First line: likely root cause in one sentence. Then the corrected formula in a code block. Then a short bullet list of what changed and why. </format>

You are a Looker Studio analyst who specializes in period-over-period comparison metrics. <context> I want to show change over time in a scorecard or table but my data source only has raw daily values, not a built-in comparison metric. </context> <inputs> - Base metric name: [BASE METRIC NAME] - Comparison period: [E.G. WEEK OVER WEEK, MONTH OVER MONTH, YEAR OVER YEAR] - Date field name in the source: [DATE FIELD NAME] - Whether Looker Studio's built-in comparison date range will be used or a manual formula is needed: [BUILT-IN OR MANUAL] </inputs> <task> Provide the setup steps or calculated field formula needed to display the percentage change of the base metric over the stated comparison period. </task> <constraints> If the built-in comparison date range feature is the right tool, say so and explain the setup instead of writing an unnecessary formula. If a manual formula is genuinely required, write it using only valid Looker Studio syntax and handle the case where the prior period value is zero. </constraints> <format> Open with a one-sentence recommendation of which approach to use. Then numbered setup steps or a formula code block, whichever applies. Close with one sentence on how to label the field for a non-technical viewer. </format>

You are a Looker Studio formula specialist who builds segmentation logic with CASE WHEN statements. <context> I need to bucket a continuous or categorical field into named segments for filtering and charting, and I want the CASE WHEN logic written correctly the first time. </context> <inputs> - Field to segment: [FIELD NAME] - Segment definitions: [LIST THE BUCKETS AND THEIR RULES, E.G. "HIGH VALUE = ORDER TOTAL OVER 200"] - Data source type: [E.G. GOOGLE ANALYTICS 4, GOOGLE SHEETS] - What the new field should be named: [NEW FIELD NAME] </inputs> <task> Write a CASE WHEN calculated field that buckets the source field into the named segments exactly as defined. </task> <constraints> Cover every stated bucket plus a fallback ELSE branch for anything unmatched, do not leave rows uncategorized. Use consistent, human-readable label text for each bucket, not abbreviations. Keep the syntax valid for Looker Studio, not generic SQL. </constraints> <format> Return the full CASE WHEN formula in a code block, followed by a short table listing each bucket name, its rule, and an example value that would fall into it. </format>

You are a data cleaning specialist who fixes inconsistent categorical data inside Looker Studio calculated fields. <context> My source data has the same real-world category spelled or capitalized differently across rows, for example a channel or product name entered inconsistently, and it is splitting my charts into duplicate slices. </context> <inputs> - Field with inconsistent values: [FIELD NAME] - Known variants and what they should map to: [LIST VARIANTS AND TARGET LABEL] - Data source type: [E.G. GOOGLE SHEETS, GOOGLE ANALYTICS 4] - Target field name for the cleaned dimension: [NEW FIELD NAME] </inputs> <task> Write a calculated field formula that normalizes all listed variants into their single target label, with a sensible fallback for anything not listed. </task> <constraints> Use REGEXP_MATCH or CASE WHEN with LOWER() so the matching is not case sensitive where that matters. Do not silently drop unmatched values, route them to a clearly labeled "Other or Unmapped" bucket instead. Keep the formula maintainable, not a giant unreadable one-liner. </constraints> <format> Return the formula in a code block. Below it, list the mapping table you used as a bulleted list, and add one sentence on how to spot new unmapped variants going forward. </format>

You are a data visualization expert who advises on chart type selection for Looker Studio dashboards. <context> I have a dataset and a message I am trying to communicate with it, and I am not sure which Looker Studio chart type will make the point most clearly. </context> <inputs> - Metric and dimension involved: [DESCRIBE METRIC AND DIMENSION] - Number of categories or series: [NUMBER] - Message I want the chart to communicate: [DESCRIBE THE MESSAGE OR INSIGHT] - Audience viewing the chart: [AUDIENCE DESCRIPTION] </inputs> <task> Recommend the single best Looker Studio chart type for this data and message, and explain why it beats the next best alternative. </task> <constraints> Pick from chart types that actually exist in Looker Studio, such as scorecard, time series, bar, geo map, table, pie, or bullet. Reject chart types that are commonly misused for this kind of data, such as pie charts with too many slices, and say why. Give one alternative only if the primary pick has a real limitation worth knowing. </constraints> <format> First line: recommended chart type in bold-style text. Then 2 to 3 sentences of reasoning. Then one sentence naming a runner-up chart type and its tradeoff. </format>

You are a data integrity reviewer who audits dashboards for misleading visual choices. <context> Someone flagged that a chart in my report looks off or gives a wrong impression, and I want a second opinion before I present it. </context> <inputs> - Chart type currently used: [CHART TYPE] - What the chart shows: [DESCRIBE METRIC, DIMENSION, AND TIME RANGE] - Axis or scale settings: [DESCRIBE, E.G. "Y AXIS STARTS AT 40 NOT 0"] - What impression it currently gives versus what is actually true: [DESCRIBE THE GAP] </inputs> <task> Identify exactly what design choice is creating the misleading impression and specify the fix in Looker Studio settings terms. </task> <constraints> Name the specific setting to change, such as axis minimum, sort order, or chart type swap, not a vague suggestion to "make it clearer". Do not assume malicious intent, treat it as a default-settings problem to correct. If the underlying data itself is the real problem rather than the chart design, say that plainly. </constraints> <format> One sentence naming the specific issue. One sentence naming the exact Looker Studio setting or chart change to fix it. One closing sentence on how to verify the fix looks correct after applying it. </format>

You are a dashboard design consultant who handles high-cardinality comparison charts. <context> I need to compare a metric across a large number of categories, such as many products, regions, or campaigns, and a standard bar chart is getting cluttered. </context> <inputs> - Number of categories: [NUMBER] - Metric being compared: [METRIC NAME] - Whether ranking order matters: [YES OR NO] - Whether the viewer needs to see every category or just the leaders and laggards: [EVERY CATEGORY OR TOP/BOTTOM ONLY] </inputs> <task> Recommend a chart configuration, including chart type, sort order, and any top-N filter, that keeps a large category comparison readable. </task> <constraints> Do not recommend a chart type that becomes unreadable past roughly 10 to 15 categories without a filter, such as an unfiltered pie chart. If a table with conditional formatting would communicate the comparison better than a chart, say so. Address how ties or a long tail of small values should be handled. </constraints> <format> Recommend the chart type and configuration in a short numbered list of settings to apply. Close with one sentence on how to handle the long tail of remaining categories. </format>

You are a growth analytics consultant who builds funnel visualizations in Looker Studio. <context> I have counts for each stage of a process and I want to visualize the drop-off between stages clearly for a team that is trying to find where people fall out of the process. </context> <inputs> - Funnel stages in order: [LIST STAGES IN ORDER] - Metric at each stage: [DESCRIBE THE COUNT AT EACH STAGE] - Data source: [DATA SOURCE NAME] - Whether Looker Studio's native funnel chart is being used or a workaround with bar or scorecard elements: [NATIVE FUNNEL OR WORKAROUND] </inputs> <task> Specify how to build the funnel visualization, including any calculated field needed for stage-to-stage conversion percentage, and how to visually flag the stage with the steepest drop-off. </task> <constraints> If using a workaround because the native funnel chart does not fit the data shape, explain exactly why and what elements to use instead. Include the calculated field formula for conversion rate between adjacent stages. Keep the visualization to one chart or chart group, not scattered across multiple pages. </constraints> <format> Open with the chart approach in one sentence. Then the calculated field formula in a code block. Then a short note on which stage to visually highlight and how. </format>

You are a brand-aware dashboard designer who sets up formatting standards for client-facing Looker Studio reports. <context> I am finalizing a report that a client will see with their own name on it and I want the formatting to look intentional and consistent, not like default Looker Studio output. </context> <inputs> - Client or brand colors: [LIST HEX CODES OR COLOR NAMES] - Report tone: [E.G. CORPORATE, PLAYFUL, MINIMAL] - Number of distinct chart types on the report: [NUMBER] - Whether dark mode or light mode theme is preferred: [LIGHT OR DARK] </inputs> <task> Specify a consistent formatting scheme covering chart color palette, font choice, scorecard comparison color logic, and background treatment for the whole report. </task> <constraints> Limit the palette to a primary color, one or two accent colors, and a neutral gray for chart elements that need it, do not recommend a rainbow of colors. Specify what color represents positive versus negative change on scorecards so it stays consistent across every page. Keep recommendations achievable inside Looker Studio's theme and style panel, not external design tools. </constraints> <format> Return a short table with columns: Element, Setting, Reason. Cover palette, font, positive/negative color logic, and background as separate rows. </format>

You are a Looker Studio data architect who designs blended data sources across multiple systems. <context> I need to combine data from two different sources into one blend so I can compare or join metrics that currently live in separate tables. </context> <inputs> - Source A and its key fields: [SOURCE A NAME AND FIELDS] - Source B and its key fields: [SOURCE B NAME AND FIELDS] - Field that should join the two sources: [JOIN FIELD] - Metrics needed from each side after blending: [LIST METRICS FROM EACH SOURCE] </inputs> <task> Specify how to configure the blend, including which join key to use, what join type to select, and any field renaming needed so the join key matches exactly between sources. </task> <constraints> Flag if the join field is likely to have mismatched formatting between the two sources, such as date formats or casing, and specify how to fix that before blending. Recommend the correct join type, left outer versus inner, based on whether missing matches should still appear. Do not exceed the join key count Looker Studio blending supports. </constraints> <format> Numbered setup steps for the blend configuration. End with one sentence flagging the most likely data mismatch to check first. </format>

You are a Looker Studio troubleshooting specialist who fixes broken blended data results. <context> A chart built on a blended data source is showing totals that do not match what I see when I check each underlying source separately, and I need to find the cause. </context> <inputs> - Sources in the blend: [LIST SOURCES] - Join field and join type used: [JOIN FIELD AND JOIN TYPE] - Metric showing the wrong total: [METRIC NAME] - Expected total versus what is displaying: [EXPECTED VS ACTUAL] </inputs> <task> Diagnose the likely cause of the total mismatch, considering common blending pitfalls like fan-out duplication from a one-to-many join, mismatched join keys, or wrong join type. </task> <constraints> Name the specific mechanism causing the discrepancy, such as row duplication from a one-to-many relationship, rather than a generic "check your data" answer. Propose the exact fix, whether that is changing the join type, pre-aggregating one source before blending, or using a different join key. If the fix requires restructuring outside Looker Studio, say so. </constraints> <format> One sentence naming the likely mechanism. One paragraph explaining why it produces this specific symptom. A final numbered list of the fix steps. </format>

You are a Looker Studio migration specialist who moves reports between data source backends without downtime. <context> I need to switch a report's underlying data source, for example from a spreadsheet to a database connection, and I do not want existing charts to break or need to be rebuilt from scratch. </context> <inputs> - Current data source type: [CURRENT SOURCE TYPE] - Target data source type: [TARGET SOURCE TYPE] - Number of charts and calculated fields relying on the current source: [APPROXIMATE COUNT] - Whether field names will change between old and new source: [YES OR NO, LIST CHANGES IF ANY] </inputs> <task> Produce a migration plan that keeps existing charts intact by aligning field names and types between the old and new source before the swap, and specify how to test the new source safely before committing to it. </task> <constraints> Recommend testing the new source as a duplicate report first rather than swapping the live report's data source directly. Call out any field type mismatch, such as a date stored as text in the new source, that would break existing calculated fields. Keep the plan to concrete steps, not general migration advice. </constraints> <format> Return a numbered step-by-step migration plan. End with a short checklist of what to verify in the test report before switching the live one. </format>

You are a Looker Studio governance specialist who sets up secure data access for agencies with multiple clients. <context> I have one large combined dataset covering multiple clients and I need each client to only see their own rows when they view a shared report link, not the whole dataset. </context> <inputs> - Data source type: [DATA SOURCE TYPE] - Field that identifies which client a row belongs to: [CLIENT ID FIELD] - Number of clients: [NUMBER] - Whether email-based row-level security through the data source owner's credentials is available: [YES OR NO] </inputs> <task> Specify how to configure the data source and filters so each client viewer only sees rows matching their own client identifier, using either row-level security features or filter-based workarounds. </task> <constraints> If true row-level security is not available for this data source type, propose the correct filter-based workaround, such as a filtered view per client or a URL parameter driven filter, and be explicit that this is less secure than native row-level security. Do not claim a security guarantee that Looker Studio cannot actually enforce. </constraints> <format> One paragraph explaining which approach fits this data source. Then numbered setup steps. Close with one sentence honestly stating the security limitation of the chosen approach. </format>

You are a data documentation specialist who writes field dictionaries for handoff between analysts. <context> I am handing this Looker Studio report off to another analyst or team and I want a clear reference of what each field in the data source actually means, since some names are not self-explanatory. </context> <inputs> - Data source name: [DATA SOURCE NAME] - List of fields with any notes you already have: [PASTE FIELD LIST AND ANY NOTES] - Calculated fields and their formulas: [PASTE CALCULATED FIELDS OR NONE YET] - Known quirks or caveats about the data: [DESCRIBE OR NONE] </inputs> <task> Produce a field dictionary document that explains what each field represents, its data type, and whether it is a raw source field or a calculated field, plus a caveats section for known data quirks. </task> <constraints> Write definitions a new analyst with no prior context could understand without asking follow-up questions. Mark calculated fields clearly and include their formula logic in plain English, not just the raw formula. Do not omit the caveats section even if it is short. </constraints> <format> Return a table with columns: Field Name, Type, Definition, Source or Calculated. Follow with a short "Caveats" section as bullet points. </format>

You are a self-service BI consultant who designs filter controls for Looker Studio dashboards. <context> I want viewers to be able to slice a report themselves without me building a separate page for every possible cut of the data. </context> <inputs> - Dimensions viewers commonly want to slice by: [LIST DIMENSIONS] - Report audience technical comfort level: [E.G. NON-TECHNICAL EXECUTIVES, ANALYSTS] - Number of pages the filters should apply across: [NUMBER OR ALL PAGES] - Any dimension that should NOT be filterable for privacy or clutter reasons: [LIST OR NONE] </inputs> <task> Recommend which filter control types to use for each dimension, such as drop-down list, fixed-size list, or date range control, and specify which should apply report-wide versus page-level. </task> <constraints> Limit the total number of filter controls shown at once to what a non-technical viewer can process, generally no more than 4 or 5 visible controls. Recommend report-level scope for filters that matter everywhere, like date range, and page-level scope for filters specific to one page's topic. Exclude any dimension marked as not filterable. </constraints> <format> Return a table with columns: Dimension, Control Type, Scope (Report or Page), Reason. Close with one sentence on default filter values to set so the report is not empty on first load. </format>

You are a Looker Studio interactivity specialist who builds parameter-driven controls. <context> I want one chart to let the viewer toggle between different metrics, such as switching a time series between revenue and units sold, without duplicating the chart multiple times. </context> <inputs> - Metrics to switch between: [LIST METRICS] - Chart type the switcher will control: [CHART TYPE] - Data source type: [DATA SOURCE TYPE] - Whether the metrics are already the same data type and unit: [YES OR NO] </inputs> <task> Specify how to build a parameter and a calculated field that lets a single chart display whichever metric the viewer selects from a control. </task> <constraints> Write the CASE WHEN calculated field that reads the parameter value and returns the correct metric. Flag if the metrics have incompatible units or scales that would make switching between them on the same axis misleading. Keep the setup to one parameter and one calculated field, not a workaround requiring duplicate charts. </constraints> <format> Numbered setup steps for the parameter and control. Then the calculated field formula in a code block. Close with one sentence flagging any unit mismatch risk. </format>

You are a Looker Studio debugging specialist who resolves filter interaction problems. <context> A chart's numbers look wrong and I suspect an interaction between a page-level filter, a chart-level filter, or a control is silently excluding data the viewer expects to see. </context> <inputs> - Chart in question and its metric: [CHART AND METRIC] - Filters currently applied at report, page, and chart level: [LIST EACH LEVEL'S FILTERS] - Control values currently selected: [DESCRIBE CURRENT CONTROL SELECTIONS] - Expected total versus displayed total: [EXPECTED VS ACTUAL] </inputs> <task> Identify which filter layer is most likely causing the unexpected exclusion and specify how to confirm and fix it. </task> <constraints> Walk through report-level, page-level, and chart-level filters in that order since Looker Studio applies them cumulatively, and identify where the conflict most likely sits. Recommend a specific diagnostic step, such as temporarily clearing filters one level at a time, rather than guessing blind. Give the fix as a specific setting change. </constraints> <format> A short numbered diagnostic sequence checking each filter level in order. End with the most likely fix in one bolded-style sentence. </format>

You are a dashboard UX specialist who designs drill-down navigation in Looker Studio. <context> I have a summary page and a detail page and I want clicking an item on the summary chart to take the viewer to the relevant filtered detail page instead of them navigating manually. </context> <inputs> - Summary chart type and dimension: [CHART TYPE AND DIMENSION] - Detail page name and what it shows: [DETAIL PAGE NAME AND CONTENT] - Dimension that should carry over as a filter when drilling down: [DIMENSION NAME] - Whether native drill-down or a page navigation link with filter passing is preferred: [DRILL-DOWN OR NAVIGATION LINK] </inputs> <task> Specify how to configure the interaction so clicking a value on the summary chart filters the detail page to that value automatically. </task> <constraints> Recommend Looker Studio's native drill-down feature where the dimension hierarchy supports it, and only recommend the page navigation and filter-control workaround where native drill-down does not apply. Be explicit about which setting enables cross-filtering between the chart and the linked page or control. Keep the interaction to a single click, not a multi-step process for the viewer. </constraints> <format> One sentence naming the chosen approach. Then a numbered setup sequence. Close with one sentence describing what the viewer experiences when they click. </format>

You are a report distribution specialist who configures sensible defaults for externally shared Looker Studio reports. <context> This report gets shared as a link with people outside my organization and I want it to open on a sensible, relevant view rather than an empty or overwhelming default state. </context> <inputs> - Report topic: [REPORT TOPIC] - Filters and date range controls present: [LIST FILTERS AND CONTROLS] - Most common use case when someone opens the link cold: [DESCRIBE TYPICAL USE CASE] - Whether the report should default to the most recent complete period or a fixed period: [MOST RECENT OR FIXED, SPECIFY] </inputs> <task> Specify the default value for every filter and control so a first-time external viewer sees a complete, relevant view without needing to touch anything. </task> <constraints> Use a rolling default date range, such as last 30 days, rather than a fixed date range that will look stale months later, unless the use case specifically calls for a fixed period. Ensure every chart has data visible at the default settings, do not default into an empty state. Note any control that should be locked from viewer editing versus left open. </constraints> <format> Return a table with columns: Control or Filter, Default Value, Editable by Viewer (Yes or No), Reason. </format>

You are a business analyst who writes plain-English narrative summaries to accompany dashboard reviews. <context> I am sending this dashboard to stakeholders who will not dig into every chart themselves, and I want a short written summary that tells them what happened and what to pay attention to. </context> <inputs> - Reporting period: [REPORTING PERIOD] - Key metric values and their change versus prior period: [LIST METRICS WITH VALUES AND CHANGE] - Any notable event that affected the numbers: [DESCRIBE EVENT OR "NONE KNOWN"] - Audience: [AUDIENCE DESCRIPTION] </inputs> <task> Write a short narrative summary that states what happened, why it likely happened if a cause is known, and what the reader should watch next period. </task> <constraints> Keep the summary under 150 words. Lead with the single most important number, not a generic opening line. Do not speculate on causes beyond what was given as a known event, flag uncertainty plainly instead of inventing a reason. Avoid restating every chart, focus on what changed and why it matters. </constraints> <format> Return plain prose in 2 to 3 short paragraphs, no headers needed. End with one sentence naming the thing to watch next period. </format>

You are a data analyst preparing to explain an unexpected chart pattern to a manager before a meeting. <context> A chart in my report shows a spike, drop, or unusual pattern and I need to prepare a clear explanation, or a clear statement that I do not yet know the cause, before someone asks about it. </context> <inputs> - Metric and the anomaly observed: [DESCRIBE THE METRIC AND THE UNUSUAL PATTERN] - Date range the anomaly occurred: [DATE RANGE] - Hypotheses already considered: [LIST HYPOTHESES OR "NONE YET"] - Data available to investigate further: [LIST AVAILABLE DATA OR TOOLS] </inputs> <task> Draft a short explanation to bring to the meeting that states the anomaly plainly, lists the most plausible hypotheses in order of likelihood, and specifies what data check would confirm or rule out each one. </task> <constraints> Do not present a guess as a confirmed cause, clearly separate confirmed facts from hypotheses. Rank hypotheses by plausibility given what is known, not alphabetically. Keep it honest if the true cause is genuinely unknown rather than forcing a confident-sounding answer. </constraints> <format> One sentence stating the anomaly. A numbered list of hypotheses, each with the specific data check that would confirm it. One closing sentence on next steps. </format>

You are a data communicator who translates technical metric definitions into plain language for non-technical stakeholders. <context> A stakeholder asked what a metric on the dashboard actually means and my technical definition is not landing, so I need a plain-language explanation with a concrete example. </context> <inputs> - Metric name: [METRIC NAME] - Technical definition or formula: [PASTE TECHNICAL DEFINITION OR FORMULA] - Stakeholder's role and background: [ROLE AND BACKGROUND] - A real example value from the dashboard to illustrate with: [EXAMPLE VALUE OR SCENARIO] </inputs> <task> Write a plain-language explanation of the metric that a non-technical stakeholder can repeat back correctly, using the real example to make it concrete. </task> <constraints> Avoid restating the technical formula as the explanation, translate it into an everyday comparison or scenario instead. Keep it to 3 to 4 sentences. Do not oversimplify to the point of being inaccurate, the plain version must still be true. </constraints> <format> Return 3 to 4 sentences of plain prose, no bullet points, ending with the concrete example worked through in one sentence. </format>

You are a reporting lead preparing talking points for a recurring dashboard review meeting. <context> I am presenting this dashboard live in a meeting shortly and I want a short set of talking points rather than reading numbers off the screen verbatim. </context> <inputs> - Dashboard topic and reporting period: [TOPIC AND PERIOD] - Key metrics and their current values with trend direction: [LIST METRICS, VALUES, TREND] - Decisions the meeting needs to make, if any: [DESCRIBE DECISIONS OR "INFORMATIONAL ONLY"] - Meeting length: [MEETING LENGTH IN MINUTES] </inputs> <task> Produce a talking points outline that covers the key metrics in order of importance, connects them to the decisions the meeting needs to make, and fits the stated meeting length. </task> <constraints> Order points by what matters most to the decision at hand, not the order charts appear on the dashboard. Include a suggested time allocation per section so the presenter can pace the meeting. Do not write full sentences to read aloud, write outline-style points a presenter can speak from naturally. </constraints> <format> Return a numbered outline with a time allocation in minutes next to each section header, and short sub-bullets of talking points under each. </format>

You are a client-facing analyst who writes follow-up emails after sharing a Looker Studio report link. <context> I just sent a stakeholder or client a link to their updated dashboard and I want a short accompanying email that highlights what to look at first instead of leaving them to figure it out alone. </context> <inputs> - Recipient name and relationship: [RECIPIENT NAME AND RELATIONSHIP, E.G. CLIENT, INTERNAL STAKEHOLDER] - Report link placeholder: [REPORT LINK] - One or two headline results from this period: [DESCRIBE HEADLINE RESULTS] - Any action needed from the recipient, such as feedback or a decision: [DESCRIBE ACTION OR "NONE, INFORMATIONAL"] </inputs> <task> Draft a short email that shares the report link, highlights the headline results in plain language, and states clearly what action, if any, is needed from the recipient. </task> <constraints> Keep the email under 120 words. Do not bury the report link, place it near the top. State the requested action as a direct, specific ask if one exists, not a vague "let me know your thoughts". Match a professional but not stiff tone. </constraints> <format> Return a subject line, then the email body as short paragraphs, no more than 120 words total. </format>