Provide a business classification regarding how the call was resolved and which can be used by the business for future analysis. The categories/classification are/is added to a service request when it progresses to a state of 'Final Resolution'. You can configure a final resolution category so that the customer must accept a final solution before a request can be completed.

Use this section to establish the Impact available in Service Requests.

1. Select the Impact Levels you want to support.
2. Create a label for each of the selected Impacts
3. Chose a default for the selected Impacts.

Use this section to establish the Urgency available in Service Requests.

1. Select the Urgency Levels you want to support.
2. Create a label for each of the selected Urgency.
3. Chose a default for the selected Urgency.

Use this section to create a label for Priority ranging from '1' to '10'.

The configuration settings that determine which combination of Impact and Urgency Levels determine the Priority Level.

How long it is expected to take before the request is completed, measured in minutes, hours, days, weeks and months.

This area is used to designate the configurations that will be available for use with each type of service request. A default must be defined for each field.

For Allowed Statuses it is mandatory to select a status from each required life cycle state ('Pending', 'Responded', 'Final Resolved', 'Completed'), which will also be set as the default status for each service request state.

Note: A default value for 'Temporary Resolution Categories' is only required where 'Allowed Statuses' include a status of a 'Temporary Resolved' state.

The products and product types that the service request type (currently being created) can handle. For example, you can create a type for handling decoder issues and another for handling modem issues. These products are added in the service requests 'Affected Products' sections.

If no products or types are selected, then all will be available.

Activities are scheduled for additional actions necessary for handling a request. Several activity types may be configured in the system, such as 'Book an appointment' or 'Installation', but only the ones defined under Activity Types will be available in service requests when the 'Schedule Activity' action is used.

Jobs are planned for additional actions necessary for handling a request, such as ordering a new box or replacing an existing one. Several job types may be configured in the system, such as 'Order new box' or 'Order new card', but only the ones defined under Job Types will be available in service requests when the 'Plan a Job' action is used.

The initial status of the entity. There can only be one initial status and it must be included if allowed statuses are defined.

Communications 

Communication Templates

Communications 

Communication Definitions

Provides configuration options for communications. Communication settings must be provided so that service requests can automatically create email and SMS messages.

Used to apply actions on the entities below, under certain conditions. Each rule refers to one entity.

• Activities
• Jobs
• Service Requests
• Subscriptions

Account Name: The account details of the customer that reported the issue.

Owner: The details of the customer that reported the issue.

The contacts cannot be changed once the request is saved but their details can be updated.

Caller/contact is the customer who initiates a service request.  The caller contact is selected from a contact list. The first and default choice is the account owner, followed by related contacts.
A contact can be related to the account owner in the Contact Information module.

Email is the electronic address to which all communications will be sent. It can be typed by the agent or selected from a list of available contact addresses.
The address is mandatory if there are communication settings enabled in the service request types.

The Phone number used to communicate with the contact.  It can be typed by the agent or selected from a list of available phone numbers.
The phone number is mandatory if there are communication settings enabled in the service request types.

Type determines the attributes available for service requests and their default values, as well as the automation of communications from the agent to the customer.

Category is a label that describes the purpose of the request.  For example, Information, Technical support.

Classification: Service request classifications are predefined in the system.  They are calculated based on the selected category.

Impact Level describes how important the request is for the customer. The default Impact Level depends on the type of service request.

Urgency describes how quickly a resolution must be provided. The default Urgency Level depends on the type of request.

Priority Level is set automatically and is based on the selected impact and urgency level, depending on the prioritization model in the service request definition.
Set workflow rules based on priority to assign the request to specific users.

Related Job /Subscription: Service requests can be related to a job or subscription.  For example, an issue with poor signal can be related to a subscription and a request for an installation can be related to a job.

The dates and time frames that are relevant to the request:

Start Date: The date on which the request was first saved.

Expected Completion Date: The difference between the start date and expected completion date. It is editable and measured in minutes, hours, days, weeks, months, and years.

Actual Completion Date: The date on which the service request life cycle state is set to 'Completed'.

Time to Completion: The time left up to the expected completion date. This information is dynamically calculated and updated based on the current date and the expected completion date.

Estimated Completion Time: The difference between the start date and expected completion date.

Time Overdue: The time past the expected completion date, calculated dynamically based on the expected completion date and the current date.

A section that confirms the receipt of a service request. The section appears on the page once the action 'Respond' is executed

Response Category:  Set to the type's default response category.

Response Date: Defaults to the time and date on which the response category is added.

Responded By: Defaults to the current logged in user editing the request.

Description: Can be used to keep track of changes.

Accepted by Contact:  Only contact information related to the account owner can be selected. This information is visible and applicable if the selected response category requires customer acceptance. If customer acceptance is required but not provided, the service request cannot transit to a 'Temporary Resolved' or 'Final Resolved' life cycle state. 

A section that indicates that an interim solution has been provided for the service request. The section appears on the page once the action 'Temporary Resolve' is executed

Temporary Resolution Category: Defaults to the type's default temporary resolution category.

Temporary Resolution Date: The date and time on which the temporary resolution is created.

Temporarily Resolved By*: Defaults to the current logged in User editing request.

Description: Can be used to keep track of changes by the user.

Accepted by Contact: Only contact information related to the account owner can be selected.

A section that indicates that the service request was processed and the issue resolved. The section appears on the page once the action 'Final Resolve' is executed.

Final Resolution Category: Defaults to the type's default response category.

Final Resolution Date: The date and time on which the final resolution is created and the final resolution category is selected.

Final Resolved By: Defaults to the current logged in user editing the service request.

Description: Can be used to keep track of changes by the user.

Accepted by Contact: Only contact information related to the account owner can be selected.

Affected Physical Goods: A list of physical goods for which the request has been raised. The physical goods can be either traceable or non-traceable. 
Note: If the product is under warranty, additional fields allow you to check whether a free replacement is possible.

Affected Services: A list of services for which the request has been raised. For example, a subscription TV channel for which a customer reported an issue.

In case a single service request is not enough for dealing with an issue, additional requests can be created and related to the initial request.

The Related Service Request section includes the following subsections:

Outward Relations: The service request chain created to handle related requests. You can either relate existing service requests or create new ones by clicking on the NEW link.

Inward Relations: Service requests appended to the main request.

Status: The status of the service request also defines its life cycle state and allows you to progress the request.

Life Cycle State: The progression of steps of a service request from the time it is created until it is completed.  For example, in order to be able to provide information on the final solution of a request, its status must be updated to one that has a 'Final Resolved' life cycle state. The state of the service request depends on the selected status set in the 'status configuration'; it is not manually set by the user. The allowed states are the following:

• Pending
• Responded
• Temporary Resolved
• Final Resolved
• Completed

Shared Notes: Use this section to record information regarding the request. Every time the notes are updated the time and the name of the agent is registered.

Owned by Group:  Refers to the Group that is responsible for executing the request. The Group defaults to that of the currently signed in user or it is automatically set based on the geographical area of the contact. Refer to Groups for more information.

The unit and/or user responsible for dealing with the service request.

The user field may be left empty, in which case users from the defined unit will be able to accept the service request. Refer to the Accepting Service Request Action.

Actions: Used to progress a service request and when further handling is required to complete a customer request without having to leave the service requests page. For example, an agent can check for the coverage of a malfunctioning Roku box and plan a job for a replacement through the same page.

• Progress Service Request
  • Accept: Assigns the service request to the user that executes the action (if the request is assigned to a unit and not a user).
  • Respond: Opens the response modal to provide the required information.
  • Manage Response: Opens the response modal to provide the required information and to progress to the next state.
  • Temporary Resolve: Opens the temporary resolve modal to provide the information required to temporarily resolve the service request.
  • Manage Temporary Resolution: Opens the temporary resolve modal to provide additional information required to temporarily resolve the service request.
  • Final Resolve: Opens the final resolve modal to provide the information required to resolve the service request and proceed to the next state.
  • Manage Final Resolution: Opens the final resolve modal to provide additional information required for a final solution.
  • Complete: Opens the complete modal to update the status to one of a 'Closed' life cycle state (required to close the request).
    
    
• Further Handling
  • Communicate Service Request: Opens the Communication Data Entry page in a modal window to prepare the communication to be sent to the customer.
  • Schedule an Activity: Opens the Activity Data Entry page in a modal window in order to schedule additional necessary actions.
    
  • Plan a Job: Opens the Job Data Entry page in a modal window in order to plan a job for actions that cannot be handled through service requests.
    

View History: A link that provides additional information related to the service request.

• Communications: A list of all the communications with this service request defined in the 'Referring To' field.
  
• Approval Requests: A list of Approval Requests related to the service request.

• There is an active definition.
• The action is allowed in the security profile of the logged-in user.
• The logged-in user has access to the service request type, designated in the type's 'Allowed Organisational Units'.

• Life cycle state must be 'Pending', 'Responded', 'Temporary Resolved' or 'Final Resolved'.

• Once a service request is created the related contact, account and service request type cannot be changed.

• Life cycle state must be 'Pending'.
• The request is not completed.
• All scheduled activities are completed, deleted or canceled.
• All planned jobs are completed, deleted, or canceled.

• Temporary and final resolution: The response section must be completed. The customer must have already accepted the response if the response category requires it.
• Final resolution: The customer accepted the temporary resolution.

• The customer accepted the final resolution. 
• Jobs planned through the service request are completed, deleted or canceled.
• Activities scheduled through the service request are completed, deleted or canceled.

Postconditions that apply to each destination status must be met.