Platform

The board pack is the system, not a copy of it

Your reporting periods, your regions and your board's agreed tolerances held as real structure - so the pack is generated from the data rather than re-keyed out of it every cycle.

Replaces
Excel packs and re-keying
Calendar
13 periods, quarters, whatever you use
Tolerances
Your board's, not defaults
Used by
Group HSEQ, executives, directors

Why do board packs still get built by hand when the data is already in a system?

Because most systems assume calendar months and one hierarchy, and almost no board reports that way. The moment the software cannot hold your reporting calendar, your regional split or your agreed tolerances, someone exports to a spreadsheet and rebuilds the pack there. Now you have two artefacts that can disagree, and you find out mid-meeting. Frontline holds the reporting structure itself - the periods, the regions, the appetite categories and the green and amber thresholds - so the pack and the operational data are the same records.

  • A 13-period calendar is structure, not a workaround
  • Indicators split by region and rolled up to a group position
  • Green and amber tolerances flag drift during the period, not after it
  • A period with no reported value is held as missing, never as zero
13
period calendar held as structureNot approximated into months
1
artefact - the pack and the data are the same records
0
numbers re-keyed between the system and the pack
2
regions reporting on one frameworkANZ and USA

The problem

Two artefacts that can disagree

The system holds the data. A spreadsheet holds the report. Someone moves numbers between them every period.

The re-keying is the visible cost and the smaller one. The real cost is that the board's view and the operational data are separate documents now, and nothing forces them to agree. A number gets updated in one place after the pack is built, and nobody finds out until a director asks about it in the meeting.

It happens because the software could not hold something entirely ordinary. Thirteen periods instead of twelve. Two regions. Tolerances a board actually agreed on, rather than the defaults that shipped with the product.

  • Your calendar, including the ones that are not months
  • Regional splits that roll up without a merge step
  • Thresholds your board signed off, sitting on the indicator

What it does

Your reporting model, configured rather than approximated

Your reporting calendar

Thirteen periods, quarters, a financial year that starts in July. The calendar is the account's structure, so a period is a real thing to report against rather than a date range someone filters by.

Regions and roll-ups

Every indicator can carry a per-region value and a group position. Both are live, and neither is produced by merging exports the week before.

Appetite and tolerance

Indicators sit inside the risk appetite category the board reads them in, with the green and amber thresholds that decide whether a number is inside appetite.

Drift during the period

A value outside tolerance is a visible state the moment it is reported, not a colour someone applies to a cell the week the pack goes out.

Missing is not zero

A period with nothing reported is held as missing. Trends stay honest, and a gap in reporting looks like a gap rather than a good result.

Owners on indicators

Each indicator carries the person accountable for it, so a number outside appetite already has a name next to it before anyone asks in the meeting.

How it works

From last quarter's pack to a live one

  1. Send last quarter's pack

    The actual deck or spreadsheet you sent the board. That is the specification - it already says what you report, how often, and against what.

  2. We configure the structure

    Periods, regions, appetite categories, thresholds and indicator owners, matching the model you already use rather than a standard one.

  3. You check it against the pack you sent

    Same numbers, same shape, generated. If it does not reconcile, that is the conversation worth having.

  4. The next pack builds itself

    Data comes from the registers underneath - risks, incidents, actions, training - so the pack is a view rather than a production.

Included

What you get on day one

  • Your reporting calendar, including non-monthly periods
  • Regional and group views of every indicator
  • Risk appetite categories with green and amber tolerances
  • A named owner on each indicator
  • Full per-period, per-region history behind every number
  • Missing periods held as missing
  • Board and executive read-only access without a licence each
  • The pack exported from live data

Questions we get asked

We report in thirteen periods, not months. Is that a problem?

No, it is the reason this page exists. The calendar is configured as your structure. Thirteen periods, four-four-five, a July financial year - the pack is built against the calendar you actually use.

Do the directors need licences?

No. Board and executive access is read-only to the views and packs that matter to them, without a seat per director.

Where do the numbers come from?

The registers underneath - risks, incidents, actions, training. If the underlying record moves, the indicator moves, which is the whole point of not keeping the pack somewhere else.

Can we still export to slides?

Yes. The pack exports from live data. What changes is that it is generated rather than assembled, so the version in the meeting and the version in the system are the same one.

See your own board pack, generated.

Send us last quarter's pack. When your spot comes up we rebuild it from live data so you can check it reconciles.

  • Your calendar, not calendar months
  • Your board's tolerances
  • No licence per director