Business dashboards · New Zealand

Dashboards designed from the decision backwards.

A dashboard is useful when it helps a named person make a named decision at the right time. We start with the question, source, freshness and action. Only then do we decide whether the right output is a dashboard, report, queue or alert.

Build one decision brief See the synthetic examples

Based inChristchurch

Working acrossNew Zealand

Starting pointYour current report or question

Decision view · synthetic records

Do any open enquiries need reassignment today?

Data through 08:30

01 Question02 Source03 Definition04 Action

Requires review3of 12 open enquiries

ENQ-1048Owner missingAssign

ENQ-1042Reply due todayReview

ENQ-1039Source update delayedCheck source

Basis: invented records used to explain hierarchy. This is not a live client dashboard or a measured result.

01 · Decide

Question before chart

Name the decision before choosing the display.

A useful dashboard brief can begin without sending us customer, employee or financial records. Describe the decision, the timing and the source. The worksheet will suggest the smallest output worth considering.

This local worksheet does not submit or store the selections.

Build a first decision brief Who needs to decide? What must they decide? When is the decision made? Where is the current information? What is least trustworthy today?

First useful outputDaily exception queue

Start with records that need attention, the reason, the responsible owner and the next review time.

Decision owner: Owner or director
Refresh position: Label the last successful spreadsheet update
First data task: Confirm what counts as open and who owns each record
Do not assume: A chart will make uncertain source data reliable

02 · Roles

One source, different responsibilities

The facts stay still. The useful view changes.

Staff, managers, owners, analysts and customers should not receive the same screen. Each view below uses the same five fictional records. What changes is emphasis, permission and action.

Staff view

What do I need to complete next?

Due 10:00JOB-204

Add the approval reference before handover.

Open record

Due 12:30JOB-208

Check the field photos and return any missing detail.

Review submission

UnassignedJOB-211

Waiting for a responsible owner.

Escalate

Manager view

Which exceptions need an owner today?

2actionable exceptions1source warning

Record	Exception	Owner	Next action
JOB-204	Approval overdue	M. Rangi	Review at 10:00
JOB-211	Unassigned	Not assigned	Allocate today
JOB-219	Feed delayed	System owner	Check source

Owner view

Is work moving, and where is confidence weak?

On-time handoffs8 / 10Illustrative weekly count

The trend is shown beside the source warning. It does not hide the delayed feed or turn ten records into a performance claim.

Analyst view

Can the number be reproduced and explained?

SourceJob registerRuleCurrent stage mapping v1.3MeasureOn-time handoff

Population: Accepted jobs due in the selected week
Excluded: Cancelled and test records
Time basis: Pacific/Auckland
Quality state: One source feed delayed

Approved customer view

What can the customer safely and usefully see?

Reference JOB-204Waiting for approval

Latest approved update: supporting record received. The next customer-visible update is due after internal review.

Internal cost, staff, risk and source-quality information stays restricted. External wording and fields require approval.

03 · Data basis

Every number needs an explanation

A polished chart cannot repair an uncertain definition.

A dashboard should make source, calculation, freshness, limitations and ownership easier to inspect. If the information cannot yet support the decision, the honest first deliverable may be a data-quality register or a simpler report.

Metric contract · example

Open enquiries requiring attention

For deciding whether a manager should reassign or follow up an enquiry today.

Definition: An accepted enquiry with no completed response and a due time before the next review.
Population: Enquiries received through approved intake routes and accepted for review.
Formula: Count of included enquiries where response is incomplete and the due rule is met.
Unit and time: Number of enquiries at the daily 08:30 review point.
Source: Enquiry register. Source owner: service manager.
Transformation: Rules version 1.3 maps source status, response and due time into the review state.
Freshness: Data through 08:30. Last attempted refresh 08:35. Last successful refresh 08:31.
Included: Accepted enquiries with a named response requirement.
Excluded: Spam, tests, declined work and enquiries waiting for customer information.
Exception: Missing owner, overdue response or source update older than the accepted limit.
Action: Assign, contact, request missing detail or record why no action is required.
Definition control: Version 2.1, effective 15 September. Owner review due 15 December.

Missing is not zero

Twelve states that must not be blended together.

A blank, old or restricted value can mean very different things. The interface and the response should show the difference.

0Zero observed
The source was checked and the count is genuinely zero.
MVMissing value
The field should exist for this record but is empty.
NCNot collected
The field is not captured in the current process.
DLDelayed
The expected update has not arrived by its agreed time.
STStale
A prior value exists but is older than the accepted limit.
SFSource failed
The latest refresh or connection did not complete.
PRPrivacy restricted
The viewer is not authorised to see the underlying value.
SPSuppressed
The value is intentionally grouped or hidden by an approved rule.
CECalculation error
The measure could not be produced from the accepted inputs.
NANot applicable
The measure does not apply to this record or period.
PTPartial
Only part of the expected population or period is available.
CTContradictory
Two accepted sources or controls currently disagree.

04 · Output

Choose the smallest useful form

Not every reporting problem needs a dashboard.

Interaction, live connections and extra screens add weight. The output should match the frequency, audience, risk and action.

When the need is	Start with	Why	Watch for
A fixed monthly governance review	Versioned report	Commentary and comparison may matter more than filtering.	Definition changes and unexplained restatement.
Daily exception handling	Action queue	People need ownership and the next step, not a trend wall.	Alert fatigue and items without a close-out state.
A defined threshold event	Alert plus review link	A person only needs to look when the agreed condition occurs.	Failed delivery, weak thresholds and no responsible owner.
Several legitimate questions over shared data	Interactive dashboard	Filters and drill-down help authorised users investigate.	Conflicting filters, permissions and stale extracts.
Restricted external status	Customer portal	Only approved fields and wording should leave the organisation.	Internal information exposed by drill-through or export.
A safety-critical or physical action	Separate engineered control interface	Visual reporting is not operating authority.	Fail-safe behaviour, specialist review and physical acceptance.

05 · Situations

The dashboard follows the decision

Different operating questions, organised in one place.

Choose the question closest to the work. Each section identifies what should be visible, which definitions matter and where human responsibility remains.

01OperationsWhat is open, late, blocked or unassigned today?

Bring active workload, queue age, bottlenecks, capacity and ownership into one operating view. The screen should lead to assignment, escalation or a documented reason to wait.

Define: Open, blocked, overdue, waiting, unupdated and closed.
Show: Source time, queue age, service-level basis, owner and next review.
Review: Daily exceptions, weekly patterns and drill-down to the accepted record.
Boundary: Late source data is not proof that the underlying work is late, and a forecast remains an assumption.

02ProjectsWhich milestone, risk or decision is changing delivery?

Connect portfolio and project views to the approved baseline, current forecast, actual progress, dependencies, risks, issues, changes and decisions.

Define: Baseline, forecast, actual, risk, issue, decision and approved change.
Show: Next milestone, unresolved decision, responsible owner, evidence and source date.
Protect: Audience controls for commercial, internal and approved customer information.
Boundary: A percentage complete must not hide unresolved work, changed scope, late updates or budget assumptions.

03Field operationsWhat was captured, stored, submitted, reviewed, returned or accepted?

Keep job identity, forms, photos, location context, synchronisation and office review connected without flattening each technical state into “complete”.

Define: Captured on device, stored locally, queued, server accepted, reviewed, returned and accepted.
Show: Job reference, author, event time, sync state, reviewer and customer visibility.
Plan: Offline behaviour, urgent response, retention, export and failed submission handling.
Boundary: A digital submission is not specialist acceptance, safety approval or evidence that urgent action occurred.

04SchedulingWhere will confirmed demand exceed suitable capacity?

Compare tentative and confirmed work with people, skills, assets, leave, travel, setup and other real constraints.

Define: Tentative, confirmed, assigned, available, capable and unavailable.
Show: Double bookings, skill gaps, forward pressure, travel buffers and change history.
Respond: Name who resolves each conflict and whether a notification was merely sent or acknowledged.
Boundary: Calendar space is not proof of suitable capacity, and the nominated scheduling record remains authoritative.

05Sales and enquiriesWhich enquiry or quote needs the next action?

Connect lead source, stage, age, owner, promised follow-up and outcome so teams can act without presenting uncertain revenue as fact.

Define: Accepted enquiry, qualified opportunity, active quote, response, outcome and conversion.
Show: Source quality, stage ageing, next action, lost reason and records missing ownership.
Review: Response work first; trends only after the stages and population are comparable.
Boundary: Attribution, conversion and forecast rules must be agreed, and individual reporting needs fair context.

06Financial reportingWhich approved financial signal needs investigation?

Present selected revenue, invoice, budget, cost, receivable or job signals from nominated accounting records and reporting periods.

Define: Period, approved source, currency, tax basis, ageing, budget version and variance.
Reconcile: Use control totals and explain differences before a management view is accepted.
Restrict: Role access, drill-through and exports according to the organisation's authority model.
Boundary: A dashboard does not replace authorised statements, accounting controls or financial advice. Cash position depends on complete, current sources.

07Customer statusWhat can an external customer safely see?

Create a deliberately restricted view of approved milestones, status, documents and next updates without exposing internal notes or uncertainty that requires review.

Define: Customer-visible fields, wording, release state and update responsibility.
Show: Approved status, relevant reference, last update and next expected communication.
Test: Shared links, filters, downloads, narrow searches and expired access.
Boundary: Internal staff, cost, risk, source-quality and restricted customer information stays protected.

08ComplianceWhat is due, submitted, reviewed, accepted or overdue?

Organise obligations, evidence, renewals, document references and review states around authorised people and governing registers.

Define: Due, overdue, expiring, submitted, reviewed, returned, accepted and superseded.
Show: Obligation, evidence state, due rule, responsible person and authorised reviewer.
Preserve: Source changes, audit history and approved exports without altering controlled evidence.
Boundary: The dashboard can organise records but cannot determine legal, technical or specialist compliance.

09Fleet and equipmentWhich identified asset is available, assigned, defective or due for service?

Connect stable asset identity with assignment, inspection, defects, servicing, location source and supporting records.

Define: Present, available, assigned, defective, restricted, due and out of service.
Show: Asset identifier, last accepted check, allocation, defect state and service calendar.
Explain: Utilisation population, location source and links to the underlying record.
Boundary: A displayed state does not replace physical inspection, operator checks, maintenance authority or confirmation of readiness.

10MaintenanceWhich preventive or reactive task needs attention?

Show planned work, reactive faults, backlog, downtime, recurring issues, parts context and closeout against a stable asset history.

Define: Requested, triaged, planned, in progress, awaiting parts, completed and verified.
Show: Asset, fault, priority, responsible person, due point and repeat history.
Verify: Completion evidence and authorised return to service stay separate from a closed work order.
Boundary: Parts connections, mobile work orders and downtime measures depend on the confirmed systems and definitions.

11Quality controlWhich finding or corrective action remains unresolved?

Trace inspection, finding, action, completion, verification and closure as separate states, with evidence and recurrence visible.

Define: Observation, nonconformance, action, complete, verified, accepted and closed.
Show: Requirement, evidence link, owner, due point, reviewer and recurrence pattern.
Control: Supplier or customer views and audit exports according to approved access.
Boundary: Recorded completion is not authorised acceptance, and a dashboard cannot prove certification.

12Environmental recordsWhich reading, observation or incident needs review?

Keep provenance, unit, time, location, calibration or validation context and review responsibility beside every displayed signal.

Define: Reading, observation, threshold, incident, task, missing interval and accepted result.
Show: Sensor or author, unit, timestamp, quality state, threshold basis and alert history.
Respond: Assign investigation and closeout without silently interpolating a current condition.
Boundary: Certified or statutory monitoring requires suitable equipment, methods and specialist interpretation beyond a display.

13InventoryWhat can be allocated, ordered or transferred?

Separate stock position from transaction history so teams can see what is physically recorded, reserved, expected or available.

Define: On hand, reserved, available, expected, quarantined, issued and returned.
Show: Movement ledger, job allocation, replenishment point, supplier lead time and count variance.
Review: Slow movement, negative stock, duplicate items and discrepancies against physical counts.
Boundary: Barcode support depends on chosen devices and identifiers; a system quantity does not replace approved stocktake controls.

14Executive viewWhich signal deserves leadership attention and why?

Provide a concise hierarchy of outcomes, leading signals, exceptions and narrative context with a route to definitions and supporting records.

Define: Outcome, leading indicator, threshold, reporting period and definition owner.
Show: Direction, material exceptions, mixed refresh rates, commentary and decision responsibility.
Prepare: Versioned meeting or board output with drill-down to the accepted source.
Boundary: A summary must not remove source warnings, forecast assumptions, changed definitions or unresolved material exceptions.

15WorkforceWhere are coverage, workload or capability constraints?

Review availability, roster, skills or credentials, workload and forward gaps with access appropriate to employment information.

Define: Available, rostered, assigned, capable, qualified, unavailable and unconfirmed.
Show: Coverage, future gaps, relevant dates and workload context rather than isolated utilisation.
Protect: Privacy, correction routes, role access and fair interpretation of individual information.
Boundary: The dashboard must not infer fatigue, performance or suitability from incomplete scheduling signals.

16Construction deliveryWhich programme, RFI, variation or approval is affecting the work?

Link project and site questions to the approved programme, registers, evidence and decision records needed for delivery review.

Define: Baseline, forecast, RFI, approval, variation, subcontractor action and accepted update.
Show: Programme movement, unresolved decisions, responsible parties and relevant site evidence.
Separate: Internal, commercial and controlled customer views with appropriate document references.
Boundary: The view does not replace contract notices, controlled documents, safety systems or professional judgement.

17Traffic managementWhich job, TMP, crew, vehicle or field record needs action?

Bring request, plan, capability, plant, booking, field handover and closeout signals into a coordination view.

Define: Requested, planned, approved, scheduled, ready, dispatched, completed and reviewed.
Show: Job reference, TMP stage, crew or credential dates, plant allocation and readiness exceptions.
Connect: Existing registers and field updates only where identifiers, access and responsibility are confirmed.
Boundary: The dashboard is not TMP approval, a safety control system or proof that a site or equipment is physically ready.

06 · Readiness

Before software is selected

The first improvement may be underneath the dashboard.

A workbook can be a dependable controlled source or a collection of hidden rules and conflicting copies. The decision follows the evidence, not a preference for replacing spreadsheets.

SourceCan each important record be identified and retrieved?
Find the authoritative workbook, system, export, owner and access constraint.
StructureDoes one row represent one stable thing or event?
Separate titles, totals and presentation cells from clean records with durable identifiers.
MeaningWould two people calculate the measure the same way?
Map formulas and business rules, then define population, exclusions, units and time basis.
QualityCan zero, missing, duplicated, delayed and failed be distinguished?
Profile values and exceptions without silently correcting the only copy.
ControlCan the source be reconciled after transformation?
Keep control totals, exception logs, versioned steps and approved samples.
ActionDoes an exception lead to a named person and next step?
Set ownership, review timing, escalation and closeout.

Keep the current source when

The workflow is limited, ownership is clear, copies are controlled and the required review can be supported safely.

Prepare the source when

Identifiers, table structure, definitions, duplicates or formula rules need repair before any dashboard can be trusted.

Connect or replace when

Several users, permissions, refresh needs, audit requirements or repeated handoffs exceed what the controlled source can support.

Choose refresh deliberately

Manual upload, scheduled export and connected refresh each have different failure, support and ownership requirements.

07 · Automation

A refresh or alert is a workflow

Show the run, the failure and the human response.

Automation can validate a source, refresh a view and route an agreed exception. It should never make a failed action look complete or turn a reporting screen into operating authority.

RUN-2409 · synthetic exampleCompleted with one review item

08:30:00Source received
File identity and reporting period accepted.
Accepted
08:30:04Pre-refresh checks
Control total reconciled; two blank owners isolated.
Passed with exceptions
08:30:07Dashboard refreshed
Definition version 2.1 applied to 184 included records.
Published internally
08:30:09Review item routed
Notification sent to the service manager. Acknowledgement still required.
Sent, not actioned

TriggeredThe agreed condition occurred.

AttemptedThe automation began the requested action.

DeliveredThe target system accepted the message or record.

AcknowledgedA named person confirmed receipt.

ActionedThe required human or system response occurred.

ClosedEvidence was reviewed and the exception was resolved.

Failure behaviour

The last good value may remain visible only when its effective time is unmistakable.

Define validation, retry, backoff, alert routing, recovery, run history and the owner who decides whether a failed refresh can be accepted. Device commands, safety controls, legal decisions and financial approvals remain outside ordinary dashboard automation.

08 · Access

Privacy, permissions and exports

A restricted view can still leak through the edges.

Access design covers the screen, drill-through, filters, exports, saved links, notifications, cached files and administration. The source data should be limited to what the decision genuinely requires.

CapabilityStaffManagerCustomerSystem owner

View assigned recordsOwnTeamApproved onlySupport only

Open source detailLimitedRelevantNoneAs authorised

Export informationRestrictedApproved setNoneControlled

Change definitionsNoneRequestNoneImplement approval

Correct a recordRequest or editReviewRequestAudit support

Minimum data

Use only the fields needed for the named decision and audience.

Named identity

Avoid shared accounts and review access when roles change.

Export boundary

Test what leaves the screen through files, email and shared links.

Correction

Name who may correct a value and how dependent views are updated.

Accessible evidence

Provide headings, table relationships, text alternatives, keyboard access and useful print or export forms.

Acceptance

Test narrow filters, unexpected combinations, zero states and restricted records with representative users.

09 · Examples

Interface studies, not client results

Three ways the same discipline changes with the work.

These small studies use invented records. They demonstrate hierarchy, status and traceability without presenting a concept as a deployed customer system.

Study 01 · Daily operations

Exceptions first, normal work still visible.

A coordinator sees unassigned, late and blocked work before the rest of the queue. Each exception carries a reason and owner.

Morning coordinationData through 08:30

JOB-211UnassignedOwner requiredAllocate

JOB-204Waiting on approvalM. RangiReview 10:00

JOB-215ScheduledA. PatelNo action

JOB-219Source delayedSystem ownerCheck feed

Study 02 · Project delivery

A percentage is replaced by the decision behind it.

The project view shows the next milestone, unresolved decision and source date. Progress is never allowed to stand alone.

Next milestone18 SepForecast · not baseline

Decision required: Approve revised access sequence
Owner: Project lead
Due: 16 Sep, 15:00
Evidence: Drawing revision C and site note

Study 03 · Assets and maintenance

Availability, defect and service status remain separate.

An asset may be physically present but unavailable. The view keeps assignment, defect, inspection and maintenance evidence distinct.

UNIT-07AvailableInspection recorded 07:45

UNIT-12AssignedReturn expected 16:00

UNIT-18Defect reviewNot available for allocation

UNIT-24Source delayedLast accepted update yesterday

10 · Validation

Before a view is trusted

Test the interpretation, not just the calculation.

A technically correct chart can still lead people to different conclusions. Acceptance should use normal, threshold, missing-data and contradictory-source cases.

01Reconcile calculations against independent samples.
02Test permissions, filters, exports and role boundaries.
03Test empty, zero, missing, delayed and failed states.
04Test keyboard use, reading order, zoom and text equivalents.
05Record source, metric, platform and action owners.
06Retain the last good value only when its effective date is unmistakable.

11 · Questions

Before a project begins

Practical dashboard questions.

What should we send first?

Send a blank or redacted version of the report, spreadsheet, export or screenshot your team currently uses, plus the decision it is meant to support. Discuss sensitive access before sending live customer, employee, financial or operational data.

Does a dashboard need live data?

No. A scheduled report, approved upload or daily exception queue may be more reliable and easier to own. Live data is appropriate only when the source, latency need, permissions, failure behaviour and support arrangements are suitable.

Can GA Applications work with imperfect data?

Yes, provided limitations remain visible. The first stage may identify missing fields, duplicates, competing definitions or unreliable dates and set out what must change before a measure is trusted.

Which dashboard platform will be used?

The platform follows the sources, users, permissions, refresh method, interaction needs and long-term owner. The appropriate result may use an existing product, a custom web interface, a controlled spreadsheet or a versioned report.

Can different people see different information?

Yes, where the selected platform and identity setup support suitable controls. Role-based views must also consider drill-through, downloads, shared links and narrow filters that could reveal restricted information.

Will a dashboard improve revenue or productivity?

A dashboard cannot guarantee an outcome. A project should name the decision and a reasonable measure of usefulness, such as whether current information is available at review time or whether assigned exceptions are closed with evidence.

Can it control equipment or make compliance decisions?

A reporting dashboard is not operating authority. Safety-critical control, legal compliance, financial approval and other high-consequence decisions need the organisation's authorised people, procedures and specialist engineering or professional review.

Can we begin with one question?

Yes. One recurring decision, a controlled source and a small group of users is often the best way to test definitions, ownership and practical value before expanding the system.

What determines the cost of a dashboard project?

Cost depends on the number and condition of sources, access method, data preparation, definitions, users, permissions, refresh frequency, interaction, exports, testing, hosting and support. A controlled report or exception queue may be more proportionate than a live interactive dashboard. GA Applications should confirm the scope and commercial position in writing before work begins.

How long does a dashboard take to prepare?

Timing depends on source access, data quality, stakeholder availability, security review, decision complexity and acceptance testing. A narrow question using a controlled export can be assessed sooner than a multi-system implementation. The project plan should separate discovery, source preparation, prototype, reconciliation, user testing and release.

Who owns the dashboard after launch?

The organisation should nominate owners for the source, each important definition, platform administration and the business action. GA Applications can provide an agreed support service, but should not become the invisible owner of business meaning, data corrections or management decisions.

What happens after the first release?

Agree monitoring, access reviews, source failures, definition changes, backup or recovery responsibilities, user support and the route for improvements. A regular review should confirm that people still use the view for the intended decision and that new fields or charts have not weakened clarity.

A sensible first step

Bring one decision, not a shopping list of charts.

Tell us what someone needs to decide, when they decide it and where the current information lives. GA Applications can help determine whether the first useful output is a report, queue, alert, dashboard or data-quality plan.

Discuss one dashboard decision hello@gaapplications.com