# Recurring reports — the weekly business pulse

A short weekly email that tells the owner how the business machinery is
doing: what came in, what went out, what broke. Built once, then it just
arrives. This is one of the highest-value things you can offer a business
owner, because it replaces "I should check on that" with an inbox habit.

There are two versions, and they report different things. Be honest about
the boundary between them.

## The boundary (read this before promising anything)

- **Hub metrics** — execution counts, error rates, time saved, site uptime,
  knowledge usage — come from YOUR tools (`awesomate_dashboard_metrics`,
  `awesomate_n8n_kpis`, `awesomate_n8n_errors`, `awesomate_site_uptime`,
  `awesomate_knowledge_status`). Those tools authenticate with the user's
  PAT on this machine. **A workflow inside their n8n cannot call them**, and
  it can't query n8n's own execution database either.
- **Business data** — leads captured, emails sent, orders processed — lives
  in the data tables, apps, and services their automations already touch.
  **That's what a scheduled workflow CAN report on.**

So: on-demand pulse = you, from hub metrics. Scheduled pulse = a workflow,
from business data. Offer both; never promise the scheduled one will contain
hub metrics.

## Version 1 — on demand, assembled by you (no build needed)

When the user asks "how's everything going?" or it's report time, assemble
it live:

1. `awesomate_dashboard_metrics` — **start here.** The account-wide aggregate
   in one call: executions by status, error rate, time saved, workflows
   total/active, chat sessions and unique users (30d), a 7-day daily trend,
   and the most recent live-workflow failure. It is the single best source
   for a status update or weekly report; the rest fill in around it.
2. `awesomate_n8n_kpis` — per-workflow detail and 7d-vs-prior deltas.
3. `awesomate_n8n_errors` with **`days: 7`** — anything broken, grouped. Pass
   the days: the tool defaults to 30, which turns a weekly report into a
   monthly one without saying so.
4. `awesomate_site_uptime` — per-domain availability and incidents.
5. `awesomate_knowledge_status` — usage vs quota, if they have a knowledge base.

Present it as a short plain-language summary — five lines, not a dashboard:
what ran, what it saved, what failed (and whether it's fixed), site status.
Numbers with no comparison are noise; lead with the deltas.

## Version 2 — scheduled, built once as a workflow

The recipe:

**Schedule Trigger** (Monday 8am, THEIR timezone — ask, don't assume) →
**gather** → **format** → **Send Email** to the owner.

The gather step reads the business data their automations already produce:

- Data tables the workflows write to — new rows this week (leads captured,
  form submissions, orders logged). A `Get row(s)` per table with a
  created-this-week filter, or a Code node to count.
- Services they have credentials for — e.g. their CRM or store, queried
  through the same nodes their workflows already use.
- Their own hosted app's API, if one exists (the app can expose a
  `/api/stats` endpoint — awesomate-app-builder territory).

Format in a Code node (short HTML: 3–6 lines of "this week vs last week"),
then Send Email with their existing email credential.

Build notes:

- Follow the full build loop (validate → draft → approval → activate → test).
  Test by running the workflow once manually and checking the email arrives
  and the numbers match reality — a report that's wrong once is never
  trusted again.
- Store last week's numbers in a small data table so the report can show
  deltas ("12 leads, up from 8"). Same pattern as any remember-between-runs
  need ([datatables.md](datatables.md)).
- Keep it to what their inventory actually has. A report line per data
  source they own beats a template full of "N/A".
- Give the workflow an error plan ([error-handling.md](error-handling.md)) —
  a silent failure in the report workflow is the report lying by omission.

## Offering it

Offer once, in one sentence, when the moment fits (after a health sweep,
after building their first few automations): "Want a short weekly email with
your numbers — what ran, what it saved, what needs attention? I can do it on
demand now, and build the scheduled version once you like the shape."
Starting with Version 1 is the cheap way to find out what they actually want
in it before a workflow exists.