A weekly maintenance review should not begin with an operator rebuilding last week's spreadsheet. The question is already known: where is planned work waiting, in progress, on hold, or complete? The report definition should be known too.
Latch reporting starts with built-in reports for common operational questions. The builder then lets an operator set the measure, choose up to two grouping dimensions, narrow the scope, and save a personal definition for reuse.
This walkthrough builds one report for a finance-hardware service operation. The team runs ATM replenishment, CDM inspections, and POS-printer maintenance across several cities. It needs a repeatable view of that planned work by city and current status.
Start with the operational question
The question decides the setup:
- Measure the number of cases created in the review window.
- Group first by city, then by status.
- Limit the window to the last 90 days.
- Include cases tagged for cash and consumables replenishment or scheduled preventive maintenance.
- Present the result as a bar chart with the underlying table visible.
Each choice is explicit in the builder. There is no hidden spreadsheet cell or undocumented pivot setting.
The builder shows the measure, 90-day window, city and status grouping, and the two selected planned-work tags.
The measure can change when the question changes. Ticket count shows demand. Open ticket count focuses on work that still needs attention. Resolved ticket count supports a completion review. SLA breach count and average resolution time show whether the operation is meeting its service commitments.
Grouping works the same way. A field-service lead might group by engineer and asset type. A regional lead might choose city and status. An asset manager might compare asset type with issue type. Latch permits two grouping dimensions so the result stays readable.
Filters keep the report tied to the work
The report can narrow by customer, site, asset, or tag. Tag filters support direct, inherited, or effective tags and can match any or all selected values.
For this planned-work report, direct case tags separate replenishment from preventive maintenance. The two tags act as the scope. Incident repairs stay out of the result even when they involve the same ATM, CDM, POS terminal, or printer.
That produces a view the weekly review can use immediately.
The result shows fifteen planned-work cases across Nairobi, Copenhagen, Makati, Sao Paulo, Accra, Dubai, and Toronto.
The chart gives the pattern. The table gives the exact buckets. Nairobi has both closed and assigned work. Toronto has a visit on hold. Those are places to inspect the underlying cases, not conclusions the chart makes on its own.
Save a personal definition for the next review
Once the setup answers the question, the operator saves it under a clear name such as "Scheduled maintenance and replenishment by city." Latch assigns the report a stable URL for that operator.
Reopening the URL reruns the same definition against current case data. The setup stays consistent while the numbers change as cases move through the workflow.
This has two important limits. A saved report is not an immutable historical snapshot. It is also owner-scoped today, so the URL does not automatically grant another operator access. If the team needs a point-in-time record, it should export or record the result through its established review process.
Data quality remains part of the result. A report cannot correct an unlinked asset, missing site, absent engineer, or unclassified case. Those gaps should remain visible because they affect the operating decision.
Working-hours-aware measures can use SLA schedules that reflect the hours a team actually operates. The choice of measures should follow the principles in queue health measures beyond first response. The wider move from stored case notes to operational action is covered in moving from a case record to a system of action.
For the full release and the finance-hardware field-service example, see the reporting release overview.
The operating rule is straightforward. Define the question once. Keep the filters and groupings visible. Save the setup under a name the operator will recognise next week.