
# Monthly Reports

Monthly reports are leadership packs — a regular, structured way for authors to communicate status to the organization's leaders. There is one report per author per month, each carrying a simple health signal and precise controls over who can read it.

## One report per author per month

Reports are scoped to an **author and a month**: each author writes one report for a given month. This keeps the cadence predictable and makes it easy to line up reports across authors and across time. The content itself is **flexible** — there is no rigid template, so authors can shape each report to what matters that month.

## RAG status

Every report carries a **RAG status** that gives leaders an at-a-glance read on health before they open the detail:

| Status | Signal |
|--------|--------|
| Green | On track |
| Amber | Some concern or risk |
| Red | Serious concern, needs attention |

Because the status is a single, consistent field across all reports, leadership can scan a month's packs and immediately see where to focus.

## Visibility

Reports support three visibility options so authors can match the audience to the sensitivity of the content. Owners always retain access.

| Visibility | Who can read it |
|------------|-----------------|
| Private | The author and owners only |
| Group | Members of a named group, plus owners |
| Admins | Owners and admins only |

- Use **private** for a personal or sensitive report meant only for leadership.
- Use **group** to share with a specific team — for example, a department reading its own leadership pack. Groups are managed in [Members, roles & groups](/docs/admin/members-and-roles).
- Use **admins** for reports intended for the leadership tier as a whole.

Choose visibility deliberately: it is the mechanism that keeps a candid report in front of the right eyes and away from the wrong ones.

## What the business should know

This section is a short list of tagged one-liners rather than a paragraph — four unrelated announcements run together as prose is the part of a pack nobody reads.

Each item carries one of three tags, so a reader can pick out what shipped and what went wrong without reading the sentences:

| Tag | Use it for |
|-----|------------|
| Shipped | Something that is now live |
| Note | Everything else — an FYI, an invitation, work in progress |
| Risk | Bad news: a loss, a churned client, something going wrong |

Only **Risk** is coloured. If every line were tinted, the one piece of bad news would stop standing out.

Reports written before this was a list keep their text: the paragraph is split into one item per sentence the first time you open the report, tagged **Note**, ready for you to correct.

## Charts

A report can carry up to **four charts**, drawn from numbers you enter rather than from a pasted image. Each one is a horizontal bar chart — the form a leadership pack actually needs: ranked categories with the figure printed beside each bar.

Because the chart is data, not a picture, it renders crisply in the browser, in the PDF and at any zoom, and next month's chart is an edit rather than a rebuild.

| Setting | What it does |
|---------|--------------|
| Title & subtitle | The reading of the chart — state what it means, not what the axis is |
| Value prefix / suffix | Printed around every number, on bars and axis alike (`$`, `h`, `k`) |
| Show % | Appends each bar's share of the total; set **Percent of** when the bars are a top-N slice of a bigger number |
| Series | A colour and legend entry — use them when bars mean different things. A **hatched** series gets its own legend entry, for a qualifier like recurring revenue |
| Groups | Headings that split the bars into sections, each with an automatic subtotal — type one instead if the bars are rounded and the true total differs |
| Bars | A label and a number, plus an optional label override (`~$100k`) and a small aside (`/year`) |

Enter values on **one scale** for the whole chart: use a suffix of `k` and a value of `87`, not `87000`.

Charts appear at the end of the pack, and on their **own page of the PDF** — the pack itself stays the single page people read in the meeting.

## Who can author reports

Creating a report requires the **`report:author`** permission, or an **admin** or **owner** role. This keeps authorship in the hands of the people responsible for reporting status while still allowing owners and admins to write reports directly. To let a non-admin write reports, grant the report author permission as described in [Members, roles & groups](/docs/admin/members-and-roles).

## A typical monthly rhythm

1. Grant **`report:author`** to the people who should write reports.
2. Each author writes their **one report for the month**, filling in the flexible content.
3. The author sets a **RAG status** — green, amber, or red — to summarize health.
4. The author chooses a **visibility**: private, a specific group, or admins.
5. Leaders scan the month's reports by RAG status and read into the ones that need attention.

## Related

- [Projects & roadmaps](/docs/admin/projects-and-roadmaps)
- [Members, roles & groups](/docs/admin/members-and-roles)
- [Resource planner](/docs/admin/planner)
