Services and Assets

A service record names the IT service, its criticality, current state and owner. An asset record identifies store equipment by tag, serial number and location and links it to a service. Incidents use both links. The service desk can therefore distinguish a fault in one register from a broader issue with the checkout service, while still keeping the case anchored to the actual equipment selected at intake.

Changes, problems and service requests also link to services. The service record connects those forms of work without pretending they have the same lifecycle. A planned change can affect a service while a separate incident remains open; a service request may be fulfilled for that service without resolving an existing problem. Each record keeps its own status and decision owner.

• Service reference. Maintain a recognizable service name, criticality, owner and current state for the desk to select.
• Asset reference. Keep each asset’s tag, serial number, location, state and linked service clear.
• Operational use. Confirm the service and asset links during incident acknowledgment and use the service link when reviewing requests or changes.

Decide how granular a service should be. One checkout service for all stores might be simple, but the person triaging a store issue must still be able to select a meaningful asset. Agree naming for asset tags and locations so two technicians identify the same register in the same way. The asset’s state can be in stock, assigned, under maintenance or retired; the service has its own active, maintenance or retired state.

Choose who maintains these reference records and how the owner is kept current when responsibilities change. The incident triage action reads the linked service and asset and validates the lifecycle state before acknowledging and assigning the case. That check only helps when reference records reflect reality. Review stale locations, retired equipment and inactive services before teams rely on these links in daily work.

Select a store register with an assigned asset state and a linked active checkout service. Create an incident for a failed card reader and link those records. Ask a technician to open the incident, confirm that the location and equipment match the store report, and acknowledge it. Now rehearse the same action with an asset selected from the wrong store. The operator should correct the link before assigning work.

Then inspect a service request and a planned change using that service. Their service links help the team see related work, but the approver must still review each request or change on its own merits. A service owner can clarify the impact of work; the service’s criticality is context for the decision, not an automatic approval.

• Assets in Service — Assigned equipment with its location and linked service.
• Open Store Incidents — Current cases that let the technician inspect the selected service and asset.

Follow these references through incident response and approved change.