Business Feature / Process | Description |
|---|---|
Service Request | A Service Request is a ticket a contact or system user raises (for a contact) to request a service from the business. A back-office user or Contact can submit Service Requests via self-service APIs (e.g. CRM.COM app or portal). A Service Request is always associated with a contact and a queue. A queue is a user-defined grouping method used to group similar Service Requests, for example, reward or billing requests. |
Queue | Queues group and dictate the core Service Request behaviour using stages. Multiple stages can be defined under the In Progress state, and there is only one New and one Closed state.
Once a Queue has been saved, four additional options are available to the user:
|
Stages | Stages are the steps in the queue that a Service Request progresses through one by one until it’s Closed. Each queue may have different stages based on the relevant process it supports (e.g., billing issues). Each and each stage in the queue is mapped to one of the states (New, In Progress and Closed). The default system stages (New and 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 state, these can be renamed or deleted as they are specified and created by a key user specifically for a type of queue. |
Numbering Scheme | Select the numbering format for your Service Requests. Each new Service Request will be assigned a sequential number based on the given format. |
Owner | A Service Request's owner is a CRM.COM back-end user or a team assigned to a Service Request ticket. The owner is responsible for progressing the ticket Service Request and ensuring that the ticket moves it progresses through the stages in the respective queue until it is closed. The Service Request creator specifies the owner, who can be a system user and/or a team of users, or Automations can be utilised in order to automatically assign a Service Request to a user and/or a team. If not specified, the owner is the Service Request creator by default. However, Only the Service Request’s owner can be changed to another user or team even whilst the Service Request is progressing through the queueor any user with the Owner user role can edit it. When a Service Request is also assigned to a Team, then team members have viewing access to the Service Request and they can only add notes or re-assign the Service Request to them. |
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 Service Request 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).
Select a priority for each Impact-Urgency combination. If no combination is defined, the system auto-populates it. 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 provide a business classification for the service request. Each Service Request Queue can be assigned multiple applicable categories. When a Service Request is created, the user can assign it one or more categories based on the queue it belongs to. |
Related 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, if for example, 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 subscription service, then select the subscription 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. Notes can be added by the owner and team member (if the Service Request is also assigned to a team). However, only the latest Note can be deleted and only by the user who added it. |
Attachments | Upload attachments related to the Service Request for easy referencing. |
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 to complete. |
Charges | The back-end user can log charges related to the Service Request, including fees for one-time services (activities) required to resolve the Service Request and products (both traceable and non-traceable physical goods). These charges can be edited from the moment the Service Request is created until it is Closed. Once the Service Request is completed and marked as resolved (when Closed), an invoice will be generated for the Contact, covering the associated services and products provided. If the Service Request is cancelled or left unresolved, the invoice will not be issued. |
Service Request Operations | The owner selects a Service Request from the summary screen to edit it. All Service Request details are editable except the Contact and the Queue associated with a Service Request.
|
Automations | Automations for Service Requests can be created based on the following trigger events:
Available actions depending on the selected event:
|
Approval of Service Request Progression | It’s possible to block a Service Request from progressing unless one or more users or the contact have given their approval. The users can see their pending approvals from the back-end system, and the contact can give their approval by clicking on a link sent in a communication. Approval Requests are configured using Automations. |
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. |
Events History | View the actions taken for the Service Request and the user who performed them. |
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. |
Custom Forms | Configure your own custom data screen for Service Requests. This is an external implementation designed using CRM.COM’s Back-Office APIs and hosted outside of CRM.COM, which can be loaded and used via the back-end system. |
Analytics |
|
...