Version Control

Reference Documents

1. Functional Process

 Process Overview

2. Data Model & security

Main objects

1. Case: Standard Salesforce Object to store and manage all general information regarding a Customer Request
2. Accounts: Standard Salesforce Object to manage the information about the Customer related with the Customer Request
3. Contacts:  Standard Salesforce Object to manage the contact person from the Customer
4. Case Team: Standard Salesforce Object to manage all the actors related to the Customer Request Process and to manage access to the Case
5. Products: Standard Salesforce Object to manage the Product Level 3 that is related to the Customer Request

Customer Request Security Model

3. Customer Request Custom Buttons & Features

Custom Buttons

"Send Final Communication" Button

In the Processing phase, the User responsible for the communication to the Customer must send Communication Email to the Client with the Proposed Customer Response. The user can send the email by clicking on the “Send Final Communication” button. In addition to the predefined Contact, the user can also input any valid email address as CC, select the Language of the Template, and select the Attachments the User wants to send to the Client. 

"Clone Customer Request" Button

At any phase of the Customer Request Process, Users are able to Clone Customer Requests to save time on the registration phase. This will open a new Customer Request form already populated with the information from the initial Request.

Features

Customer Request Assignments 

Assigning a Customer Request to a User or a Group of User is to pass the responsibility to act on the Customer Request on a particular phase of the process. On Salesforce, the Customer Request Assignment is based on the field Case Owner.

A Case Owner can be a User (Solvay employee with a Salesforce license) or a Queue (a group of Users that should be part of a team to handle Customer Requests with the same criteria).

Based on each GBU own process and rules, the Customer Request Assignment can be performed by:

• Manually changing the Owner – at any time, a User with Access to a Customer Request can click the button Change next to the current owner and select a new User/Queue to be the new Owner
• Manually choosing the actors – on the creation (from the fields Originator, Investigator* and Commercial Assignee*) or at any time (from the Case Team section) Users are able to select the future actors. The Owner will be changed then automatically based the change of the Status
• Automatically selecting the actors – the GBU has provided the rules, based on Customer Request criteria, to allow the system to automatically change the Ownership of a Customer Request to a specific User or a Queue when the Status changes

The Customer Request Actors are managed on the Case Team section on the Customer Request Layout page. The Users are added to the Case Team i) manually by a User or ii) automatically by the System when they are the new Owners of a Customer Request. When the Users are added automatically to the Case Team, they are added with the correct Role based on the current Customer Request Management Phase. 

Customer Request Approval Process

After the registration phase is completed by the User and all the information related to the Customer Request is provided (General Information, Description, Accounts and Contacts, and Attachments), the Customer Request must be manually submitted by the User to be approved by clicking on the ‘Submit for Approval’ button. Based on System Rules and GBU Rules, a Customer Request can be:

• automatically approved - the Status will be automatically changed to Approved and the Customer Request will be assigned to the User or Group of Users responsible for the Processing
• assigned to be approved - the Status is changed to Pending Approved and the User or Group of Users responsible for approving the Customer Request will be notified.

During the approval process, the customer request will be frozen until it is “Approved” or “Rejected”.

If additional information is needed before the approval of the customer request, it can be recalled with a comment “Additional Information Required". Once the information has been delivered, the request can be submitted for approval again. 

Customer Request Notifications

On each step of the Customer Request Management Process, a set of Solvay personalities (Salesforce or not Salesforce Users) needs to be notified that a new Customer Request has now moved to a specific Status in order to act (Customer Request Owners) or to be informed.

On each Status change, an email is sent from Salesforce to a group of users, based on System Rules and GBU Rules that should be stored and displayed in the Activity History Section of a Customer Request. There are four types of Addresses on the Customer Request Notification Email when the Status is changed:

• The new Owner – if your GBU has implemented assignment rules and the owner has changed automatically to a specific User or to a Queue, the new Owners will receive the Notification Email.
• The previous Owner (if not a Queue) – normally the previous owner is the User that changed the Status and triggered the notification. He/she will be also notified  to ensure that the correct Owner has been assigned
• The Case Team – all Case Team Members, independent of their Role will receive the Notification Email
• Solvay Contacts on Notification Rules – group of contacts (not necessary Salesforce Users) that are selected to be notified when the Status is changed based on each GBU Rules.

4. Specific Rules & Automation

Configuration of the process for the estimated resolution date (v3)

The configuration is done in the custom meta data type : CR Resolution date Warning

For instance

• If there is no line of a GBU, the estimated resolution date is calculated by the Code and there is no alert and the warning is displayed if Estimated Resolution date > Requested Resolution date
• If the GBU segmentation is blank , the Configuration will be applied  for all GBU customer segmentation
• If the CR Case Type is blank, the Configuration will be applied  for all CR Case Type

Color Coding

Display when the estimated resolution date > current date

Display when the estimated resolution date < current date

Customer Request Registration

In order to create a new customer request, on the Case tab, the user needs to click on the “New” button, select the customer request record type and click on “Continue”. Additionally, customer requests can be found in a related list on the Account page from which the user can see all existing customer requests for this Account as well as creating a new one. When creating a customer request from this related list on the Account page, the record type is by default “Customer Request” and the Account is automatically populated in the Account Name field.

When the user creates a Customer Request, he/she has the ability to register the following information: 

Case Information 

Customer Contact Information

Multiple contacts can be maintained on the Customer Request. The main Contact can be maintained under the Customer Contact Information section and additional Contacts can be maintained in the Case Customer Contacts related list.

The main Contact on the customer request is by default recipient of the communication to the customer. The recipients can nevertheless be changed by the user.

Description

In this section, the initial description of the Customer Request is captured

As detailed in the Approval Process section above, users must at all times submit manually a Customer Request for approval after all the relevant information is provided regarding the Customer Request. When an approval is requested by the GBU the status is changed to Pending Approval and the User or Group of Users responsibel for the approval are notified. When the Customer Request is approved, the status is changed to Approved.

Process the Customer Request

Once the Customer Request is approved, the Users or group of Users responsible for processing it are notified to act on the Case. The Users will provide a description of what was done and processed on this Customer Request that should then be communicated to the Customer.

Customer Response

Detailing the Response that should be sent to the Customer.

Customer Communication

In order to send the final communication to the customer, there is a button “Send Final Communication” that when pushed will open the template of the final communication email which can be previewed and is editable. 

By default, the email of the main Contact assigned to the customer request will automatically be populated in the recipient's fields. It is possible to add any other email address to the list or in CC.

Basic information on the customer request is available in the template but it remains fully editable. Once the answer to the customer is ready, the user can send the email.

The customer request template is available in the following 16 languages (including simplified Chinese and traditional Chinese):

Furthermore, the language of the main Contact is used to determine the language in which the email template will be generated. In case no language is assigned to the main Contact, the default language of the communication is set to English. The user can always change the language by choosing another one in the dropdown list if needed. Attachments on the customer request can be attached to the final communication email to the customer.

Customer Request Closure

Any User assigned to the case team can close the customer request by clicking on the “Close” button. This redirects the User to the closure page where a “Comments” fields can be populated prior to closing the Customer Request. When closing a Customer Request, the status will be default Close/Answered, meaning that the Customer Request was completed and the Customer received a communication. If the customer request was Rejected or has not completed the process, the Status can be changed to Closed/Stopped. 

Close Case

This section groups all the fields related to the Closure phase

The best way to get IT support is to use the new Service One Platform.