Business Feature / Process | Description | Example/Use Case | Use in Training Material | Additional Notes |
|---|---|---|---|---|
Service Request | It is a request ticket for service by a contact to the business. Service request can be submitted by a back-office user or directly by a 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.
Once a Queue has been saved, 3 additional options are available to the user :
| |||
Stages | Stages are a 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 represent the service request ‘state’. ‘New’, ‘In-Progress’ and ‘Closed’ default queue stages are automatically mapped to the default SR sates 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 that is assigned to a service request ticket. This user is responsible to the ticket progress and ensure that this ticket moves through the statuses in the respective queue until it is closed. The Owner is specified from the SR creator and can be a system user or team of users. By default, the owner is the SR creator, unless otherwise specified. The owner can be changed even after SR is executed on the queue. | |||
Priority Model | Priority models defines the required effort for responding 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)
The medium urgency and medium impact setting is used as 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 to the service request. Each Service Request Queue can have it’s own applicable categories Once categories are defined, each service request can belong to multiple categories based on the queue it belongs to. | |||
Charges | On a service request the back-end user will have the ability to charge for one time services (activities) that are required to resolve the service request as well as for products (traceable/ untraceable physical goods). This will generate an invoice upon completion 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 to a Service Request.
|
General
Content
Integrations