- update the asset mgmt and configuration mgmt systems
- ensure billing record is correct (including expedited service parameters)
- verify required collected IMACD information
- return necessary material (properly identified) to the depot for further disposition
- close the request
helpdesk responsibilities to gather and document incident content goes a long way to getting the right resource dispatched and the ticket closed in the SLA window. a helpdesk knowledgeable about the workgroups, business processes, and available services drops a high quality ticket in the service request queue.
incomplete data normally causes the resolver group to bounce the ticket back to the helpdesk for more information. the SLA clock should be reset and the helpdesk should communicate the new deadlines to the end user.
- based on service delivery documentation, identify all associated resolver groups and align their resources
- confirm the service delivery expectations and alignment to the SLA
- confirm availability of resources and coordinate logistics
- establish and communicate the schedule to the IMACD key contacts and the end user. adjust to taste maintaining the service delivery window.
- if forecasted delivery execution misses the SLA window, escalate to the outsourcer’s FOM.
the outsourcer should not direct the resolver group to perform any action that voids a warranty. ideally, the resolver group is an authorized warranty provider and warranty process steps should turn off the SLA stopwatch.
the outsourcer needs to have a means of tracking the warranty status and authorization requirements on each device in the inventory. its possible that the outsourcer does not meet the OEM’s requirements allowing it to designate the resolver group as a 3rd party warranty service provider. this may mean that the swap inventory strategy needs to be adjusted.
end users (knowingly and unknowingly) register tickets on unsupported devices expecting issue resolution within the SLA. the technician may actually arrive on-site before discovering that the device is not field replaceable. the resolver organization has chewed up money to this point and should be able to invoice the outsourcer. communicating next steps is the trickier question.
the ourtsourcer’s field operations manager should now take the lead on interacting with the end-user to determine next steps. the FOM should step in between the end user and the resolver group and clearly set the end user’s expectations as to how the issue can be resolved.
waiting for deskside support is not a favorite activity for end-users. they’re annoyed because something is broken, their sponsors are annoyed because the normal business process flow is inevitably disrupted.
the technician is also under pressure to resolve the ticket. they overcome physical security obstacles, dragging a tote (hopefully with some ergonomic facilitation) and need to synchronize with the end-user. this dance began soon after the ticket was opened with the initial attempt to make contact. and this is where the notorious breach code comes in.
the tech calls the end user within the first 60 minutes of ticket registration attempting to coordinate the fix.
- if the end-user is not available, voicemail is left requesting a direct to the helpdesk
- a second attempt is made at roughly 50% of the SLA performance period. if the end-user is still not available, an additional voicemail is left asking that the end-user re-schedule the ticket. the ticket is left in a pending state with a breach code of end-user unavailable.
asset mgmt is the core of refresh services provided by the resolver group and critical when configuration mgmt concepts are extended to workgroups. send the technicians out with a magnifying glass and ask that they document the serial number on every asset involved in the trouble ticket. the resolver group should be getting paid for asset and configuration management, you might as well grab the data when someone is touching the hardware rather than define and execute independent sampling processes.
helpdesk service levels are normally conceptualized as applying to a single trouble ticket. the supporting processes are usually well defined and the associated roles are assigned and owned by the outsourcer, the resolver group, or another supplier.
in reality, delivery capacity exerts a major influence on the ability of the resolver group to execute a service request. service level targets should be closely linked to ticket volumes and types.
when the resolver group is being paid by the “effort minute”, the outsourcer needs to tightly control the virtual punch card system. Normally, this means that the ticketing system is counting the minutes that the ticket is in “active” status.
The resolver group should not be charging the outsourcer for technician downtime when automated processes are running. On the other hand, the resolver group should be tracking setup time require to prepare for the onsite activity. A workflow approach to documenting process execution is less error prone and easier for supervisors to audit.
trouble ticket - either an IMACD request or an incident resolution request
resolution time - the cumulative time that the trouble ticket is in “active” status.
active status - the operational state in which the resolver group is able to progress work on a trouble ticket using the processes described in the Statement of Work.