Page Comparison

Service Request

It is a request ticket for service by a contact to the business.

Service requests can be submitted by a back-office user or Contact via self-service APIs (e.g., CRM.COM app or portal).

A service request always belongs to a Queue. A Queue is a CRM.COM user-defined grouping method that is used to group similar service requests (e.g., reward or billing requests)

Queue

Queues group and dictate core SR behaviour, such as allowed stages. Multiple stages can be defined under the In Progress state, and there is only one new and one closed state.

• New: This is the first and default status upon SR creation.

• In Progress: This is a transitional stage until an SR is closed. Usually, this stage is divided into several stages (e.g. response, follow-up)

• Closed: This is, by default, the final status of every queue. Closed SRs are not visible in the Kanban view.

Once a Queue has been saved, three additional options are available to the user :

• Edit Alert Times for Queue: These are notifications to users when a Service Request has not progressed from the New status yet. The alert times can vary depending on the priority of the Service Request.

• Edit Completion Times for Queue: This setting indicates how long a Service Request should take to be completed (from creation) based on its priority.

• Configure Application Settings: In case contacts are allowed to create Service Requests for a specific queue by using another platform (e.g., app or portal), then the Self-Service feature should be enabled.

Stages

Stages are back-end, user-defined discrete process steps in a queue.

Each queue may have different stages based on the relevant process it supports (e.g., billing issues).

The stages are completed and moving to the next as the service request progress until 'Closed'.

Each stage in the queue represents the service request 'state'. 'New', 'In-Progress' and 'Closed' default queue stages are automatically mapped to the default SR states, respectively.

The default system states (New, Closed) cannot be renamed or deleted as they are automatically assigned to each new queue upon creation.

User-specified stages are mapped to the 'In Progress' service request state; these can be renamed or deleted as they are specified and created by a key user specifically for a type of queue.

Owner

The Owner of a service request is a CRM.COM back-end user or a team that is assigned to a service request ticket.

This user The owner is responsible for the ticket progress and ensures that this ticket moves through the statuses in the respective queue until it is closed.

The SR creator specifies the Owner and can be a system user or a team of users.

By default, the Owner is the SR creator unless otherwise specified. The Owner can be changed to another user or team even after SR is executed on the queue.

Priority Model

Priority models define the required effort for responding to and resolving a service request by the user. Priorities models can be arranged according to SR urgency and impact. The urgency and impact levels will be set upon Service Request creation (either by the user or assigned automatically through a workflow rule)

• Impact Levels represent how important the request is for the customer.   

• Urgency Levels relate to how quickly a resolution must be provided.  

• Priority Model - select a priority for each Impact-Urgency combination. If no combination is defined, then it is auto-populated by the system. 

The medium urgency and medium impact setting is the default priority when creating a new Service Request. 

Categories

Categories can be defined in a hierarchical - tree structure and are used to provide a business classification for the service request.

Each Service Request Queue can have its own applicable categories

Once categories are defined, each service request can belong to multiple categories based on the queue it belongs to.

Link to other Service Requests

It's possible to link a Service Request to other Service Requests, if they are somehow related.

Related Address

Optionally specify an address related to the Service Request, for example, if the Service Request has been raised for a technical issue requiring an on-site visit. The address can be one of the Contact’s addresses or any other address.

Affected Services

If the Contact associated with the Service Request is a subscription service member, and the Service Request is being raised for a particular service, then select the service related to the issue.

Notes

Add internal notes related to the Service Request. Important notes can be pinned to appear at the top of the list of notes.

Attachments

Upload attachments related to the Service Request for easy referencing.

Tags

Assign tags associated with the Service Request. Tags can be used as a filtering option on summary screens and reports.

Custom Fields

If you require additional information not supported by CRM.COM, you can create custom fields of various formats to meet your specific needs.

Activities

If additional tasks need to be scheduled as part of the Service Request, create an activity and assign it to another user or team.

Charges

On a service request, the back-end user will be able to charge for one-time services (activities) that are required to resolve the service request and for products (traceable/ untraceable physical goods).

Upon completion, this will generate an invoice, and if the SR has been resolved(closed), the Contact will be invoiced for associated services and products supplied.

These charges are editable from the moment of creation of the service requests until the SR is resolved and closed. If the service request is cancelled, the invoice will not be posted.

SR Operations

First, the Owner has to select the specific Service Request from the Summary screen and edit it.

All values of a service request are editable except the Contact and the Queue associated with a Service Request.

• Progressing a Service Request: To progress a Service Request select the next status in the queue. A Service Request can only be progressed to the next status, following the current status or can be closed.

• Regressing a Service Request: Select the previous status in the queue to regress a Service Request. The user has to provide a reason for regressing. The history of regression is displayed below the progress bar.

• Close Service Request: By selecting the Close button from either the summary screen or the service request screen, the user will be prompted to specify whether the request has been resolved. If resolved, Contact will be billed for all items in the charges on the service request. If not resolved, then no charges will apply. In both cases, the SR ends up as closed.

Stage change Approvals

Configure Automations to manage the progression of the SR through the queue by requesting approval from one or more system users or the contact themselves (who can approve it through a communication sent to them).

System users can see approvals pending on them and accept/reject each one.

Print the Service Request

Print the Service Request using a configurable template to determine the layout.

Email the Service Request

Email the Service Request to the contact’s email address using a configurable template to determine the layout.