A resolution determines that the issue described by the service request was resolved and can either be a temporary or a final resolution.

A resource is a user that works in order to deliver the service request for a specific period of time.

EXAMPLE

The allocation process is used to allocate credit transactions against debit transactions to settle them.
The allocation process is an automated process triggered every time a financial transaction becomes 'Posted'.
Within CRM.COM, you have the option to select between one of 2 main allocation process principles, that will be applied to all financial transactions within the system;

• FIFO :Where a credit is allocated against the oldest available (non-allocated) debit automatically
• FIFO & Against Item :Where a credit is allocated first against a designated debit and any remaining amount is allocated FIFO

The Caller Contact is the customer who calls the Call Center to make a Request. The Caller Contact can be either the Account Owner who initiated the Service Request or any other Contact who is associated with the Account Owner.

Level set based on the effects the Service Request has either on the customer or the company so that it can be handled accordingly by the company's technical staff.

Defines how critical the Service Request is so that it is given the appropriate priority for resolution.

Level automatically assigned to the Service Request based on the selected Impact and Urgency Levels. It defines the priority that will be given to the Service Request for its resolution. In Service Request Definitions, a Priority Level is assigned to each combination of Impact and Urgency Level.

The answer provided by the User in reply to the issue/question logged on the Service Request.

An interim solution to a Service Request until the final solution is provided.

The final solution provided to a Service Request.

A User that works to complete the Service Request.

A Service Request State Flow consists of the following steps:

1. Create: when a customer contacts the Call Centre to report an issue, a Service Request is created and can be related to either a Job or Subscription

2. Accept: an authorised agent accepts the Service Request so that it can be processed further
3. Respond: an agent responds by acknowledging receipt of the Request
4. Resolve:
   1. Temporary Resolution: Temporary Resolution is provided to the Service Request
      1. If a Temporary Resolution is provided, the customer needs to accept it to be able to proceed to the next step.
   2. Final Resolution: Final Resolution is provided to the Service Request.
5. Completed: the Final Resolution is accepted by the customer.

The nature of a Service Request often requires a continuous interaction between the agent and the customer. To ensure that the customer is contacted at the appropriate time Communications can be automatically triggered and sent, whenever the Life Cycle State of a Service Request is modified. Pre-configured Communication Templates are used that include the information to be communicated to the customer.
The use of Dynamic Links in email Communications allows the customer to review the agent's replies (Response, Temporary Resolution, Final Resolution) and accept or deny them by clicking on the respective links available in the emails.

Service Requests can be independent tasks or be a part of bigger tasks. There are cases where an inquiry results in a new order, such as a New Subscription or the replacement of a Physical Good. Such tasks must be handled by Jobs as they cannot be completed by Service Requests. To this end, the 'Plan A Job' Action is available through Service Requests. The Service Request cannot be completed unless the associated Job is cancelled, deleted or completed, thus ensuring that the Request is successfully handled.

Service Requests may be handled by agents and closed instantly or may require follow-up Actions. If the required follow-up Actions are simple, they can be handled through Activities which are easily planned with the 'Schedule An Activity' Action, available through the Service Request.

• Accounts Receivable based Entities
• Assignable Entities
• Explicit Viewing Access Entities

• Service Requests cannot be created unless an Accounts Receivable is selected
• Service Requestsmust be assigned to a User that will be responsible for processing and completing the Service Request
• Service Request entries can be accessed, viewed and modified by Users defined as members of the Service Request's Owned By Group, by users that belong to a Group that collaborates with the Owned By Group, or by Super Users.

• Controlled Selection Access Entities

• A Type can be added on a Service Request, by Users who belongs to one of the Allowed Organisational Units defined in the Type, or a collaboration exists between their Unit and the AOU of the Type, or by Super Users.

Various activities can be

scheduled through Service Requests.

A Service Request is owned by Accounts Receivables.

Contact Information

own the Service Requests through

their Accounts Receivable.
The contact is usually the person that called to raise the Service Request.

Service Requests and Jobs are related in two separate ways:

1. Service Requests can be created referring to

1. a Job, in which case the Request was created for a specific task to be conducted as part of the Job's Resolution.
2. Jobs can be performed for a Service Request. If a Job is planned for a Service Request, it is usually due to follow-up Actions that need to occur for the Service Request to be completed.

Non-Traceable Physical Goods

can be added to Service Requests so that they can be checked.

A Service Request is assigned either to a Unit or a User. Users have the option to assign the Service Request to a Unit so that a further assignment is done by the employees within the Unit. Service Requests cannot be processed unless assigned to a specific User.

Communicationscan be automatically sent when a Service Request reaches a specific Life Cycle State depending on the Service Request Type.