Build a weekly business reporting assistant

Who would use this?

An operations team preparing a recurring performance report.

Teams spend time consolidating approved exports and explaining movements, while missing periods can distort comparisons.

A concrete pilot offer

A reporting workflow that computes metrics in code, labels missing data and drafts an evidence-linked summary for review.

Build the workflow

1. Define source, period, time zone and metric meanings with the client.
2. Validate both comparison periods and reconcile source totals.
3. Compute changes in code, including zero-denominator and missing-data cases.
4. Ask the model to narrate only the supplied results, with caveats and row references.

Walk through the example

The full prompt

Replace the bracketed inputs. Use synthetic or appropriately permitted data. The prompt drafts a result; the surrounding application must enforce permissions, checks and approvals.

Write an internal weekly summary using VERIFIED METRICS only. Preserve the period, units and definitions. Cite each metric_id next to the claim it supports. If prior-period data is missing, say comparison unavailable. Distinguish observations from hypotheses; do not assert causal explanations without supplied evidence. Do not recommend spending changes as if approved.

VERIFIED METRICS: [computed values, metric_id, source, coverage]
KNOWN CONTEXT: [documented facts]
OUTPUT: summary, evidence_map, data_gaps, questions_for_owner

Test before delivery

• Missing data is distinguished from zero.
• Every number links to a computed field.
• The narrative does not invent a cause for a change.

Measure: Preparation time and material correction count.

Is the workflow worth a pilot?

Replace these sample assumptions with the buyer’s figures. Time capacity is not automatically cash savings or revenue.

Delivery effort, setup fees, error costs and demand are not included. Validate the assumptions during the pilot before using them in a proposal.

Scope the service before quoting

Agree the input volume, exact output, integration access, human reviewer, acceptance tests and handover owner. Quote implementation effort separately from ongoing software, API usage and support. Validate customer demand through real conversations.

These examples demonstrate a possible service. They do not report client results or establish an income expectation.

Keep the guide

Go deeper into the engineering

The linked note includes additional examples and primary documentation. Provider capabilities change; check the relevant docs before implementation.