| Excerpt |
|---|
| Learn to work with Service Requests |
OverviewService requests are used to register problems that customers experience with their products and subscriptions and to check whether products are under warranty. Service request types support the responsible agent by predetermining the category, priority level and possible statuses of the fault. Throughout its life cycle, a service request progresses through the following states: - Pending: the service request is registered and is ready to be assigned to an agent or department. Requests assigned to a department must be accepted by an agent before they can be processed.
- Responded: the agent acknowledges receipt of the request and provides an initial response, which is communicated to the customer.
- Temporary Resolved or Final Resolved: the agent provides an interim or final solution to the issue and communicates it to the customer. Interim solutions must be followed by a final solution. The final solution has to be accepted by the customer; otherwise another solution must be provided.
- Completed: Once the customer accepts the final solution, the service request is completed and no further processing can take place.
The handling priority of a service request depends on the impact of the issue on the customer's business as well as its urgency. Both values are provided by the agent when registering a new request while workflow rules can be established to assign requests of a particular priority to a specific agent. Additional actions necessary for the handling a service request, such as scheduling an appointment to repair a decoder or ordering a new one, can be planned directly through the service request page by using activities and jobs. Communication with customers can be automated to take place each time progress is achieved. Customers can respond through links available in their communication or by calling their agent. Setting Up Service Requests| Info |
|---|
| Configuration > CRM Application> Service Requests |
TypesTypes are used to determine the operational characteristics of service requests.
Configure the following entities before creating service request types and then add the ones you would like to make available from each type. - Statuses are used to label service request life cycle states (used to progress a service request) in a way that is meaningful to your organisation.
- Categories are used to provide a business classification to the service request, such as, information or request for a change. These classifications provide the user with input on how to handle the request, and can also be used by the business to analyse the type of calls they receive.
- Response categories provide a business classification to responses provided to customers, and can be used by the business for future analysis. They are added to a service request when it progresses to a 'Responded' state. You can configure a response category to designate whether a response must be accepted by the customer before it can be temporarily or finally resolved.
- Final resolution categories provide a business classification for how the call was resolved, and can be used by the business for future analysis. They are added to a service request when it progresses to a 'Final Resolution' state.
- Temporary resolution categories provide an optional business classification for temporary solutions provided before the call is resolved, and can be used by the business for future analysis. They are added to a service request when it progresses to a state of 'Temporary Resolution'.
The users which will be authorised to create service requests of each type are designated by the 'Allowed Organisational Unit'. Type Fields Mandatory Configurable | Main Information |
|---|
| Estimated Completion Time | How long it is expected to take before the request is completed, measured in minutes, hours, days, weeks and months. |
|---|
Allowed Statuses & Categories |
|---|
Statuses Categories Response Categories Temporary Resolution Categories | This area is used to designate the configurations that will be available for use with each type of service request. A default from each field must be defined. Note: A default value for 'Temporary Resolution Categories' is only required where 'Allowed Statuses' include a status of a 'Temporary Resolved' state. |
|---|
| Allowed Products & Types |
|---|
Physical Goods Services | 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. |
|---|
| Activity Types | 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. |
|---|
| Job Types | Jbos 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. |
|---|
Status Transitions Defines the possible progression of status from each selected service request status. The next possible status depends on the current status of the request, the type of the request and on the user's or unit's authorisation. |
|---|
Status | The initial status of the entity. There can only be one initial status and it must be included if allowed statuses are defined. |
|---|
Status Transitions | The series of predetermined status changes which a service request can progress through. Each entry consists of the following: - Status: the current status on a service request
- Destination Status: the status that can be selected after the current status. One or more can be defined.
- Allowed Organisational Units: Used to authorise specific units or users to make the transition.
|
|---|
| Communication Settings |
|---|
| Send Communication | Customers and agents remain in contact throughout the processing of the service request. Pre-configured communication templates can be used to trigger messages when the life cycle state of a service request is modified. The events which can be selected to trigger a communication are: - On Create
- On Update
- On Start Progress
- On Respond
- On Temporary Resolved
- On Final Resolved
Links in email/SMS communications enable the customer to review the agent's responses and solutions and accept them. |
|---|
| Communication Template | The template that is used to create the communication when the event occurs.
Note: Only 'Effective' templates with an 'Outgoing' direction can be selected. |
|---|
Back to top DefinitionsService requests definitions are business rules which are used to control the behaviour of service requests throughout their life cycle. Allowed service request types must be specified in the definition. An active definition must be present to perform any service request process.There can only be one active definition at a time. Definition Fields Mandatory Configurable Name | Description |
|---|
| Allowed Types |
|---|
Allowed Types | Defines the Types of service requests that can be used while creating new service requests. |
|---|
| Prioritization Model |
|---|
| Supported Impacts | Use this section to establish the Impact available in service requests. - Select the Impact Levels you want to support.
- Create a label for each of the selected Impacts
- Chose a default for the selected Impacts.
|
|---|
| Supported Urgency | Use this section to establish the Urgency available in service requests. - Select the Urgency Levels you want to support.
- Create a label for each of the selected Urgency.
- Chose a default for the selected Urgency.
|
|---|
Supported Priorities | Use this section to create a label for Priority ranging from '1' to '10'. |
|---|
| Priority Level Calculation | The configuration settings which determine which combination of Impact and Urgency Levels determine the Priority Level. | Urgency 1 | Urgency 2 | Urgency 3 | Impact 1 | Priority 1 | Priority 2 | Priority 3 | Impact 2 | Priority 2 | Priority 3 | Priority 4 | Impact 3 | Priority 3 | Priority 4 | Priority 5 |
|
|---|
Back to top The following modules are related to service requests and may be configured for the service requests module to operate at its full capacity. | Module Link | Area | Description |
|---|
Communications | Communication Templates | Can be used in service request definitions and types to automatically create communications when certain events occur. | Communications | Communication Definitions | Provides configuration options for communications. Communication settings must be provided so that service requests can automatically create email and SMS messages. | | Configuring Workflow Rules | Workflow Rules | Workflow Rules are used to apply actions on the entities below, under certain conditions. Each rule refers to one entity. - Activities
- Jobs
- Service Requests
- Subscriptions
|
Using Service Requests| Info |
|---|
Service Requests can be accessed from: CRM > Service Requests > Manage Service Requests |
Service request fieldsThis table contains an explanation of the sections of the service requests Data Entry page, a description of the usage of its fields and additional information.
Mandatory Configurable Contact Information |
|---|
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.
| Account Information |
|---|
The account details of the customer that reported the issue. | Service Request Terms |
|---|
Service Request Information | 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 which 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 the service request. Urgency describes how quickly a resolution must be provided.
The default Urgency Level depends on the type of the request. Priority Level is set automatically and is based on the selected impact and urgency level, depending on the prioritisation model in the service request definition.
Set workflow rules based on priority to assign the request to specific users. 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. Contact Email Address 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. Contact Phone is 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.
|
|---|
Related Entities | 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. |
|---|
Key Dates | 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, 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. |
|---|
Response |
|---|
A section that confirms the receipt of a service request. The section appears on the page once the life cycle state of the request changes from 'Pending' to 'In progress'. 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.
| Resolution |
|---|
Temporary Resolution | A section that indicates that an interim solution has been provided for the service request. The section appears on the page once the life cycle state changes to 'Temporary Resolved'. 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. |
|---|
Final Resolution | A section that indicates that the service request has been processed and the issue is resolved. The section appears on the page once the life cycle state changes to 'Final Resolved'. 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 Products |
|---|
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. | Related Service Requests |
|---|
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.
| Activities |
|---|
Displays the activities that have been scheduled for the Service Request and which can be filtered by life cycle state.
| Action Panel |
|---|
Status & Notes | 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 are 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. |
|---|
Assignments | 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.
|
|---|
Service Request Actions | Actions: Used 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. - 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 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 the job defined in the 'Referring To' field.
- Approval Requests: A list of Approval Requests related to the service request.
|
|---|
Back to top Creating and processing requests| Note |
|---|
Actions are subject to validations which take place before an action is initiated (prerequisite) or after it is submitted (postcondition). |
Selecting and creating a service request
Specify the criteria that match the requests you are interested in or use NEW from the Actions Menu to create a new request. Provide the mandatory information in the service requests fields table before you SUBMIT the request. | | New |
|---|
| Prerequisites | - 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 Organisation Units'.
|
|---|
Modifying a service request
Use EDIT from the Actions Menu to enter edit mode.
Additional Information While service requests that are assigned to a unit and are pending acceptance by a user can be modified, the 'Assigned to User' can only be set through the Accept action. Refer to Accepting Service Requests. Prerequisites | 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.
|
|---|
Deleting a service request
Use DELETE from the Actions Menu to delete 'Pending' requests. | Prerequisites | - Life cycle state must be 'Pending'.
- The request is not completed.
- There are no scheduled activities which are not completed, deleted or cancelled.
- There are no planned jobs which are not completed, deleted, or cancelled.
|
|---|
Back to top Accepting a service request
New service requests are assigned to a unit or a user. Requests assigned to a unit can be accepted by a unit member, by using the Accept action from the Actions Menu in the Data Entry page. For example, a request regarding an issue with a Roku box is assigned to the repairs department and then accepted by a specific agent. | Postconditions | Users must be authorised to accept a service request ('Accept Service Request' action is enabled in their security profile) and they must be a member of a unit to which the service request is assigned to or a member of a unit in the same group. |
|---|
Responding to a service request
A response is used to confirm the receipt of a request. The Response section, which the agent is required to complete, becomes available once the life cycle state is set to 'Responded'. 'Accepted By Contact' field is mandatory if defined in the configuration of the Response Category. Additional Information
A communication is created when the request is responded, provided 'communication settings' are enabled in the active service request definition.
Customers can automatically accept responses through email/SMS links. Once the customer clicks the respective link, the response of a service request is set as 'Accepted by Contact'. For more information refer to the Communications manual.
| Prerequisites | The request's life cycle state is 'Responded' |
|---|
Resolving a service request
A solution to the request can take the form of a temporary or final resolution. The Temporary Resolution or Final Resolution sections, which the agent is required to complete, become available once the life cycle state is set to 'Temporary Resolved' or 'Final Resolved'.
Additional Information Providing a temporary resolution is optional; service request types can be set up to skip this state. A communication is created when the request is provided with a resolution, provided 'communication settings' are enabled in the active service request definition.
Customers can automatically accept solutions through email/SMS links. Once the customer clicks the respective link, the resolution of a service request is set as 'Accepted by Contact'. For more information refer to the Communications manual.
| Prerequisites | - Temporary and Final Resolution: the Response section must already be completed. If the response category requires customer acceptance, then the response must have already been accepted.
- Final Resolution: if a temporary resolution was provided then it must be accepted by the customer.
|
|---|
Postconditions | The resolution can only be accepted by the caller or a related contact. |
|---|
Back to top Completing a service request
Change the life cycle state of a service request to 'Completed' by selecting the appropriate status, indicating the issue is resolved.
Additional Information A communication is created when the request is completed, provided 'communication settings' are enabled in the active service request definition. | Postconditions | - Final resolution has been accepted by the customer.
- Jobs planned through the service request are completed, deleted or cancelled.
- Activities scheduled through the service request are completed, deleted or cancelled.
|
|---|
Applying business flows
Scheduling an activity for a service request
Use 'Schedule An Activity' from the Action Panel area of the Data Entry page, in order to schedule additional necessary actions for service requests, such as scheduling an appointment.
View Activities for more information. - The contact information and service request number are carried over onto the activity from the service request.
- Activities scheduled through the service request must be completed, deleted or cancelled to complete the request.
Planning a job to complete a service request
Use 'Plan A Job' from the Action Panel area of the Data Entry page for actions that cannot be handled through service requests. For example, the registration of a new subscription or replacement of a box.
View Jobs for more information. Additional Information - The accounts receivable specified on the service request is carried over onto the job.
- Jobs planned through the service request must be completed, deleted or cancelled to complete the request.
| Prerequisites | The action is available if the service request is in a 'Responded', 'Temporary Resolved' or 'Final Resolved' state. |
|---|
Back to top Approving a service request
Service requests can be set up to require approval from a specific user before they are further processed. This is done by setting up Approval Definitions and triggering Workflow Rules.
For more information on Approval Requests refer to /wiki/spaces/WIP/pages/10008784.
Relating service requests
Service requests can be related to similar or relevant requests of the same contact.
- Go to the Related Service Requests section in the service request Data Entry page
- Click on EDIT from the Actions Menu
- Click on NEW under Outward Relations to create a new request or ADD to select an existing request.
Communicating service requests
Customers and agents remain in contact throughout the processing of the service request. Pre-configured communication templates can be used to trigger messages when the life cycle state of a service request is modified. A service request can also be manually communicated by using the Communicate Service Request action available through the Actions Menu.
Links in email/SMS communications enable the customer to review the agent's responses and solutions and accept them. You can use tags related to service requests (text that is automatically replaced by values specific to selected records) when creating communications. Tags are available for selection by typing '#'.
Refer to the Communications manual for a complete list of service request tags. Applying warranties on service requests
Service requests can be used to check for the coverage of faulty hardware items, available when the item is under valid warranty.
ADD the faulty item in the Affected Physical Goods tab of the Affected Products section. Check for coverage by selecting the coverage reason from the drop-down menu. The Covered field indicates whether a free replacement is available.
Use service requests to check whether the good is under warranty and plan a job to replace it. | Prerequisites | The physical good must be under valid warranty. |
|---|
Applying workflows on service requests
The CRM.COM Workflows module can be used to automate processes. For example:
- Use Alerts to email or SMS users, when a specific value is entered in a service request field
- Schedule activities when a request of a specific type is created
- Assign high priority service requests to a specific user
For more information on workflow automation refer to Workflows. Back to top Service Requests AnalyticsSegmenting service requests
You can group service requests with common business characteristics. Use the lists in system business processes for identification of customers or for simple statistical calculations.
For more information on Segmentation and how you can create service request lists refer to Segmentation.
Dashboards
Dashboards make information regarding the key performance indicators of the progress of the service request available from a single integrated view. Dashboards are made up of components such as charts and summary tables. Refer to Dashboards for information on their use and set-up.
Service request dashboard componentsCompleted Service Requests per Type and MonthThe component displays the service requests which were completed within each of the last 12 months, in a vertical stacked bar chart, grouped by service request type and month. The results can be filtered by service request type. New Service Requests per Type and Month The component displays the service requests whose processing was planned to start on a specific date in the last 12 months, in a vertical stacked bar chart, grouped by service request type and month. The results can be filtered by service request type. Overdue Service Requests per TypeThe component displays the service requests whose processing completion is overdue, i.e. the requests included in the component are not a 'Completed' state and are past their expected completion date. The results are displayed in a stacked bar chart, grouped by service request type and predefined period buckets (the difference between the current and expected completion date), and can be filtered by service request type. Pending Service Requests per TypeThe component displays pending service requests, i.e. those not a 'Completed' state, in a pie chart, grouped by service request type. The results can be filtered by service request type. Service Requests assigned to logged in user The component displays the pending service requests, i.e. those not a 'Completed' state, that are assigned to the logged in user, in a summary table. The results are sorted on expected completion date, starting from the date closest to the current date, and can be filtered by service request type. Back to top Reports
Service Request information can be extracted in a structured format for analysis by using reports. The service requests included in the report are selected and grouped based on user defined criteria. The user can select the fields displayed in the report.
Refer to Reports for information on their use.
Service request status reportThe report displays a list of service requests extracted based on their type and status.
Service Requests Business Example| Panel |
|---|
| Scenario Mary is reporting that a fault in her Roku box is affecting the subscription TV channels.
Solution As this type of service request is common, system presets are in place to support the agent in dealing with the issue effectively. Requests for technical support require customer acceptance to be completed. Configuration
The basic configuration specific to the above business requirement should be as follows: | Service Request Statuses (LFS- life cycle state) | - To be approved (Pending LFS)
- Assigned (Responded LFS)
- Final Solution (Final Resolved LFS)
- Completed (Completed FLS)
|
|---|
Service Request Categories | - Service Request Category: Technical Support
- Response Category: Approved for Resolution
- Final Resolution Categories:
- Change of Decoders
- Change of Smartcards
|
|---|
| Service Request Type | Technical Issue
- Estimated completion time: 1 day
- Allowed categories (SR Categories, Response, Final Resolution)
- Communication Settings: enable communication settings to send email to the customer on responding and providing a final solution
|
|---|
Service Request Definitions | Create and activate a service request definition and add the Technical Issue request type in the allowed types |
|---|
| Workflow rule | Create a rule to assign Technical Issue request type to 'Technical Department' |
|---|
User Process
- The agent creates a new service request of type 'Technical Issue' and adds the serial number of Mary's Roku box in the affected products.
- The call centre agent submits the service request which is automatically assigned to the technical department (according to the Workflow rules).
- An agent from the technical department accepts the request and informs Mary that her request is being processed by providing a response.
- The response is sent to Mary when the request is saved (according to the communication settings of the service request type).
- The agent calls Mary, identifies the issue, and guides her through the necessary steps for resetting her Roku box.
- The agent changes the status of the service request to one reflecting a 'Final Resolved' life cycle state.
- In the resolution description section, the agent reports that a reset of the Roku box resolved the issue Mary was experiencing.
- The final solution is sent to Mary when the request is saved (according to the communication settings of the service request type).
- The agent requests Mary to accept the solution by clicking on the respective email link.
- Mary replies by clicking the link in agent's email, confirming the issue she was experiencing has been resolved.
- The agent changes the status of the request to 'Completed' and closes the service request.
|
| Note |
|---|
| - If you are using a previous release, view CRM.COM Release Changes.
- Use the Service Requests WEB API to create and manage Service Requests from an external system, such as a customer portal. View the Service Requests WEB API for a complete list of actions available through the WEB API.
|
Glossary| CRM.COM Term | Definition |
|---|
| Job | Small A small project initiated by the operator for customers, involving the delivery and billing of services, products and products, as well as activities. Customer requests and orders, such as that for a new subscription, can be initiated and registered through a job. |
|---|
| Subscription | A collection of customer services which is provided to customers and billed on a recurring, usage or Oneone-Time time basis. |
|---|
| Workflow | Support business workflows and automate tasks required to complete business processes, triggering system actions provided certain events or conditions occurA set of tasks which are necessary to complete a bigger task, involving the definition, execution, and forwarding of the task among users for action, according to a set of workflow rules. |
|---|
| Activity | Small task or action that is either stand-alone or must be completed as part of a larger project. |
|---|
| Communication | Used to log bidirectional Log interaction between customers and agents conducted through email. Communications can support multiple Communication media such as Email, SMS, telephony, letters or face to face interactionand others. |
|---|
| Panel |
|---|
| | Filter by label (Content by label) |
|---|
| showLabels | false |
|---|
| spaces | V4Manual |
|---|
| showSpace | false |
|---|
| labels | global |
|---|
|
|
|