A field engineer restores a display and marks the ticket resolved. The note says "fixed". The ticket does not record what failed. It does not show which component was checked. It does not confirm whether the fault returned after movement. It provides no evidence.
The equipment may be working. The operating record is not complete.
This walkthrough follows one synthetic display fault from configuration to reporting. The names, sites, assets and tickets are illustrative.
Define the evidence before dispatch. Enforce it at closure. Keep troubleshooting reviewable. Preserve a path from every report number back to the work underneath it.
Completion Is Defined Before Dispatch
The example begins with a governed issue classification: Display fault. The classification gives the team one place to define what must be captured whenever that issue appears.
The issue classification is the shared definition for field evidence and reporting.
The manager defines five fields:
- Observed screen state.
- Diagnostic code.
- Display cable condition.
- Resolution path.
- Confirmation that evidence was captured.
Every field is required. The decision is deliberate.
A diagnostic code without a component condition is difficult to interpret. A repair path without post-repair evidence is difficult to defend. Free text can add context. It cannot replace the minimum operating record.
The same required-field definition drives the field form, closure validation and report catalog.
This is where structured field service ticketing differs from a checklist document. The definition attaches to the issue. It follows the ticket into the technician interface and becomes part of the closure rule. The manager decides which facts are mandatory before any engineer leaves for the site. The system enforces the record they agreed to collect.
That does not remove operator judgement. It makes the judgement legible. The technician still decides what they observed and which repair was performed. The service manager still decides which facts are mandatory.
The result is narrower than a generic form builder and more useful than a free-text ticket with no required fields. The fields exist because an operating decision depends on them.
The Evidence Rule Reaches the Field Visit
Jordan Lee opens FIELD-104, a synthetic ticket for a customer-facing display that drops out after cabinet-door movement. The application remains responsive. The diagnostic log records DISP-204, which points the investigation toward the display signal path.
The mobile work surface shows the site, asset and classification. It also shows the conversation and completion details for the assigned job.
The technician sees the affected asset and required completion details without navigating an administrative ticket screen.
Two facts are already present: the screen blanks intermittently and the diagnostic code is DISP-204. Three required facts are still missing: cable condition, resolution path and evidence confirmation.
The interface says so at the point of work.
Resolved work cannot be closed while required evidence is missing.
This distinction matters. Resolved describes the service state. Complete describes the operating record. Treating them as the same thing is how teams end up with closed tickets that cannot support a repeat visit, a manager review or a trend report.
The engineer powers down the unit and inspects the display path. They record a loose connector. The selected resolution is Reseated display cable. Three controlled door-movement cycles pass without another DISP-204 event.
The technician records those facts in the required fields and drafts a plain-language update. The attachment control provides direct access to a photo, video or existing device file.
Structured values, narrative evidence and media capture stay in the same field workflow.
This is not a choice between forms and conversation. The structured fields answer the questions that must be comparable across tickets. The note explains what happened on this visit. Photos and video provide supporting evidence where the physical condition matters.
Once the required values autosave, the close action becomes available.
The closure control stays locked until the required operating record is complete.
The enforcement happens while the engineer still has access to the equipment. A reminder sent after the visit has already missed the useful moment.
AI Guides the Next Check Without Taking Control
The ticket also contains an AI troubleshooting recommendation. It proposes:
- Power down the kiosk.
- Inspect and reseat the display cable.
- Restore power.
- Complete three controlled door-movement cycles.
The recommendation includes a confidence score and its reasoning. Audio continues while video disappears. The fault repeats with door movement. The diagnostic code points to the display signal path, not a full power loss.
AI proposes a bounded next step. The operator reviews the evidence and decides whether to use it.
The recommendation does not silently change the ticket or declare the root cause. A proposed task remains visible for review. This control boundary makes the suggestion useful on real work.
The model narrows the search. The person who can inspect the equipment still decides.
Field Evidence Feeds a Governed Operational Report
After several display tickets, the service manager wants to know which observed symptoms coincide with which cable conditions.
The report library contains a saved definition named Display fault patterns by observed state and cable condition. It sits beside standard operational reports. It can be rerun without rebuilding the question in a spreadsheet.
A saved report keeps its measure, dimensions, time window, filters, visualisation and owner.
The reporting engine does not expose arbitrary SQL. It provides an allow-listed set of measures and dimensions. Standard dimensions appear alongside governed Issue Data Fields. Those dimensions include customer, site, asset, status, priority and engineer.
Custom workflow facts become report dimensions without becoming an unrestricted query surface.
The names remain specific: Display fault · Observed screen state and Display fault · Display cable condition. A generic label such as "Condition" would become ambiguous as soon as another issue type defined a field with the same name.
The saved report records stable field identifiers rather than copying display labels into query logic. The backend resolves those identifiers against the governed schema and runs a parameterised query. Changes to the visible label do not silently change what the report means.
The synthetic report covers eight distinct tickets. Intermittent blanking with a loose connector appears three times. Flickering with a secure connector appears twice. Blank displays with damaged cables and colour distortion with secure connectors each appear once.
One ticket has no field values. The report does not discard it. It appears as Not provided.
The report counts distinct tickets and keeps missing evidence visible instead of quietly shrinking the denominator.
That treatment matters. If incomplete records disappear from the report, the operation can look cleaner as evidence quality gets worse. Keeping missing values visible turns data completeness into something managers can monitor.
The result also avoids multiplying ticket counts through related tags, assets or history records. The unit being counted is the distinct ticket, not every joined row that happens to describe it.
Every Aggregate Stays Answerable to Its Ticket Records
An aggregate can reveal a pattern. It cannot show whether the pattern is trustworthy on its own.
The manager opens the Intermittent blanking · Loose connector row. The drill-down shows the three contributing tickets. For each, it includes the issue classification, governed field values and status. It also includes the assigned engineer, resolver and other ticket evidence.
Each aggregate row keeps a path to the ticket records underneath it.
This is the useful boundary for a custom reporting engine. Managers can ask operational questions that were not anticipated in a fixed dashboard. The answer stays governed by known measures, named dimensions and explicit filters. The source records stay readable.
Field evidence should be defined before dispatch. It should be enforced before closure. It should be reusable after the visit. Each step feeds the next.
The required fields defined up front become the closure rule in the field. The completed evidence becomes the basis for a reviewable AI recommendation. The same governed values become the report dimensions and drill-down paths. A field ticket is complete when the equipment state and the evidence record agree. That is what turns one repair into operational memory for the next visit.