Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 SR 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.

...

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

...

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.

...

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:

...

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 Working Notes 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.

...

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.

...

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:

...