Overview

Customer Care modules in CRM.COM are capable of handling sales and support functionality. Customer Care is comprised of the Service Requests, Activities and Leads modules.

• Use Service Requests to register problems that customers experience with their products and subscriptions and to check whether products are under warranty. 
• Use Activities to log tasks which take place as part of a specific business process such as a Lead or a Service Request. The activity maintains information about the task that is to be performed by tracking the resource that owns the task, the service that should be provided and eventually the actual time that was spent on providing each service.
• Use Leads to create and keep track of leads related to existing or prospect customers. The information collected during the entire process of transforming a lead into a customer helps in evaluating the lead in terms of how much effort and  time should be spent on the Lead by the sales person. 
• Setup and use Communications in combination with the customer care entities in order to communicate with your customers and keep them posted on issues concerning them. Communications can be created directly by a user or by other system processes such as Event Based Communications and Communication Plans.

Setting Up Customer Care modules and Core Processes

You will need to complete the setup for the Customer Care modules prior to using them. 

Setting up Service Requests

A Service Request could be a customer request for information, support or simply for a change. Service requests are also used to register problems that customers experience with their products or subscriptions and to check whether products are under warranty, whilst simultaneously assisting the user by categorising the fault and providing a priority level.  

Statuses

Statuses are used to progress a service request throughout its life cycle. Each status can have a predefined life cycle state of:

• Pending - The service request is registered and is ready to be assigned to a user or or department.  Requests assigned to a department must be accepted by a user before they can be processed.
• Responded - A user acknowledges receipt of the request and provides an initial response, which is communicated to the customer.
• Temporary Resolved - The user provides an interim solution to the issue and communicates it to the customer, interim solutions must be followed by a final solution. The temporary solution may need to be accepted by the customer; if not accepted then another solution should be provided. 
• Final Resolved - The user provides a final solution to the issue and communicates it to the customer who may need to accept the final solution. If not accepted then an alternative solution must be offered.  
• Completed - Once the customer accepts the final solution, the service request is completed and no further processing can take place.
• Cancelled - The service request can be cancelled while it's still in 'Pending' life cycle state, a cancellation reason must be provided.

Provide status names which are meaningful to your organization and map them to the pre-defined life cycle states. You must provide at least one status for each available life cycle state with the exception of 'Temporary Resolved', as it is not compulsory that a service request goes through a temporary resolution. 

Categories

Categories can be defined in a hierarchical structure and are used to provide a business classification to the service request, define your categories and map them to one of the following pre-defined classifications:

• Information
• Advice
• Standard Change
• Access to an IT service 
• Request for change
• Report an incident

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. 

Through Response, Temporary Resolution and Final Resolution categories (see below) you can provide a business classification to the responses and resolutions provided to customers, and can also be used by the business for future analysis. These categories are added to a service request to progress it to the respective life cycle state.

Response Categories

Define the categories that will be available on responding to a service requests (for 'Responded' life cycle state). The response categories can be defined in a hierarchical structure, and also allow for a 'Requires acceptance' option whereby you may indicate whether a response must be accepted by the customer before it can be temporarily or finally resolved.

Temporary Resolution Categories 

Define the categories that will be available for 'Temporary Resolved' service requests. As for Response Categories a hierarchical structure can be created and the 'Requires Acceptance' option is also available for acceptance by the contact before it is finally resolved. 

Final Resolution Categories

Define the categories that will be available for 'Final Resolved' service requests. Once again a hierarchical structure can be implemented and the 'Requires Acceptance' option can be activated for final resolution acceptance by the contact. 

Prioritisation Model

Prioritisation model defines the required effort for responding and resolving a service request by the user. Set up the model to be used for assigning a priority number to an issue according to its 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), and the system will use the Prioritization model table to assign the priority of the request.

• Impact Levels represent how important the request is for the customer. Enable the impact levels to be used for service requests, select a default and provide labels (if required) to make them relevant to your business.  
• Urgency Levels relate to how quickly a resolution must be provided. Enable the urgency levels to be used for service requests, select a default and provide labels if needed.   
• Priorities are used to specify the time needed to complete a service request based on its priority. You have the option of providing a label for each enabled priority based on your business terms.
• Priority Model - select a priority for each Impact-Urgency combination. If no combination is defined then it is auto-populated by the system.   

 Cancellation Reasons

Provide the reasons for which a Service Request may be cancelled.

Types

Service request types allow the company to set standard behaviour for common service request flows, and to determine the operational characteristics of service requests. They can be used to log customer requests for information, advice, reporting an incident etc. Multiple service request types should be setup to support your various business needs. Upon creation if a service request the user selects the type which best describes the service request to be logged, and then progresses the service request based on the presets defined for the type. 

Select +New to create a new Service Request Type and provide the following details: 

• Name: The name of the service request type which must be unique. 
• Alternative Code: An alternative code for the service request type which must be unique. The system will provide a code if it's left blank. 
• Used as Default Type: Set to 'on' if this Service Request Type should be the default type (most commonly used). 
• Description: A brief description of the service request type. 
• To be completed within: Estimated time required to complete this type of service request. Provide a number (e.g. 2) and unit of time (e.g. days).
• Recalculate Key dates on Responding: If set to 'on' then the key dates of this type (such as 'To be completed by') will be recalculated upon responding to the request.
• Statuses: The service request statuses which can be used in service requests of this type. At least one status per service request life cycle state should be specified, except for 'Temporary Resolved'. If just one status is provided for each life cycle state then it will automatically become the default status, otherwise one must be selected to be the default status.  
• Status Transition Rules: Define the allowed transitions between the various service request statuses based on a set of conditions that include the initial and destination status value, and the User or Business Unit who is allowed to perform the status transition. 'From Status' is the current status of a service request, 'To Status' is the next status to be set therefore progressing the service request.
• Categories: Select which of the defined categories can be used by this type based on the life cycle state. Multiple categories can be selected for each life cycle state but only one can be the default. If only one is available then it automatically becomes the default.
• Products: Select the specific products or product types that can be handled by this type of service request. If none are specified then all will be available.
• Activity Types: Specify the activity types that could be scheduled through the particular service request. Selecting 'All activity types' denotes that all should be available, alternatively select 'Specific activity types' and specify which ones will be allowed.  
• Cancellation Reasons: The cancellation reasons allowed to be used for service requests of this type. Select 'All Reasons Allowed' or 'Specific Reasons', also select a default cancellation reason. 
• Can be used for creation by: Select the business units (and therefore users) who will be allowed to create service requests of this type.
• Select Save to save the new Service Request type.

Back to top

Setting up Activities

Activities are small tasks or actions that are either stand-alone or must be completed as part of a larger entity, such as a Service Request, a Subscription or a Lead. 

Statuses

Activity statuses determine the progression of an activity during its life cycle state, capturing the time from its creation until its completion or cancellation. Each status is related with an activity's life cycle state which can be one of the following:

• Pending - The activity has been created and is waiting to be assigned to a user or department who will handle it. 
• In Progress -  The activity is under way.   
• Completed - The activity is done.    
• Cancelled - The activity has been cancelled for a reason.  

Label the life cycle states of activities in a way that is meaningful to your organization.  

Categories 

Create the categories that will be available for assigning to activity types, provide meaningful business classifications such as 'Installation', 'Maintenance' etc. based on your business range. These classifications can be created in a hierarchical structure and provide the user with input on how to handle the activity, and can also be used by the business to analyse activity requests. 

Cancellation Reasons

Define the possible reasons for for cancelling an activity and select one as the default. Cancellation reasons can also be used for business analysis.

Types

Types are used to determine the operational characteristics of activities. You can use types to define one-time services (such as the installation of a modem) which can be added as a component to a larger entity and billed based on the duration (the time the installation took). 

Select +New to create a new activity type and complete the following details: 

• Name: The name of the activity type which must be unique.
• Code: A code for the activity type which must be unique. The system will provide a code if it's left blank. 
• To be completed within: Estimated time required to complete this type of activity. Provide a number (e.g. 30) and unit of time (e.g. minutes).
• Description: A brief description of the activity type.
• Statuses: Specify the statuses that are allowed to be used by activities of this type and the default status for each life cycle state.
• Status Transition Rules: Define the allowed transitions between the various activity statuses based on a set of conditions that include the initial and destination status value, and the User or Business Unit who is allowed to perform the status transition. 'From Status' is the current status of an activity, 'To Status' is the next status to be set in order to progress the activity.
• Categories: The activity categories which are allowed to be used for activities of this type, also select one to be the default category. 
• Services: Select 'No services allowed' if no services should be available for this type of activity, otherwise select 'Allowed services' and define the one-time services which can be provided through activities of this type. Services which are marked as 'Automatically applied', will be added in new activities with the specified minimum time spent. These services must first be defined via Finance > Products & Pricing > Manage Products, and must have a Classification of 'Service' and a Service Type of 'One Time' in order to be available for selection.   
• Can be used for creation by: Designate the business units (and therefore users) who will be allowed to create activities of this type.
• Select Save to save the new Activity type.

Back to top

Setting up Leads

Basically, a Lead is an opportunity for additional business. In CRM.COM a Lead consists of a set of processes performed in order to manage a prospect customer, it includes products and services that the customer is interested in, as well as activities and communications performed until the particular customer is won or lost. If a Lead is won it can automatically be converted into a Contact with an Account based on the Lead Type definition. 

Statuses

Statuses are used to represent the life cycle state of a Lead so that it's meaningful to a business. Define the various Lead statuses, mapping each one to a supported life cycle state. On changing the Lead status, the Lead Life Cycle state is updated accordingly thus progressing the Lead. Use New to create a Lead status - provide a Name, Code and Description and the corresponding Life Cycle State which represents the specific status, alternatively, use Edit to change an existing status or Delete to remove a status.  

The supported Lead Life Cycle states are the following:

• Pending - The Lead has been created and is ready to be assigned to a user or department who will take it up.

• In Progress - The Lead is being handled.

• Lost - A Lead is lost when there is no more interest on behalf of the prospect customer. The reason for losing the Lead must be specified.

• Won - Once a Lead is Won, it can be converted into a 'Financial' Contact associated to an Account. This automation is enabled and configured through the Lead Type definition. 

• Cancelled - A Lead is cancelled for any reason.

Categories

Categories are used to provide a business classification for the Lead (e.g. business customer, physical person customer, business partner etc.). Use the +New option to specify the Lead categories that will be available when creating Leads. It's possible to define categories in a hierarchical structure by leaving 'Parent' blank if a category is at the top of a structure. These classifications guide the user in handling the potential customer and can be used by the business to analyse their Leads.

Priorities

The priority level of the Lead helps identify the order in which the Lead should be processed by the users. Use Edit to specify a label for each priority level (1 to 10) based on your business needs.  

Importance 

The importance of a Lead helps identify the effort and the benefit that the company will have if a Lead is won (e.g. High, Medium, Low importance). Use the Edit option to provide a label for each importance level making it more meaningful for your business.  

Source Types

Source types are the possible sources from which the Lead originated. Lead sources are predefined in the system and are not configurable, but they can be overridden with the use of labels. If necessary use the Edit option to enter labels for each source type. The following Lead sources are available: 

• Advertisement
• Notification
• Communication
• Recommended by contact
• Recommended by employee
• Recommended by partner
• Website
• Other
• Custom 1....5   

Lost Reasons

Lost Reasons are the reasons for which a Lead could be lost. Use+New to define the possible lost reasons (e.g. competitors, price, service etc.) which can be used when completing a lost Lead.  

Competitors

Use the +New option to define all possible competitors that could reach a Lead with similar products and/or services. A website and description can also be provided for each competitor.  

Types

In CRM.COM Lead Types are used to determine the operational characteristics of Leads and should be defined to suit the business needs of a company - for example based on the products or services offered. When creating a lead the user will be required to select the Lead Type that best represents the lead to be created.   

Before proceeding to define the Lead Types it's a good idea to consider whether any other entities may also need to be configured for complete functionality.

Select +New to create a new Lead Type and provide the following details: 

• Name: The Lead Type name which must be unique.
• Alternative Code: Provide a code for the lead type, if it's left blank the system will provide one automatically. 
  • To be completed within: How long the processing of the lead is expected to take before it is completed (duration is given in minutes, hours, days, weeks, months and years).
• Priority Level: Select the priority level that leads of such a type should automatically be set to. The levels are pre-defined in the system as explained in the 'Setting Up Leads' procedure above.  
• Importance Level: Select the importance level that should be assigned to Leads of this type. 
• Used as Default Type: Set to 'on' if this Lead Type should be the default lead type (most commonly used). 
• Automatic Lead Conversion: If enabled, then an associated Account will automatically be created when a Lead is won - thus changing the Contact's life cycle state to 'Financial'. Also select the Account classification and the Credit Rating to be used in such cases. 
• Statuses: Select one or more statuses to be mapped to each life cycle state, as well as the default for each one.  
• Status Transition Rules: Status Transition Rules define the allowed transitions between the various Lead statuses based on a set of conditions that include the initial and destination status value, and the User or Business Unit who is allowed to perform the status transition. 'From Status' is the current status of a lead, 'To Status' is the status to be set after the current status (to progress the lead).
• Categories: The Lead categories which are allowed to be used for Leads of this type, also select one to be the default category. 
• Source Types: Select the Source Types to be available for use with this Lead. A default Lead Source Type must also be specified in this section.
• Lost Reasons: Select the allowed Lost Reasons to be used for this Lead type from the drop-down list, also select the default Lost reason.
• Competitors: Select the competitors which can be used for leads of this type, there is also the option of automatically including a competitor on leads. 
• Products: Select 'All Products Allowed' or 'Specific Products' from the 'Allowed Products' drop-down list.  If specific products are required then create a list of products, product types, product brands or product families which can be added as products of interest to Leads of this type. There is also the option to 'Automatically Apply on Lead' if enabled. 
• Activity Types: Select all the possible activity types that could be used by this type of lead to schedule an activity. If none are selected then all activity types will be made available. 
• Can be used for creation by: Select the business units (and consequently users) who will be allowed to create leads of this type.
• Select Save to save the new Lead type.

 Back to top

Managing Leads, Activities and Service Requests

The Customer Care related modules can be handled in a similar manner. 

Navigate to the respective screen and specify the criteria matching the entry you are interested in locating, select Search to find the relevant entries then select Edit to make changes, or simply View to see the information without changing it. To create a  new Lead/Activity/Service Request use the +New option providing the mandatory information on the respective screen. When you are done select Save to save your changes. 

Assigning an entity to a business unit or a user

The Assignment Information section can be used to select the business unit and/or the user responsible for handling the entity. The Business Unit can automatically set based on the geographical area of the contact (if configured accordingly in Configuration > System Settings > Setup Network Settings > Automatic Collaboration Rules). If there is no specific user then the User may be left blank, in which case any user from the defined business unit will be able to Accept the entity, therefore take responsibility for completing the task once it has been created (see below). 

Once the entity has been saved the Assignment Information appears on the right-hand-side of the screen.

Whilst entities that are assigned to a unit and are pending acceptance by a user can be modified, an entity cannot be modified if its cancelled or completed. Once an entity has been created, the related contact name, account and type cannot be changed.

Shared Notes are used to record information regarding the entity. Select Comment, type the note and click on Add to save it. Whenever notes are created the date, time and user name is recorded.

You can Delete entities as long as they are no other entities in the system associated to them. If an entity has been created by mistake, you can Cancel it through Actions > Cancel. An entity can be cancelled as long as it is still in a 'Pending' life cycle state.

Accepting and starting progress of customer care entities

New entities are assigned to a unit or user as defined in the Assignment information section.  A unit member (user) can accept entities assigned to their unit, by clicking on the Accept option in the Assignment Information section on the data entry page. For example, a lead regarding a business client is assigned to the B2B Marketing Department and then accepted by a specific user. Before an entity can be progressed it must be assigned to a specific user and not just a unit. When you edit an entity you also have the option of assigning it to a specific user as during creation stage. 

Once an entity has been assigned to a user it must be progressed to start its processing. For Activities and Leads click on Start Progress (from the 'Activity Progress' or 'Lead Progress' section) and select one of the available statuses that represents an 'In Progress' life cycle state.  The action will change the state from 'Pending' to 'In Progress'. Use Edit to amend the entity if necessary. To complete the entity select 'Complete' for an activity and 'Won' or 'Lost' for a lead. 

The next step is to provide a solution to the issue; either a temporary or a final solution. This is possible by clicking on the 'Temporary Resolved' or 'Final Resolved' in the 'Response and Resolution' section. Providing a temporary resolution is optional; service request types can be set up to skip this state. Once the issues have been resolved and accepted by the customer then the request can be 'Completed'. In order to complete a request any planned activities must also be either completed, deleted or cancelled.

It's also possible to update values set for a state through 'Manage Response/Resolution' option as long as the entity has not progressed to the next state.

Communicating customer care entities

Communications can be sent to customers directly from the screen of any customer care entity by using Actions > Communicate...

Alternatively, the user-customer interaction can be automated through the use of communications as the entity progresses through each stage . For example, in service requests:

• A 'Communication' can be created when the entity is set to 'Responded' state, providing that the 'Event Based Communication Definition' is configured accordingly.
  

• Customers can automatically accept responses and resolutions through email/SMS links. Once the customer clicks the respective link, the response/resolution of a service request is set as 'Accepted by Contact'.

You can use tags (text that is automatically replaced by values relevant to customer details) when creating communications related to any customer care entity. Tags are available for selection by typing '#'. Refer to the Communications manual for further information and a complete list of available tags.

Using Key Dates in customer care entities

Set the dates and time frames which are relevant to your entity. The set of dates includes: 'Start Date', 'Expected Completion Date', 'Actual Completion Date', 'Time to Completion', 'Estimated Completion Time' and 'Time Overdue'. (need to check these are correct).

It's possible to set the time within which an entity must be completed (To be completed within) through the entity Type.

Enabling 'Recalculate key dates on responding' will recalculate all the dates upon receiving a response to a service request. 

Using Products in customer care entities

Most commonly customer care modules are used to handle tasks, questions or issues associated to physical goods or services. The system can be set up with various entity types in order to handle issues with different products. The list of products that each entity can handle depends on the 'Products' added on the entity type; i.e. activity type, service request type, lead type.  

Scheduling activities for service request and leads  

The Actions menu options are:

• Communicate Lead/Activity/Service Request.
• Schedule an Activity (except for Activity entity).
• Cancel.
• View History.

Lead Specific Processes 

Processing a Lead

Use the 'Lead Progress' section on the right-hand-side of the screen to progress the Lead to the next stage. At the end of it's life cycle a Lead can result in a 'Won or 'Lost' status, this is done by selecting the respective 'Won' or 'Lost' action. If the lead has been 'Won' then select the appropriate status, i.e. one which represents a 'Won' life cycle state from the drop-down list. If a Lead has been 'Lost' then select the reason for losing the lead from the available options, and also set the new status to one representing 'Lost'. In either case select Save to complete the process.  

If the Lead status has been set to 'Won' and the auto-conversion process is enabled for the Lead Type, then an Account will automatically be created (based on configuration) and associated to the Contact which will now have a 'Financial' life cycle state. Once converted, the Contact can purchase products and/or services. 

Importing Leads

The fastest way to create leads is by importing an Excel or CSV file, to do so please refer to the Appendix A and the Utilities section in the Foundation manual.  

Back to top 

Activity Specific Processes

Booking resources to complete an activity service 

Activities consist of tasks that must be completed by a designated user. The resources necessary to complete a task can be booked through CRM.COM Resource Scheduling entity by supplying the service to be provided, the responsible department/unit and the date/time on which the task should be completed. Services that are necessary to complete an activity can be defined as 'mandatory' on the activity type and added automatically.

Resources can be requested when adding a service for an activity through the 'Services to be Provided' section. Clicking the Request Resource link opens the Resource Availability modal, allowing you to search available resources and place a request. Refer to Resource Scheduling for more information.

Service Request Specific Processes

Service Request management dashboards

The Service Requests management dashboard tool allows managers, team leaders, and ordinary users to easily handle and keep track of the service requests that must be addressed. The dashboard is readily available through the Service Request Summary screen.

Relating service requests to other service requests

Service requests can be related to similar or relevant service requests by the same contact and managed through the Related Work section available on the service request data entry page.

Customer feedback

It is possible for customers to rate your company's services (in this case service requests) by providing a rating as well as comments. Both rating and feedback are only possible through the WEB API.

The provided feedback can be viewed through the Feedback summary page available under Foundation > Analytics.

Back to top