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, pre-approved change to an existing service, a password reset, or some other kind of assistance or information.

When the user needs to report an interruption in service or a problem with an existing service, an Incident should be created instead. We have chosen to separate service requests from incidents because these two kinds of request have rather 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 relatively quick to resolve.

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

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

The Service Request table uses the same choice list of service categories as the Services table.

A user creating a service request chooses the category of service from a drop-down, and then sees all the active services that belong to that category in a second drop-down list. The default service categories for service requests can be seen in the services table or by creating a Service Request record and opening the drop-down list.

Use Case

Service Requests 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, should an inbound email account be set up.

End User Record Submission

When a customer submits a Service Request, the contact information fields automatically populate based on the details in his/her User 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 easily be changed by modifying the linked fields from the User table to enable "non-source" values to be used.

The user is required to select a service after selecting a service category. When the service is selected, the user will see a description of the service, any special instructions for that service, and any additional dependent fields defined to be visible for that service.
He may then provide further information and click Save to save the form, after which he will receive an email acknowledging receipt of the request.

Automatic Assignment of New Requests

When a new request is saved, it is automatically assigned to a team based on the values in three fields pulled from other tables (Rule: All new Service Request actions, Action: Assign Service Request). The related service has a Responsible Team associated with it and a field called Give Service Team Priority over Asset Team that has Yes/No values. If a Asset was identified for the request, then there is also an Asset Responsible Team field that will be populated in the SR.

The current assignment logic is: if the Service Request involves a specific Asset, then the request is assigned to the responsible team for that Asset, unless the Give Service Team Priority over Asset Team field is set to Yes. In this case, or If no Asset 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. The current logic is implemented in the SR rule named "All New Service Request Actions" and may be modified there.

Technician Record Submission

If a technician creates the SR, he may choose an assigned team and assigned person from the drop-down fields, and his changes will not be overwritten – the rule only assigns 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 are already starting work on it, or Closed if they were able to resolve the issue immediately and want to capture the request for reporting purposes.

Automatic Emails Sent upon 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 turned off by technician users. This option is set in the workflow options, and can be modified.

If the status is not Closed when saved, the rule named "All New Service Request Actions" will send the customer an acknowledgement email and will also send an email to either the Assigned Person, if there is one, or to the Assigned Team.

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 Request record as described above in Tasks for Service Requests.

If tasks are associated with the service, they are manually generated by the technician responsible for the service request when ready, on the Tasks tab.

In the screenshot above, the user has generated two of the user-selected tasks by using the Generate Tasks button, and has also created an ad hoc task using the Create Ad Hoc Task button.

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. Conditional tasks are only needed if some particular field condition is met and are 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, or whose prerequisites have been marked as Not Needed, are set to a Status of Assigned, and the assigned team or person is notified with an email. The Date Due is also set based on several criteria.

The Sequence field is used to indicate 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 is not functional, 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. When they are completed, 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 two tasks are Queued waiting for their preceding tasks to be completed. The top two tasks were assigned at the same time, since they had no prerequisites.

When tasks are used, two fields track the number of tasks and the number of completed tasks 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 there is no assigned person, that the final task is done (Rule: Tasks Just Completed; Action: Notify Assigned team or person of completed tasks).

Processing of Records

If a technician working on a Service Request needs more information from the customer in order to take further action, she can set the status to Pending Customer. A workflow action will automatically send an email to the customer requesting further information and including the content of the Additional Notes field, an append-only field that is used to communicate with the customer. The email includes a hyperlink for the customer to click to edit the Service Request directly.

If the technician needs to reassign the Service Request to a different team or person, he or she simply changes the Assigned Team and/or Assigned Person field and the system will email the new assignee notifying them of the reassignment (Rule: Assigned team or person changed; Action: I: Notify team or person of new assignment).

The Staff Only Notes field is an append-only field that holds technician working notes that are not visible to the customer.

When the technician has completed work on the Service Request, they set the Status field to Closed and put the solution notes into the Solution field. This triggers a workflow email to the customer that includes the content of the Solution field and tells the customer that the request has been completed. By default, no escalation rules are set up for the Service Request table.

Reviewing for Knowledgebase and Standard Solution Inclusion

When the Status is changed to Closed, additional required fields become visible at the bottom of the Working tab:

The person closing the request is required to update the Standard Solution field and the Review for Knowledgebase fields. The Standard Solution defines a subset of requests that have a Resolution field value that may be reused in another request. Requests with a Yes in that field become available to the lookup next to the Resolution field:

That lookup searches for standard solutions and provides a button to import their Resolution field value into the request that is currently being edited. So it is helpful to mark useful responses in this way so they can be reused.

The Review for Knowledgebase? field is used to create another subset of requests that should be considered for conversion into a Document FAQ. The conversion to a Knowledge Article may be done directly by the service technician using the Create Knowledge Article button shown above, or that button may be permission-controlled to be visible only to someone in a higher level group.

There is a built-in report finding all service requests with a Yes value in the Review for Knowledgebase field and a Pending Review value in the Knowledge Document Status field. This report can be scheduled and mailed to a team responsible for creating new Knowledge Articles in the Documents table.

Clicking the Create Knowledge Article button opens a new document record and maps fields from the request into fields in the new record. Additional fields can be filled out as well. When the document record is saved, a runs and updates the service request to set the Knowledge Document Status to a value of Created. That hides the create button so it will not be converted again.

If upon reviewing the request, the reviewer determines it should not be converted, they can change that field to Not Needed so that the request will stop appearing on the reports of items to review.

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 here automatically creates a new time entry record when the Add Time button is clicked. The time entry shows 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, they may 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. Time spent on each type of request will be held in the Time Entries table, from which reports may easily be run for all kinds of time.

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 the email or edits a Service Request in a status of Pending Customer, the status changes to Updated by Customer (Rule: all customer update actions, Action: User Update Actions) 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 closing email to customers includes a hotlink 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 hotlink 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 (Rule: All customer update actions, Action: User Update Actions).

Workflow

Ownership

Records in this table are "owned" by the individual customer. 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:

• Number of Assignees – is auto-incremented each time the assigned person changes (Rule: Assigned team or person changed, Action: Notify team or person of new assignment)
• Number of Teams Assigned – is incremented each time a different team is put in the Assigned Team field (Rule: Assigned team or person changed, Action: Notify team or person of new assignment)
• Number of Reopens – is incremented each time a closed request is reopened by a customer
• Total Hours to Close – elapsed time between Date Created and Date Closed, which is the default value
• Working Hours to Close – elapsed time between Date Created and Date Closed minus the non-working hours of the team in the Assigned Team field and the time during which the Status was Pending Customer, which is the default value
• Solved Within SLA – yes/no field with default value of Yes, is set to No when the total hours to close is greater than the relevant SLA Hours to complete field, which is pulled in with the service and based on priority (Rule: Status Change Actions, Action: All status change actions)

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, number of reopens, 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.