The Service Requests table holds all customer service requests. A service request (SR) is created when an internal customer needs a new service, a standard preapproved change to an existing service, a password reset, or some other kind of assistance or information.  Service requests are also used to request the purchase of equipment, supplies, or new services or software.

When the user needs to report an interruption in service or a problem with an existing service, an incident should be created instead. separates service requests from incidents because these two kinds of request have different workflows and resolution criteria. An incident may often require the generation of a Problem and a Change Request, while Service Requests will generally be self-sufficient and straightforward to handle.

The easy way to distinguish Service Requests from Incidents is to recognize that Service Requests are the kinds of things you would select from a service catalog, such as application assistance, password resets, new employee setup, documentation, or copying services.

If a user creates a Service Request when it should have been an Incident, the technician may click the Save Changes and Copy to Incident button on the Related Records tab of the service request form to easily convert that Service Request into an Incident and have all the fields mapped appropriately.

A user creating a service request chooses the business service from a drop-down, and then sees all the active services for that business service in a second drop-down list. The default business services for service requests can be seen in the business services table, or by creating an SR record and opening the drop-down list.

Creating Service Requests

Service Requests (SRs) may be created by telephone support staff or technicians on behalf of customers or by customers directly through the web interface or by inbound email.

End User Record Submission

A customer can submit a service request from the default end user interface home page by:

When a customer submits a Service Request using any of these methods, the submitter information fields automatically populate based on the details in the user's Person record. In the default setup, a request cannot be submitted on behalf of a user who has no user record in the system. This may be changed by modifying the linked fields from the User table to enable "non-source" values.

Requests involving Purchase

When users submit a request that involves a purchase, they see the Items Requested for Purchase section at the top of the Items / Costs / Time tab. To choose the items for the purchase, click the Select Item link to bring up a new item requested form.

To complete the purchase request:

  1. Select the Type and Subtype. Only those values made accessible in the service record will be selectable, and then look up the available models from the Catalog, shown as the drop-down called Item Name/Number, and select one. After selecting the item, the latest price and an estimated cost are displayed.  
  2. Save the Item Requested form and return to the Service Request. Users can create additional request items if the purchase involves more than one item; for instance, for a new computer, the user could create items for the main processor, the mouse, and the monitor to be ordered.  Once the items are created, they are shown in the Service Request screen.
  3. Click Save to save the Service Request form, which will send an email acknowledging that the request was received.

Actions on Submission

The system runs the following actions when a new Service Request is submitted.

Automatic Assignment and setting of Priority and SLA Dates.

When a new request is saved, it is automatically assigned to a team based on the values in three fields pulled from other tables. The related service has a Responsible Team associated with it and a field called Give Service Team Priority over CI Team that has Yes/No values. If a Configuration Item was identified for the request, then there is also a CI Responsible Team field that will be populated in the SR.

The current assignment logic is: if the Service Request involves a specific configuration item (CI), then the request is assigned to the responsible team for that CI, unless the Give Service Team Priority over CI Team field is set to Yes. In this case, or if no CI is defined, then it is assigned to the Responsible Team for the Service. If there is no Responsible Team for the Service, then it is assigned to the 1st Level Support Team.

Naturally, this logic may easily be changed to suit your organization. You can simply set a default value such as the 1st Level Support Team or you may choose some other logic to use based on different fields. If technicians need to reassign the Service Request to a different team or person, they simply change the Assigned Team and/or Assigned Person field and the system will email the new assignee notifying them of the reassignment.

In addition, the priority is set based on the Impact and Urgency, and the correct SLA is applied, if SLA's are in use, based on the submitter, the service, and the configuration item, if any.  If the request does not require approval first, then the SLA target dates are set based on the SLA and the priority.

Notifications 

When a service request is submitted, if it does not require approval first, a pop-up appears to the submitter stating the SLA target date. For a new request that is not Closed, which can happen when technicians take a phone call, an acknowledgement email is sent to the submitter. If the selected service had a value of Yes in the field "CC Manager", then the submitter's manager is also emailed.

If the assigned person field has a value, that person is emailed, otherwise the assigned team is emailed about the new request.  If the request requires approval, they will launch the approval process;  otherwise, they will work on completing the request.

Following Progress on Their Requests

Customers may return to the portal to check on the status of their service requests by clicking View My Service Requests on the home page. 

They will see all of their Service Requests displayed, and can click the Summary link to view and add more information.

Technician Record Submission

If technicians create the SR, they may choose an assigned team and assigned person from the drop-down fields and the changes will not be overwritten: the rule only assigns the record if the Assigned Team field is empty when the record is saved.

New SRs are created in a Status of Open by default. During creation, a technician may change the Status to In Progress, if they wish to indicate they have already started working on it, or Closed if they were able to resolve the issue immediately and want to capture the request for reporting purposes.

Automatic Email Sent if Request is Closed during Technician Submission

If a Support Staff technician creates a record in a status of Closed, an email is sent to the customer telling them how to reopen the Service Request. This email is sent by a workflow action and is displayed as a checkbox that can be deselected by technician users. This option is set in the table's Workflow, and can be modified. 

The Service Request Layout

This section describes the default layout screens and fields for service requests.

Common Area

The common area, shown above all tabs of a service request record, contains the ID, Summary, Status, Assigned Team, Assigned Person, and SLA Due Date for the service request.

Common area layout

Details Tab

The Details tab contains information about the user who submitted the request, the service being requested, the request's importance, and notes about the request. The Submitter fields default to the user who created the service request, but can be updated by a technician if the request was created on behalf of another user.  Upon submission, the user must choose a Business Service. Based on the Business Service chosen, a list of relevant Services will be available for selection. Alternatively, if the submitter requested the service through the service catalog, these fields will be prepopulated for them.

Impact and Urgency are also required. Upon saving the record, a Priority will be chosen automatically based on the Impact and Urgency. If the Impact or Urgency is changed, the button Set Priority can be used to refresh the Priority field based on the new values. To manually override the priority, Override Priority can be set to Yes. The submitter can enter more details about the request in the Description field. After submitting a service request, the submitter can enter additional notes in the Additional Information field. Any relevant files can be added to the Attached File field.

If the service is marked as billable and the Service Cost function is turned on, there are two additional required fields shown above Description:

The Cost Center field is required and autopopulates the Cost Center Code field

The list of cost centers available is filtered to those where the Department matches the Submitter's Department.  See Cost Centers for more details on this background table.

Approvals Tab

If the service requires approvals, fields on this tab will allow creation, editing, and launching of Approval records. Depending on the approval method of the service, either Predefined Workflow Only, Manually Created in Request Only, or Both Options Available, different fields will be available.

A workflow will be selected automatically if the service has a Default Workflow, but may be changed manually by privileged users. The approvals in the workflow are generated for this service request by clicking Generate Approvals. If additional approvals need to be added, the checkbox Create Approvals in the Manual Approval Creation section can be selected, which will make new fields appear. Additional details on approvals can be found in the Managing Approvals section below.

Tasks Tab

If the service has a task workflow, it can be launched and managed on this tab. For instance, the "Computer hardware installation tasks" workflow contains the following tasks by default: Unpack and test the hardware to ensure it is functional; Install the hardware in its new location and connect to company network; Install any necessary software and test; Update the Configuration Item record with changes. 


Based on the Service selected and the Assigned Team for the Tasks, each Task generated in this tab may also be tied to an OLA Target, with a Resolution Time and Resolution Time warning threshold, allowing progress to be tracked against them as needed and notifying the appropriate parties - i.e. Assigned Team Manager - when those thresholds are breached. For more information on OLA Targets, see Service Level Management.

Items / Costs / Time Tab

If the service for the request is marked as being billable, for instance a Desktop Phone or Headset Purchase, cost information appears on this tab. In addition, if the service involves a purchase, the items that the user has requested will be displayed in the Items Requested for Purchase section. 


The Items requested for Purchase table shows any items being purchased for this service request. Below the table is an Estimated Cost of Order based on the Estimated Cost of the Item Requested, a Total Cost of Order based on the Actual Price per Unit of the Item Requested, a count of the Number of Items Requested, and a count of the Number of Incomplete Items Requested based on the Items Requested that are not yet installed. 

In the Service Cost Information, the Cost Model field is set automatically when new service requests are created to match the Cost Model field in the Service record. The options are Fixed for the Service, Based on Items Purchased, Based on Task Costs, and Based on Time Spent. Depending on the selected option, different fields are visible in the service request. For instance, if the Cost Model is 'Fixed for the Service,' a field for Fixed Cost appears.

If your company tracks the time spent on requests, the fields for entering time spent appear near the bottom of this tab. Users may put in an amount of time and a brief description, and click the Add Time button to generate a time entry linked to the service request.

Work Status Tab and SLA fields

The Work Status tab displays all of the information from the SLA defined for the Service Request based on the user's SLA group. For more information on this, see Service Level Management. The SLA Title is displayed, along with the support hours for the SLA, the SLA Target Response Time, Actual Response Time, SLA Target Resolution Time, SLA Warning Date, and whether or not the SLAs for Response and Resolution were met. If the SLA was breached, a Reason for SLA Breach field becomes visible where the breach can be explained. There are also Staff Working Notes with time stamps, and a Resolution field that can pull from the Known Error database if needed along with an Attached Files field.

Note that these fields will be hidden if you turn off the SLA function in the ITIL Functions table.  Also, the SLA targets will be blank for service requests that require approval until the request is approved, at which time the target due dates are calculated.

This tab also includes the main fields used to communicate the resolution to the customer and to communicate with other staff members. The Staff Only Working Notes field is only visible to members of the Base Service Desk group, so customers cannot see the notes in that field.

The Resolution field is used to put in the final resolution that is sent to the customer when the request is set to Closed.  There are several other fields that appear below only once the status is set to Closed: the Closure Category, Reason for SLA Breach, if relevant, and the Standard Solution and Review for Knowledgebase fields.

Related Records Tab

If the service request was created from within an incident, that incident is automatically displayed in the Source Incident section.  

If the service request should be converted into an incident or change request, buttons here can be used to map information from the service request into the new incident or change request. Clicking Save Changes and Copy to Incident, for example, opens a new incident record with the Summary, Assigned Team, Assigned Person, Submitter Information, Business Service, Description, Configuration Item, Additional Information, Staff Only Notes, and Resolution prepopulated based on the service request. In addition, the incident will automatically show the originating service request in the Source SR fields. Once the new incident is saved, the service request will be automatically updated to show the related incident information.

The same thing applies to converting a service request to a change request.  The source SR is shown in the change request and the change request information is linked back to the service request.

If the service request is related to a release, the release can be selected in the Related Release section.

All Service Requests submitted by this user shows any other service requests created by the same Submitter, allowing technicians to compare the current request to previous ones for the same user. At the bottom of this tab, any configuration items assigned to the submitter are also listed in a table.

Processing of Records

This section describes the most common actions a technician will perform when working on a service request. Throughout the process, the technician can enter working notes in the Staff Only Notes field, which is an append-only field not visible to the customer.

Requesting Information from the Submitter

If a technician working on a Service Request needs more information from the customer in order to take further action, set the status to Pending Customer. A workflow action will automatically send an email to the customer requesting further information. The email includes the contents of the Additional Information field on the Details tab, an append-only field used for communicating with the customer. The email includes a link for the customer to open the Service Request directly.

Changing the Assigned Team or Person

Technicians may reassign a request to a different team or a different person.  Any time either field is changed, an automatic notification is sent. It is sent to the new assigned person, if there is one and it is not the person who just set it, or to the new team.

Managing Approvals

For service requests that need to be approved, approvals are managed in the Approvals tab.  All of the approval fields are dependent on the Service Approval Required field having a Yes value.  If it has a No value, then no approvals are needed and this tab can be skipped.

The methods available for approval generation for a service request depend on the service. As described in the Service Catalog and Portfolio Services, there are three options for approval generation methods for a service:

  1.  Using a predefined workflow: If a service's Approval Generation Method is Predefined Workflow Only, then the default approval workflow will be shown, with the button to Generate Approval(s).
  2.  Manually creating approvals within the service request: If Manually Created in Request Only is selected as the Approval Generation Method, the user will just see the option to Create Approvals in the service request, and will define approvals manually.
  3.  Both methods can also be available for a service:  If Approval Generation Method is set to Both Options Available, the fields visible for the Predefined Workflow Only method are visible, along with the option to manually create approvals.

If the service for the request allows for a Predefined Workflow, the Approval Workflow Title appears and populates with the Default Workflow for the service. To create approvals based on the workflow:

  1. Click Generate Approval(s).  Any approvals generated based on the workflow will appear in the table of Approvals Needed below.
  2. If the service also allows manually created approvals, the user can create additional approvals by selecting the Create Approvals checkbox.
    1. This causes the Manual Approval Creation section to appear. Enter an Approval Title, give the approval a Step Number, and click Generate Approval.
    2. After clicking Generate Approval, the new approval will be added to the table of Approvals Needed. This process can be repeated to create multiple ad hoc approvals.
  3. Once all approvals are created, click Launch Approval Process. Launching the approval process sets the approval(s) with the lowest Step Number from Queued to Pending Approval. In addition, an email is sent to the Approver, or the Approval Team.
  4. Approvers have three options for taking action upon approval records. They can click Approve, Require Changes, or Permanently Reject.
    1. Approve sets the Status of the approval record to Approved and triggers launching of the approval(s) in the next highest step number, provided there are no other approvals with the same step number waiting to be approved. 
    2. Require Changes results in an email to the Assigned Person of the service request. 
    3. Permanently Reject sets the Status of the approval to Permanently Rejected, sets the Status of the service request to Canceled, sets the Status of any other Queued or Pending approvals for the service request to Not Needed, and triggers an email to the Submitter and Assigned Person for the service request to notify them of the rejection.
  5. Once the first step approval is approved, the next one(s) in the sequence is set to Pending Approval. Once all approvals are approved, the Status of the service request is set to Approved. SLA timeframes for the service request are then updated, using the date the service request was approved as the start time.

Using Tasks for a Service Request

Some services are defined to have a set of tasks that should be completed. The task method is defined in the service record as described in Tasks for Service Requests. If tasks are associated with the service, they are generated by the technician responsible for the service request when ready, on the Tasks tab.  For the user-selected tasks, the Generate Tasks button remains visible in case the user decides to check additional boxes after generating the first tasks. Validation prevents the same tasks from being created a second time for the same service request.

Tasks are created with a status of Queued or Conditional (if the task is marked as a conditional task, that is, the task is only needed if some particular field condition is met, defined in the task template). A rule running on creation handles assignment. Once the tasks have been generated, the Launch Tasks button becomes visible. When the Launch Tasks button is clicked, all tasks that have no prerequisite tasks are set to a Status of Assigned, and the assigned team or person is notified with an email. The Date Due and OLA Target dates (if OLAs are used) are set to start the clock from when a task is assigned. 

The Sequence field indicates the general sequence of tasks. If all the tasks have a Sequence value of 1, this indicates that they are likely all parallel tasks triggered at the same time. If a task has one or more prerequisite tasks, its sequence value is automatically set to the highest sequence value of its prerequisite tasks plus 1. So if a task has prerequisites whose Sequence values are 1 and 4, it will be set to 5. This numbering does not "do anything", it is just descriptive of the general order in which the tasks are expected to be done.

If there are tasks that have prerequisite tasks, those tasks remain in the Queued or Conditional status until all of their prerequisites are completed, at which point any conditions are checked (for the conditional tasks) and the status is set to Assigned or Not Needed (if the condition for a conditional task is not met). In the example above, the last task is Queued waiting for its preceding tasks to be completed. The two sequence 2 tasks were assigned at the same time, since their sequence 1 prerequisite task was Completed/Approved.

When tasks are used, two fields track the number of tasks and the number of completed tasks - those with a terminal status.  When these two fields match, meaning that the final task has been completed, a rule notifies the assigned person or assigned team (if no assigned person) that the final task is done.

Reporting Time Spent

Technicians may easily report the time they spend on handling service requests. There are two fields: Time Spent and Time Description, and an action button: Add Time, on the Time tab of the layout. Entering values there will automatically create a new time entry record when the Add Time button is clicked. The time entry will show the work done by the technician and on the current date. 

All the time entries for a request can be seen on the Time tab as well. If a technician needs to report time that was spent on a different day or by a different user, click the New button on the Time spent table to submit a time entry directly and change the date or "Done by" field. All time entered is totaled in the All Time Spent field, which can be used in reporting or billing.

The Add Time action button converts the time fields into a Time Entry record and then blanks out the current values so they will be empty. Note that this same time entry methodology is used in the Incident, Problem, Change Request, and Task tables. So time spent on each type of request will be held in a single table (Time Entries) from which reports may easily be run for all kinds of time. 

Canceling Requests

At any point after creation of a service request, a user can cancel their own requests by clicking the Cancel the Request button in the common area. After clicking Cancel the Request, users must confirm the cancellation in a new pop-up window. If confirmed, the service request's status will change to Canceled, any pending approvals for the request will be marked as Not Needed, any open tasks will be set to Not Needed, and any items requested will be marked Canceled.

Closing Requests

When the service request is resolved, the technician sets the Status field to Closed and enters the solution notes into the Resolution field. If a similar incident has been resolved and marked as a standard solution, a technician can click on the lookup icon next to the Resolution field.

This opens a new window. Use the search bar at the top to look for the most relevant service requests. If a service request with a similar resolution exists, technicians use the Import/Replace button to copy the service request's Resolution into the current service request. The standard resolution can be modified further if needed. The technician can also select a Closure Category, which is used for reporting. The Closure Category values are determined by the Closure Category Table, and can be modified to match your company's needs. 

When a service request is marked as Closed, fields in the Knowledge Management section appear, provided that this function is turned on. Standard Solution can be set to Yes when the service request is common or has a resolution that might apply to future service requests. Once Standard Solution is Yes, the Resolution in this service request can be selected and pulled into new service requests' Resolution fields using the lookup icon next to the field. 

Setting Review for Knowlegebase? to Yes indicates that a knowledge article will be created based on this service request. Once Review for Knowledgebase? is Yes, the Knowledge Document Status and Create Knowledge Article fields are visible. The default value of Knowledge Document Status is Pending Review, and once Create Knowledge Article is clicked, the Knowledge Document Status is automatically updated to Created. If it turns out the knowledge article is not necessary, change the Knowledge Document Status to Not Needed. Clicking Create Knowledge Article opens a new knowledge article record with some information mapped from the service request, such as the Title, Purpose, and Content. Additional required fields must be populated before saving the record. Once the new knowledge article is saved, it is automatically linked back to the originating service request. In addition, the knowledge article will automatically include details from the source service request.

Closing a service request triggers a workflow email to the customer that includes the content of the Resolution field and tells the customer that the request has been completed.

Customer Updates

If the customer updates the Service Request at any point, an email notifies the assigned person or assigned team (if there is no assigned person) of the update.

When the customer replies to an email or edits a Service Request in a status of Pending Customer, the status changes to Updated by Customer and an email notifies the assigned person or the assigned team (if assigned person is empty) that the customer has replied. The customer is able to update the Additional Notes field directly, and email replies are mapped to that same field.

The email sent to customers when their ticket is closed includes a link back to the record if they wish to reopen it and instructs them to explain why they are not satisfied with the solution. Clicking the link will automatically change the "I Would Like To Reopen My Service Request" field to Yes, which in turn sets the status of the service request to Reopened and notifies the assigned person.  It also increments the # of Times Reopened by 1.

Customers may alternatively be sent a link to submit a survey. Once the survey is saved, it is added to the Surveys table where it can be included in reports and used to inform service improvement plans. 

Validations and other Automation

Following are some of the validations and other automation managed by the system:

Workflow

Image of the Workflow editor showing the 9 statuses for Service Requests. The diagram shows which states can move to which other states, such as Pending Approval can move to Approved, Open, or Canceled.

Ownership

Records in this table are "owned" by the person whose login matches the Submitter Login. This means each record is associated with a particular login and no other "end user" employee will be able to edit that record. All technician users are able to edit any service request by default.

Reporting and Statistics

Several fields are included that are used for statistical reporting. The following fields may be of interest:

There are default reports measuring Total Time Spent by Service Category, Average time to close by service category and by person who closed, as well as averages for number of people assigned, number of teams assigned, and so on. With the field structures already there, it is easy to add reports to slice and dice the information the way you need it. Below are a few examples of the default reports.

Service Demand Report

This is a Trend graph that shows a trend analysis of the service demand over time based on the number of Service Requests for each Service. 

Example report showing the types and number of services grouped by weekly time slices.

Billable Service Report

This is a Bar Chart that shows the dollar amount of Billable Services provided for each Department.

Chart shows the highest amount of billable services for the Customer Support department, and the lowest bar in the chart for Marketing.

Active Service Requests Segmented by Service

This is a Bar Chart that shows the number of active Service Requests for each Service.

Example report image. Bar chart of Active Services shows nearly all in the 'Other' category.