Auto-narrative performance reports

Marketing analysts spend a large share of each reporting cycle translating dashboard numbers into prose that leadership can skim. Monthly and quarterly packs usually need the same structure: period context, KPI movement versus plan and prior period, channel or campaign callouts, and a short read on what changed. When that narrative is written by hand from Tableau, Looker, or similar tools, the bottleneck is drafting, not analysis.

In this pattern, an LLM produces a first-pass performance narrative directly from structured KPI extracts for a defined reporting period. Products such as Tableau Pulse and comparable metric-alert or pulse surfaces already surface deltas and thresholds; the model’s job is to turn those extracts into coherent paragraphs that match your house style, not to invent metrics or invent causes.

The output is a draft for analyst review. The model never ships the narrative to stakeholders on its own. Analysts edit tone, correct attribution, add context the extract lacks, and approve distribution. That keeps speed gains without treating generated prose as final truth.

Related work that often sits next to this flow includes Anomaly root-cause explanations when a KPI spike needs a deeper diagnosis, Auto-generated review decks when the same period needs slides as well as narrative, and Conversational reporting in Slack when leaders want ad-hoc answers outside the formal pack.

Treat the reporting period as a required contract, not a soft preference. The extract should name the inclusive start and end dates (or month/quarter label your team uses), the comparison baselines (prior period, year ago, plan or forecast), and the KPI set that belongs in this narrative. Typical fields include metric name, current value, comparison values, absolute and percentage change, and any dimensional breakdowns you allow into the narrative (channel, region, product line, campaign).

Source systems matter for reliability more than for branding. Whether the extract comes from Tableau Pulse subscriptions, a scheduled dashboard export, a metrics API, or a warehouse query behind the BI tool, the payload should be machine-readable and stable across runs. Free-form screenshot text and pasted table dumps increase hallucination risk and make empty-output rules harder to enforce.

Optional context that improves drafts without replacing human judgment includes last period’s approved narrative, a short glossary of metric definitions, and a list of known external events the team already documented (launch dates, outages, major promotions). Feed those only when they are curated; do not scrape chat history or ticket noise into the prompt.

Start from a scheduled or on-demand job keyed to the reporting calendar. Resolve the period first. If the period cannot be determined, stop before calling the model. Next, pull the KPI extract for that period and validate completeness against the required metric list. Only then assemble the prompt: period label, extract payload, style constraints, and any approved glossary or prior narrative snippet.

The model should write in a fixed outline your analysts already use. A practical default is: period framing in one or two sentences; headline KPI movements with numbers from the extract; secondary metrics or segments that moved enough to matter; explicit “not in extract” placeholders where the draft would otherwise speculate; and a closing section labeled as draft hypotheses for the analyst to keep, rewrite, or delete. Require the model to quote figures as supplied and to refuse to fill gaps with estimates.

After generation, route the draft to the owning analyst (or a rotation queue) with the source extract attached. The analyst’s job is verification and voice, not rewriting from a blank page: confirm every number against the extract or live dashboard, replace weak causal language with verified drivers, and strip anything that sounds confident without evidence. Only after approval does the narrative enter email, wiki, deck notes, or the QBR pack.

When the same period also needs slides or Slack summaries, keep this narrative as the approved text source rather than regenerating independently. Separate generations for the same extract drift; one approved draft reused downstream stays consistent.

Return empty output (no narrative body) when the KPI extract is missing, empty, malformed, or fails schema validation. Return empty output when the reporting period is missing, ambiguous, overlapping, or does not match the extract’s period fields. Do not invent a period from “latest available” data, and do not stitch partial extracts into a fake complete report.

Partial extracts deserve the same discipline. If a required headline KPI is absent, fail closed for the full narrative or emit only a structured error listing missing metrics, depending on your ops preference. Either choice is better than a fluent story that silently omits pipeline or CAC. Log the failure with period, extract id, and missing fields so analysts can fix the pipeline instead of debugging prose.

When comparison baselines are incomplete (for example, plan exists but prior period does not), the safer pattern is empty output or a short non-narrative status message, not a draft that pretends YoY or vs-plan language is available. Soften only when your product explicitly supports “period-only, no comparison” mode and the prompt forbids comparative claims.

Before distribution, confirm the period label matches the extract and the calendar your stakeholders expect. Spot-check every numeric claim against the source values; treat rounding and unit differences (currency, thousands, percentages) as defects to fix in the draft or the extract, not as stylistic noise.

Remove or rewrite causal statements the extract does not support. “Paid search efficiency improved after creative refresh” is acceptable only if that driver is documented in approved context or verified by the analyst. Prefer descriptive language (“Paid search CPA decreased 12% vs prior period”) until a cause is confirmed. Align terminology with the glossary so “revenue,” “bookings,” and “pipeline” are not used interchangeably.

Check tone for the audience: executive packs need shorter paragraphs and fewer channel digressions; channel owners may need segment detail. Keep speculative next steps in a clearly marked section or cut them. When you reuse the narrative into decks or Slack, re-read after paste; formatting loss often hides dropped caveats.

Finally, record approval (who, when, period). That audit trail matters when a later anomaly review or board pack cites the same month, and it makes it obvious that the LLM produced a draft, not the final word.

Standardize the extract schema across brands or regions before you scale the prompt. Prompt tweaks cannot fix inconsistent metric names or shifting dimension grains. Version the style guide the model follows the same way you version dashboard definitions: when a KPI definition changes, update glossary and extract together so narratives do not lag the dashboard.

Run the job early enough that analysts still have review time before the stakeholder deadline. Speed comes from eliminating blank-page drafting, not from skipping judgment. Pair this use case with anomaly explanation flows when a KPI breach needs root-cause depth, and with review-deck generation when leadership expects slides from the same approved story.

Measure operational success with cycle time to first usable draft, edit distance or time-to-approve, and rate of empty or failed runs (pipeline health), not with vanity scores on how “fluent” the prose sounds. Fluent and wrong is worse than empty and honest.