The SLA clock starts when the ticket opens, not when someone notices it. An IT helpdesk running on email and verbal requests has no reliable timestamp for when a request was made, no structured classification of what kind of request it is, and no mechanism for flagging which tickets are approaching their service level deadline before they breach it. The breach is discovered after the fact, which makes the SLA metric a historical record of failures rather than a management tool for preventing them.
The SLA Structure
Sla Due Date is the field that creates an actionable queue rather than a chronological pile. Sort open cases by SLA due date and you have a priority list: the cases closest to breach go to the top, regardless of when they were submitted. Without this field, ticket prioritization is based on whoever shouts loudest or whoever the helpdesk remembers last — neither of which correlates well with contractual service commitments.
Type of case classifies the request. Hardware failure, software installation, access request, network connectivity, meeting room setup — each type has a different resolution path, different skill requirements, and often a different SLA threshold. An access request that should be resolved in four business hours sitting unresolved in a queue with hardware failures that allow 24 hours creates a false sense of capacity that isn't visible until the SLA breach report.
Case Details is the free-text field where the request specifics live — the exact error message, the specific software version, the access level being requested. Without sufficient detail in the original ticket, the resolution requires a callback to clarify requirements, which adds time to the resolution cycle and creates an undocumented gap between ticket open and active work start.
Multi-Factory Context
Factory and Factory Involved with Department are the location and scope fields for a manufacturing environment with multiple sites. A case logged by a user at Factory A that involves systems at Factory B requires coordination between sites. The Factory Involved field captures that cross-site dependency so the resolution path routes correctly rather than staying in the submitting factory's queue while the actual affected system is at a different location.
User Name with Department gives the requestor's organisational context. An access request from Finance has different approval routing than an access request from Operations. A printer setup in the Director's suite has a different urgency classification than the same setup in a general office area. The department field is the context that shapes how the case is handled without requiring manual decision-making on every ticket.
Subtask Architecture
Have subtask? and Subtask Detail handle the case that can't be resolved in a single action. A server migration ticket has a subtask for data backup, a subtask for configuration backup, a subtask for the migration window, and a subtask for user communication. Without a structured way to log those dependencies in the ticket record, the migration is tracked as a single open ticket that's "in progress" for two weeks with no visibility into which components are complete and which are blocking resolution.
Meeting room and When? handle the meeting room booking component of the helpdesk that IT support teams in multi-site manufacturing often absorb. A confirmed meeting room booking is a service commitment with an exact time constraint — it's a different category than most IT tickets and benefits from being logged in the same system that manages the SLA calendar.
Succeed? closes each case with a resolution status flag — resolved successfully or not, without ambiguity. A case closed with Succeed? = No is an escalation candidate or a chronic issue that needs a different approach, visible only if the resolution status is a structured field rather than a text comment buried in the case notes.