Service request fulfillment
Service request fulfillment process
The information needed to capture and resolve service requests varies. But, you can standardize the process for fulfilling these requests.
The IT Service Desk template associates certain requests with a service request fulfillment workflow. We set up the workflow to complement the following service request fulfillment process. Use it as a jumping off point for your service desk.
The service request fulfillment process, in brief:
- A customer requests help from your service catalog or via email.
- The service desk assesses the request alongside pre-defined approval and qualification processes. If needed, they send the request for financial or business approval.
- A service desk agent works to fulfill the service request, or forwards the request to someone who can.
- After resolving the request, the service desk closes the ticket. The agent consults the customer to make sure they are satisfied.
Jira Service Desk's default service request workflow
Using request types, you can associate service requests with an issue type called Service request. This puts the issue into the recommended service request fulfillment workflow.
This workflow follows the basic process above. You can customize it to adapt to the needs of your business.
We include two types of service requests in the template:
- Service requests have no approval step. We recommend using them for pre-approved service requests.
- Service requests with approvals include an approval step. We recommend using these for requests that need either business or financial approval.
Customize your service request workflows
- From your service desk project, select Project settings ( ) > Workflows.
- Select the edit icon (a pencil) next to either:
- the entry titled Service Request Fulfilment workflow for Jira Service Desk
- the entry titled Service Request Fulfilment with Approvals workflow for Jira Service Desk
- Use the workflow editor to add or remove steps and transitions.
Auto-close service requests after resolving them
The IT Service Desk template includes an extra SLA and automation rule. Together, these automatically close service requests three business days after an agent resolves them. This is useful for teams that want to wait before closing requests in case customers have extra feedback.
The SLA called Time to close after resolution starts a clock when the resolution field of a service request is set. This clock stops if the an agent clears the resolution field or if the request transitions to Closed.
You can view, edit, or remove this SLA:
From your service desk project, select Project settings ( ) > SLAs.
We include an automation rule called Auto-close after being resolved for 3 business days. This rule transitions a service request from Resolved to Closed when the above SLA breaches.
You can disable or fine-tune the rule. To view or edit this rule:
From your service desk project, select Project settings ( ) > Automation.
Tips for creating service request forms on your portal
- Begin with the most common requests. Choose ones that are simple and easy to fulfill. This delivers immediate value to customers. It allows the service desk team to learn as they build out future phases of the service catalog.
- Document all the requirements for a service request before adding it to the catalog. These include question data, the approval process, fulfillment procedures, the fulfillment team, process owners, SLAs, reports, and so on. This allows the IT team to better manage the request type over time.
- Capture the data needed to start fulfilling the request. But, don't overload the customer with too many questions.
- Work with stakeholders to standardize the approval process, where possible. For example, pre-approve all requests for new monitors. Or, assign software approvals to the customer's manager.
- Document any knowledge base information that might allow customers to service their own request. Record this in a linked Confluence space. If you do, customers can view articles while they search your portal. Read more about creating a knowledge base.
- Review your team's performance in fulfilling requests. Adjust your SLAs, requirements, and training to improve customer satisfaction.
- Create reports to help manage the lifecycle of a service request offering. These trends can uncover forms that are no longer needed, too complex, or insufficient.
Default form fields for service requests
Jira Service Desk allows you to customize the fields of information collected from customers. Additionally, you can customize the fields of information used by your agents. Jira Service Desk does this through issue type fields and screens. Fields help agents fulfill the request, discuss with vendors, and categorize requests.
By default, we include the following fields in your agents' view of a service request:
|Summary||A short description of the request.|
|Reporter||The person who submitted the request.|
|Component/s||Segments of your IT infrastructure that relate to the request. For example, "Billing services" or "VPN server". These are used for labeling, categorization, and reporting.|
|Attachment||Files or images added to the request.|
|Description||A long, detailed description of the request.|
|Linked Issues||A list of other requests that affect or are effected by the request. If your business uses other Atlassian products, this list may include linked development issues.|
|Assignee||The service desk agent assigned to fulfill the request.|
|Priority||The importance of the request's resolution to the service desk. Usually in regards to your business needs and goals. Sometimes calculated by impact and urgency.|
|Labels||A list of additional custom labels used for categorizing or querying records.|
|Request participants||A list of extra customers or vendors who take part in resolving the request.|
|Approvers||A list of business or financial contacts responsible for approving the service request.|
|Organizations||A list of customer or vendor groups interested in the request's resolution.|
Extra form fields recommended by ITIL
ITIL recommends a few more fields for their in-depth processes. The IT Service Desk template doesn't include these by default. This is because IT teams who use Jira Service Desk don't often use these fields. If needed, you can include these fields or add custom fields. Find out more about fields in Jira.
ITIL also recommends including the following fields:
|Impact||The effect of the service request, usually in regards to service level agreements.|
|Urgency||The time available before the business feels the service request's impact.|
|Pending reason||A short description or code that indicates why the service request is not progressing.|
|Product categorization||A category of IT asset or system that the request effects.|
|Operational categorization||A category of action or function required to fulfill the request.|