Body
Initiation
Every customer request must be in the form of a service request ticket in TeamDynamix before continuing through the process. Customers may make requests through any of several channels:
- Phone: Service Desk should direct customer to a catalog entry, if one exists, or assist user with completing the form
- Service Catalog: customer submits via TDX form
- Email: customer sends email to an EGA configured to create tickets in TDX
If a customer did not enter the request themselves, a FCS service delivery analyst must enter the ticket.
Evaluation
Edit the request to set Responsibility, Status, Impact/Urgency, and Service. If the service request is misclassified as an incident, also update the Classification & Form.
All these elements are required to ensure the correct service level targets for time to respond and time to resolve are applied.
Identify Type of Request
If the request is an automated request or a regularly scheduled request, no analyst interaction is required for evaluation. You can proceed directly to fulfillment. If the request is a defined standard request that is manually fulfilled, attach the standard operating procedure (SOP) outlining the fulfillment procedure. Everything else represents a non-standard request, commonly referred to as "General Support."
Authorization
For both standard and non-standard requests ensure that the customer is eligible to make the request and that they have gathered the appropriate approvals. If they have not, you can proceed directly to closure.
Prioritization
Remember that the request's service activity value determines the service level target for time to respond and time to resolve. Use these targeted times to respond and resolve to determine the next actionable incident. Make sure that the request's urgency value represents the customer's communicated urgency; if it is urgent to them, set the value to High and add "Urgent: " to the title of the request ticket. This can help with prioritization when a number of requests share similar targets.
Tickets that have already breached SLA should be worked according to the group manager's strategy for resolving incident backlog.
Hierarchical Escalation
Hierarchical escalation, meaning to a manager or director, is not typically used for a routine service request. Most often this is used in cases of concern around policy or safety, or can be requested by the customer. ("I would like to speak with a manager.")
Fulfillment
If manual, follow the standard operating procedure for fulfilling this request. All defined standard requests in TeamDynamix should have a KB article outlining the procedure, or linking to external documentation outlining the procedure. These documents should be followed on all interactions; if the documentation or procedure are insufficient, escalate the request and indicate the gap in knowledge so the service delivery team can improve it. Leaving feedback directly on the KB Article is recommended so that the owning team will see this on the documentation days and can improve their articles with your input.
Document everything. The service request ticket is the only reliable record for the support interaction. As such, all fulfillment steps performed, conversation with the customer, information gathered must be recorded in the service request.
Incomplete Request Information
Use the ticket to communicate with the customer. Be sure to use a status of Waiting for Customer and set a "Goes Off Hold" date to make another attempt if the customer has not yet responded.
Scheduled Request
If the customer indicated a date in the future to fulfill the request, be sure to use a status of Scheduled and set a "Goes Off Hold" date to the date you will resume fulfillment.
Functional Escalation
Functional escalation, meaning to a second or third level support group, may be required based on existing knowledge. Unless specifically instructed by the service delivery manager, do not escalate a request until you have followed the existing procedure and obtained all the relevant information as indicated by the service delivery team.
Be sure to use a status of Reassigned when escalating a request to another group.
Note: If sufficient documentation does not exist for fulfillment, make a comment on the ticket before reassigning it. ("No KB available to fulfill this request.")
Complete the Request
A service request is fulfilled once the service delivery analyst has completed action or provided the information to satisfy the customer's request.
Note: FCS does not practice "confirmation of fulfillment." We are not adequately resourced to provide quality support and manually close each individual service request after ensuring customer satisfaction.
Verify and update the request's metadata (urgency, service, service offering) so that metrics accurately reflect the support work performed. Tickets are regularly audited for accuracy and completeness.
Fulfill the request with notification to the user by setting the status to Resolved and providing comments regarding the fulfillment. Use an appropriate response template anytime one is available; this helps provide a consistent voice.
If the customer is unsatisfied by the fulfillment and emails back within 14 days, the service request will reopen. If the customer does not respond within 14 days, TDX will automatically mark the request as closed.
Closure
After a request has been fulfilled, there may still be action required, typically in the form of outputs to other service management practices.
Missing Knowledge
No KB article existed: If you received a request where the previous service delivery analyst indicated insufficient knowledge was available, take an action to create the knowledge. You could do this via your team's task tracking method, a service request to yourself to create a KB article, or simply create the article now.
Existing KB article was not attached: If you received an request where the previous service delivery analyst did not correctly identify existing knowledge such as an SOP document, notify the SDA of the available TDX KB article for future use.