CRM User Guide

CRM User Guide
CRM User Guide- Release R13.00 -Page 2 of 178 - (c) Temenos Systems 2013 05/07/2013
Introduction
Overview:
Customer Relationship Management in short CRM is a methodology used to learn about Customers' needs and behaviours in order to develop
stronger relationships with them. It brings many pieces of information about Customers, sales, marketing effectiveness, responsiveness and
market trends. It involves all aspects of interaction that a Bank has with its Customer, whether it is sales or service related.
Earlier in T24, when a front office staff had to deal with a Customer, they would either launch the enquiries CUSTOMER.POSITION and CUS-
TOMER.POSITION.SUMMARY or launch a customised enquiry. While these enquiries would show only the balances of accounts and con-
tracts, they did not enable the front office staff to know the latest transactions the customer had with the Bank. Gone are the days when the
client had to come to the branch to do business, now they can simply get on-line or phone the call centre. Shopping around for banking serv-
ices and has never been easier.
T24 Customer Relationship Management is aimed at client-bank relationship. The module aims at bringing all customer information relating to
products used, accounts, personal details, contact details and campaigns together. Since customers can now interact with the bank through
multiple channels, the ability to provide the above information across all channels is critical.
T24 CRM enables a Bank to provide better Customer service, discover new Customers, cross sell or up sell products more effectively and
increase Customer revenues. It also helps sales staff to close deals faster, improves efficiency of call centres and simplifies marketing and sales
processes.
Let us take an example to understand the use of T24 CRM module to Banks. Assume that the bank has introduced a new type of short-term
loan product. The bank wishes to campaign and eventually sell this product to its existing Customers.
The eligibility conditions for the new loan product are retail Customers, who hold a savings account in any currency with the Bank and with a
minimum balance of 5000.
How can a bank use T24 CRM module to campaign for this new product?
The CRM module in T24 will help the Bank to define a set of criteria to select Customers to whom it plans to sell its new product. Once Cus-
tomers are identified, the bank can initiate a workflow to sell the product to the identified Customers. This workflow can be constructed using
the Process Workflow (PW) module in T24. CRM also enables a Bank to provide probability scores. It means, once a set of Customers qualify
for a campaign, the Bank can predict the probability of certain Customers availing of the loan is higher than that of others.
CRM is broadly classified into two, they are:
• Analytical CRM
• Operational CRM
CRM Configuration:
We will now see how to configure CRM.
On receipt of the product code it must be entered into the SYSTEM.PARAMETER.FILE(SPF) application. This application contains only one
record named SYSTEM.
The product must then be included in all the COMPANY records, that must be configured for CRM
Auto ID has to be setup for a few applications which are a part of the CR module.
Customer Profiling Configuration:
Profiling is used to group customers of similar profile. It automatically populates the field CR.PROFILE.TYPE and CR.PROFILE with appro-
priate values. These are two NO.INPUT fields in the CUSTOMER application.
There are 3 applications which are involved in this process, they are as follows:
CR.PROFILE.TYPE
CR.PROFILE
PW.TRANSITION
CR.PROFILE.TYPE
Customers are classified into different groups using CR.PROFILE.TYPE application, when they satisfy specific criteria. This enables the bank
to easily sell products to them, as well as group the customers accordingly.
CR.PROFILE.TYPE defines different types of profiles. This application contains the broad classification of customers based on CATEGORY,
SECTOR etc. The application contains a field called Description that holds the description. No real business logic. For e.g.: Home Owners.
CR.PROFILE
CR.PROFILE provides the condition based on which a customer would fit into a category in CR.PROFILE.TYPE.
A customer can be grouped under more than one category also.
In the following example a profile APTMENT.OWNER is created with an associated rule. The rule will be used to evaluate if the client fits into
the profile.
PW.TRANSITION
Rules or criteria for CR.PROFILE are setup using an application called PW.TRANSITION (refer: Process Workflow user guide for detailed infor-
mation)
After the set up, when a CUSTOMER record is created, with the RESIDENCE.TYPE field as ‘RESIDENTIAL.APT’ the CR.PROFILE.TYPE and
CR.PROFILE fields are updated accordingly as shown in the screenshot below.
It is possible to do automatic profiling using an online service called CR.PROCESSING.
We can also prevent profiling for a customer by setting the field NO.UPDATE.CRM of CUSTOMER application to YES.
Single Customer View (SCV)
In CRM, SCV stands for Single Customer View or 360-degree Customer view. The Front Office staff will launch this view, whenever a Customer
contacts the Bank. This view helps to get the complete information about a Customer such as latest transactions, Accounts and contracts
status, future financial events, result of campaigns, etc.
Single Customer View can be launched either using the enquiry CUSTOMER.DETAILS or by navigating through the menu - User Menu > Cus-
tomer > Enquiries > Customer Details
The following screen shot shows the single Customer View for the customer
This Single Customer View contains many logical tabs. We’ll discuss about each of them as we move on.
The first Tab is the ‘CUSTOMER’ Tab it contains General Information about the customer. This tab contains the customer’s photo, customer’s
signature, information about the contacts the customer has had with the bank, i.e. though email , appointments etc.
This tab has three sub tabs namely Active Process, Contacts and Opportunities. The Active Process and Opportunities tab are explained in the
Campaign Processing User Guide. The contacts sub tab contains information on the interactions the customer has had with the bank.
Creating a contact for the customer
A Customer contact is created using the application CR.CONTACT.LOG. It stores information on all the interactions which the customer has
had with the bank.
CR.CONTACT.LOG
An entry in the CR.CONTACT.LOG file can be created manually or automatically. Based on the customer’s request, a date and time for the meet-
ing is fixed and an appropriate person is assigned. Please note that this contact date need not necessarily be TODAY. It can be any future date.
By this means, we actually book appointments with the customer.
Contact Type and Contact Status fields have pre-defined set of values and are available as a drop down that you can choose from.
Contact Staff field can contain any valid T24 user name.
Contact Channel field can contain the ID of any record from the EB.CHANNEL application.
Contact Direction field signifies whether the contact was initiated by the bank (Outward) or the customer initiated the contact (Inward).
When an entry is created in the CR.CONTACT.LOG file, 2 LIVE files get updated based on the ‘Contact Date’ of the entry. If Contact Date is the
current day, then, an entry in the application CR.CONTACT.LOG.HIST is created. If Contact Date is a future date, then, an entry in the appli-
cation CR.CONTACT.LOG.FUTR is created.
CR.CONTACT.LOG.HIST
The CR.CONTACT.LOG.HIST shows the interactions the customer has had with the bank and the corresponding date and time of the contact.
The number of contacts stored in this application depends on an application called CR.CONTACT.LOG.PARAM.
CR.CONTACT.LOG.PARAM
The CR.CONTACT.LOG.PARAM is a parameter file; here we define what activities of a customer need to be logged.
This application can have various types of IDs. They are:
SYSTEM
Valid T24 application name (Example : FUNDS.TRANSFER)
Valid T24 version name (Example : FUNDS.TRANSFER,TRG)
When the record ID is SYSTEM. It has only one inputtable field - MAX.HIS.INDEX.
The field MAX.HIS.INDEX here is set to 3. So only the last three contacts that the customer has had with the bank will be stored in CR.CO-
NTACT.LOG.HIST. When there are more than three contacts for a customer, then, the oldest one gets wiped out and the new one is recorded.
When an entry is removed from CR.CONTACT.LOG.HIST, the corresponding record in CR.CONTACT.LOG is also removed (deleted).
If this field is left blank, the default value is 15, i.e. the last 15 contacts which the customer has had with the bank will be stored in CR.CO-
NTACT.LOG.HIST.
In the following example, we see a record with ID that is a valid T24 application or a version name.
As you can see above, a record with the ID FUNDS.TRANSFER has been created. Within the record, we specify the name of the field in the
FUNDS.TRANSFER application that holds the customer number (See field Customer Field.1) and set the field ‘Update Log’ to Yes. This means
whenever a record is input using the FUNDS.TRANSFER application, an entry (contact log) has to be created in CR.CONTACT.LOG appli-
cation for the customer specified in the DEBIT.CUSTOMER field in the FUNDS.TRANSFER application.
If the field ‘Update Log’ is set to NO, then no contact entry will be created in the CR.CONTACT.LOG file. You may choose to set the field
‘Update Log’ to a ‘No’, when we want to create records for future use.
When a record with a valid T24 application name or a version name is created in the CR.CONTACT.LOG.PARAM application, it denotes that
when these applications/versions are used, a contact log for the customer will be created in CR.CONTACT.LOG application.
The contact that was created will be updated in the SCV as shown in the below screen shot.
The second Tab is the ‘BASIC DETAILS’ Tab it contains the details of the customer like name, date of birth, marital status etc. Click on the
Amend Basic Details icon to edit the details if needed.
The third Tab is the ‘ADDRESS’ Tab it contains the address of the customer. We can edit the details if needed.
The ‘RELATIONSHIP’ Tab displays the details, if any, of the customer with another customer in the bank.
The fifth Tab is the ‘EMPLOYMENT’ Tab it displays the employment details of the customer if any. Employment details can also be edited if
required
The sixth Tab is the ‘FINANCIALS’ Tab it displays the financial details of the customer. We can edit the details if needed.
The seventh Tab is the ‘DOCUMENTS’ Tab it displays the details of the documents submitted by the customer.
The eighth Tab is the ‘DELIVERY PREFERENCES’ Tab it displays the details of the delivery preferences for the customer if any.
Prospect Management
Prospective customers are the ones who are not yet a customer of the bank, but may become a customer in the near future.
The CUSTOMER.TYPE field in the CUSTOMER application enables the differentiation between customers who are active and have business
relationship with the bank and Prospective Customers. Valid values are PROSPECT and ACTIVE.
The value of this field, if left blank, will mean that the customer is an active customer and hence after authorization of the record, value cannot
be changed to PROSPECT.
If the customer forms a business relationship with the bank then CUSTOMER.TYPE will be changed to ACTIVE and after this, the customer
record cannot be deleted
If PROSPECT is entered and if the customer does not form a business relationship with the bank, such as opening an account, limit or con-
tract then after a period of time defined on the CUST.RETENTION field on COMPANY, the customer record and all associated data will be
removed from the system by the CUSTOMER.PURGE process during Close of Business.
A customer can have the Customer.Type set to ACTIVE by any one of the following activities:
• A prospective customer record is manually modified to activate the customer.
• The Customer forms a business relationship with the bank such as opening an account, limit or contract
It is not possible to reverse an ACTIVE customer record, however a PROSPECT customer record can be reversed, in fact all data relating to
that customer will be removed.
Prospect Management Configuration:
The following files need to be set up to enable the process of Prospect Management
COMPANY – used to define the default setup
CR.CONTACT.LOG.PARAM – Records created application can be used to override the defaults specified in the COMPANY application
CUSTOMER – the field Customer.Type is used to denote whether the customer is a PROSPECT Or ACTIVE customer
Settings in COMPANY record
The above company has been set up to retain a Prospective Customer for 180 days without any contacts, after which all data for the pro-
spective customer will be deleted.
The Cust.Retention input may only be nnD or nnM where nn is a positive number, D is Days and M is Months.
The retention period is determined using the last contact date for prospective customers on its CR.CONTACT.LOG record. If it is not set up
then the AUDIT.DATE.TIME on the customer record is used.
Example: 1
Settings in CR.CONTACT.LOG.PARAM for ACCOUNT application
The ID of a record in the CR.COBTACT.LOG.PARAM application is any valid T24 application with or without a version.
CR.CONTACT.LOG.PARAM record for ACCOUNT application
The above setting allows the creation of a new ACCOUNT record for a PROSPECT Customer. When an account is created for the PROSPECT
customer, the CUSTOMER.TYPE filed will automatically change to ACTIVE.
Prospect Customer
A prospect customer is created as shown above.
Account Record
An account is opened for the above created prospect customer.
Customer Record after Account Input
After an Account has been input for the Prospect customer, the Customer has now become an ‘ACTIVE’ customer as shown in the above
screenshot.
Example: 2
Settings in CR.CONTACT.LOG.PARAM for ACCOUNT application
If the Prospect.Allow field in CR.CONTACT.LOG.PARAM is set to NO, then the system doesn’t allow Account to be created for PROSPECT
customer
New Prospect Customer
A prospect customer is created as shown above.
Creating New Account Record for PROSPECT customer
As we can see here the system doesn’t allow input of new account for the Prospect customer, since the Prospect Allowed is set to ‘No’, in
CR.CONTACT.LOG.PARAM.
CUSTOMER.PROSPECT LIVE File
Customer Prospect Record
Prospect Customers are stored in the Live file CUSTOMER.PROSPECT. Once a Customer becomes Active, it is deleted from this Live file.
Product Overview
Throughout the past 15 years high levels of transaction automation have been achieved within the financial services industry through the use of
integrated banking packages such as TEMENOS T24. These efforts have largely been directed at “back office” transactions with the result that
this area has now become highly automated. With the introduction of multi channel banking, banks are having to differentiate themselves not
only on the products and services that they are able to provide though the investments that they have made in back office automation but
increasingly in the way that they are able to interact with the client. The client now owns the client-bank relationship and is able to dictate how
they will interact with the bank. Gone are the days when the client had to come to the branch to do business, now they can simply get on-line
or phone the call centre. Shopping around for banking services and has never been easier.
Consequently, banks are having to try harder to retain their existing clients, increase ‘wallet share’ and to attract new clients. Every contact
with the client be it in the bank, via a call centre, at an ATM or on the web needs to be treated as an opportunity to retain and cross or up sell
the client.
The role of technology in this environment is critical. When the client contacts the bank they expect to receive the same levels of service and
access to information across all channels. The customer experience must be consistent throughout and information must be accurate and
updated in real time. Any bank employee who may come into contact with a client needs to be sales aware and have access to the necessary
information about the client, his recent activities, long term goals as well as the products and services that the bank is able to offer.
The concept of CRMsystems has been around for a long time and it is now more relevant than ever. T24 has a module called CR to take care of
Customer Management with the bank. It also has components like KYC and AML which can be used for Risk and compliance management.
T24 Customer Relationship Management is aimed at client-bank relationship. The module aims at bringing all customer information relating
to products used, accounts, personal details, contact details and campaigns together. Since customers can now interact with the bank through
multiple channels, the ability to provide the above information across all channels is critical. A lot of times a client may interact with the sys-
tem while sometimes it might be with a bank agent or staff. A distinction between the two should be indicated.
The application shows the following information which is held together in various tables
Client Static Data – Name, profile, goal etc.
Client Products - All financial products for the clients with the bank including recently matured products and current applications.
Client History - A history of all interactions with the bank including recent transactions, mail sent and received, all attempts to sell to the
client and all visits to the bank, website, call centre, ATMs etc
Future Client Events – All scheduled transactions and mailings, which includes payments like mortgage coming up etc.
Potential Client Sales – Suggestions based on rules based analysis of client and related history and profile as to what additional products
and services which can be sold to the customer. All campaigns will be highlighted.
Setup
Installation Of Product
On receipt of the product code this must be entered into the SPF file called SYSTEM.
SPF
Product codes in the SPF
The product must then be included in the COMPANY records as required.
Company
Sample SPF screenshot
AUTO.ID.SETUP
Auto ID has to be setup for the 3 applications mentioned above in the COMPANY screenshot. A sample is shown below.
AUTO.ID.START
Sequencing for different tables are shown below
CR.CAMPAIGN.OPPORTUNITY – ‘CRCO’YYJJJnnnnn where YY=Year, JJJ=Julian Date and nnnnn=sequence number
CR.CONTACT.LOG - ‘CR’YYJJnnnnn
CR.OTHER.PRODUCTS – ‘CROP’YYJJnnnnn
Customer
Customer template has been updated to incorporate new fields required for CRM. The fields are shown below with more information available
in the CUSTOMER user guide.
The details of the fields added to CUSTOMER are as below
Field Name Type Description

XX<PROFILE.TYPE 35,A Linked to PROFILE.TYPE table
NOINPUT
XX>PROFILE 35,A Linked to PROFILE table
NOINPUT
TITLE 6 Can have any of these values
MR_MRS_MS_MISS_DR_REV
GIVEN.NAMES 50, A Name of the customer
FAMILY.NAME 50, A Family name of the customer
GENDER 6, A MALE_FEMALE
DATE.OF.BIRTH 11, D
MARITAL.STATUS 11 Linked to the virtual table MARITAL.STATUS in EB.LOOKUP
NO.OF.DEPENDENTS 2
PHONE.1 17, ANY
SMS.1 17, ANY
EMAIL.1 35, ANY
XX<EMPLOYMENT.STATUS Linked to the virtual table EMPLOYMENT.STATUS in EB.LOOKUP
XX-OCCUPATION 35, A
XX-EMPLOYERS.NAME 35, A
XX-EMPLOYERS.ADD 35, A
XX-EMPLOYERS.BUSS 35, A
XX-EMPLOYMENT.START 11, D
XX-CUSTOMER.CURRENCY 3, CCY
XX-SALARY 10
XX-ANNUAL.BONUS 10
XX>SALARY.DATE.FREQ 17, FQU
NET.MONTHLY.IN 10
NET.MONTHLY.OUT 10
XX<RESIDENCE.STATUS 35 Linked to the virtual table RESIDENCE.STATUS in EB.LOOKUP
XX-RESIDENCE.TYPE 11, A
XX-RESIDENCE.SINCE 11, D
XX-RESIDENCE.VALUE 11
XX>MORTGAGE.AMT 11
XX<OTHER.FIN.REL 3 Linked to RELATION
XX>OTHER.FIN.INST 35
XX<COMM.TYPE 35
XX>PREF.CHANNEL 11, A Linked to EB.CHANNEL
XX<CR.CAMPAIGN.ID 35
XX>CR.OPPOR.ID 35
XX.INTERESTS 35, A
FAX.1 17
SECURITY.PASSWORD 35
XX<SECURITY.QUEST 35
XX>SECURITY.ANS 35
XX<PREVIOUS.NAME 35
XX-CHANGE.DATE 11
XX>CHANGE.REASON 35
CUSTOMER.SINCE 11
XX.RESERVED04 35, A Added for future use
to NOINPUT
XX.RESERVED01
CUSTOMER TABLE CR.PROFILE
CONT.
Customer profiles are updated by two ways.
Customer creation or updating: Whenever a customer record is created or updated that “CUSTOMER” is profiled to a group. Customer tem-
plate contains 2 fields called CR.PROFILE.TYPE and CR.PROFILE which are updated with the group. These fields are multi-value fields. Hence
a customer can be part of more than one group. (Screenshots above).
Service : A new TSA.SERVICE has been created called CR.PROCESSING which will update the customer record with a group assigned to him.
TSA SERVICE RECORD FOR CRM
CR.PROFILE.TYPE
Customers are classified into different groups via CR.PROFILE.TYPE table when satisfying specific criteria. This enables the bank to easily sell
products to them as well as group the customers accordingly.
CR.PROFILE.TYPE defines the different types of profiles.
CR.PROFILE.TYPE TABLE
CR.PROFILE
CR.PROFILE provides the condition based on which a customer would fall into a category in CR.PROFILE.TYPE.
A customer can be grouped under more than one category too.
In the below mentioned example A profile STUDENT is created with a rule associated with it.
CR.PROFILE TABLE
Screenshot of the rule is given below as part of PW.TRANSITION.
PW.TR A N STION
Rules for CR.PROFILE’ s are setup through an application called PW.TRANSITION (refer : Process Workflow user guide)
PW.TRANSITION RULE
CUSTOMER RECORD DISPLAYING NEW FIELDS
CONT.
Flow To Setup Customer Profile
When a customer is created, the PW.TRANSTION rule is checked for condition first. If customer satisfies the rule, a profile is associated with
the customer based on the CR.PROFILE which is linked to the PW.TRANSITION rule.
Updates To DE.ADDRESS
A few fields have been updated in DE.ADDRESS reflecting the contact details for a customer
DE.ADDRESS
The fields added are
1. Phone –Contains the telephone number of the customer.

2. SMS – Contains the mobile number of customer which can be used to send a sms messages.
3. Email – Holds the email address of customer through which a message can be mailed.
Customer Single View

Customer single view is the central information view of necessary customer data. The single window is a split up of
1. Customer Information – Basic static information of the customer.

2. Products held by customer information
* Products which are not held within the bank are recorded in a table called CR.OTHER.PRODUCT.
3. Customer Activity - All activities which have happened and will happen in future for the customer are displayed. This includes pay-
ments made and to be made.
4. Campaign and Opportunities – Information regarding the different campaigns sent out to the customer along with the response
received for the same.
A customer can amend data through the customer single window.
SINGLE CUSTOMER VIEW
BROWSER.PREFERENCES
CRM users have to have access to only the above mentioned window. To setup, create a record for the required user in BROWSER.PRE-
FERENCES indicating the main screen as CRM.START
BROWSER.PREFERENCES
Login Screen For A CRM User Is As Below

Selecting a customer can be done using any of the fields shown below.
MAIN SCREEN FOR CRM USER
A user can only access the customer single window. This user is specifically a CRM user and hence has no access to other areas of T24.
Customer Contact Information

Whenever a customer contacts the bank (be it for query or instruction), a log is created showing the history of the contact
The following tables are used for logging the information.
C R .C ON TA C T.LOG.PA R A M
A parameter table which holds information on which field should be the tracking field for a customer in any application. These records are then
recorded in CR.CONTACT.LOG. The screenshots below explain more.
A base record called SYSTEM is created to record how many transaction histories are to be held.
* The following example shows the max history to be 3.
Other than SYSTEM record, any application (with or without version) can be given as ID
Since customers are tracked with a customer number or account number (or both), we specify the same in parameter record. An example is
shown below.
Note: Though validation against the fields is done for the application, user has to make sure the correct customer and account fields are given.
Example
Let us track a mortgage for a customer
MORTGAGE RECORD FOR TRACKING CONTRACT LOG
We have given the mortgage tracking fields in CR.CONTACT.LOG.PARAM as given above.
CR.CONTACT.LOG FROM MORTGAGE RECORD
A manual entry done directly in CR.CONTACT.LOG table is shown below.
MANUAL UPDATE OF CR.CONTACT.LOG
C R .OTH ER .PR OD U C TS
Sometimes banks wish to record information regarding customers assets/liabilities held outside the bank. They can be recorded in an appli-
cation called CR.OTHER.PRODUCTS. This is an information only application and does not have any financial implication with T24.
This record is populated manually and CRM shows the information with regards to other products in the product window of the CUSTOMER
single view.
CR.OTHER.PRODUCTS
C R .C ON TA C T.LOG.FU TR a nd C R .C ON TA C T.LOG.H IST

There are two contact files named CR.CONTACT.LOG.FUTR and CR.CONTACT.LOG.HIST both of which holds CR.CONTACT.LOG table
information for a customer based on whether they are past or future events. Both these tables are updated when CR.CONTACT.LOG is updated
with a new record or an existing record is updated.
C R .C ON TA C T.LOG.FU TR
The example shows various Logs which are future events.
CR.CONTACT.LOG.FUTR
C R .C ON TA C T.LOG.H IST
CR.CONTACT.LOG.HIST
C A MPA IGN a nd OPPOR TU N ITY

A campaign is a event/publicity/contact held by the bank for its customer for the following purposes.
l A product announcement
l Targeting specific type of customers (based on income, location etc).
C R .C A MPA IGN .D EFIN ITION S

Before a bank selects customers to send a campaign too, a definition of the campaign has to be created.
CR.CAMPAIGN.DEFINITION records actual definition of the campaign. The record would be created with “CAMPAIGN.STATUS” as new. The
record should be verified after which it moves to pending status.
To build list of customers who become part of the campaign, the service “CR.PROCESSING” is to be verified.
Example : The below shown screenshot defines a car loan campaign being run for Students running from 30 th Nov to 4th Dec. The record cam-
paign status should contain New status
CAMPAIGN DEFINITION
TSA.SERVICE FOR CRM
*Note: Company Mnemonic will vary according to each bank’s setup.
Once the TSA.SERVICE is completed the record moves to ‘Launched’ status
CAMPAIGN DEFINITON SHOWING STATUS
The TSA.SERVICE also builds a list of opportunity records as explained below.
C R .C A MPA IGN .OPPOR TU N ITY

Once a campaign is defined and a list of customer’s is built, an opportunity table records the history of each of the targeted customer.
OPPORTUNITY RECORDS CREATED FROM CAMPAIGN
All the opportunity records will initially be in New status, once the bank receives a feedback from the customer, the status is moved by a cus-
tomer servicing executive.
CR.CAMPAIGN.OPPORTUNITY RECORD
A process is created for each customer to send out the information through the delivery channel mentioned.
Prospect Management
The Customer Type on the CUSTOMER table enables the differentiation between customers who are actively doing business with the bank
and Prospective Customers.
A customer with a Customer.Type of PROSPECT is only allowed a period of time (Cust.Retention) to be on the system, after which the pro-
spective customer information is removed by the Customer Purge process in the Close of Business.
A customer can have its Customer.Type set to ACTIVE by any one of the following activities and once Active cannot be reversed.
A prospective customer record is manually modified to activate the customer.
An unauthorised transaction is entered for a customer, for example an account or a limit is opened for a customer, or a customer takes out a
loan without having an account or limit with the bank.
The system defaults for allowing input of prospective customers are as follows: -
The default is YES for fields that do a direct check on the CUSTOMER table, i.e. they have SYS.REL.FILE (CHECKFILE) defined as CUS-
TOMER on the relevant STANDARD.SELECTION record.
The default is NO for fields that can either optionally consist of a customer code or free text, or fields that contain a customer code as a com-
ponent of the field.
However the system defaults can be overridden using the application CR.CONTACT.LOG.PARAM. For example Limit where the customer code
is the first part of the key delimited by ‘.’ can be set to YES to allow input for prospective customers, whereas CUSTOMER.SECURITY with a
key of customer code can be set to “NO” to block input for prospective customers.
It is not possible to reverse an active customer record, however a prospective customer record can be reversed, in fact all data relating to that
customer will be removed.
There is an existing mechanism to log customer contacts, this is normally related to authorised contracts, but the customer log (CR.CO-
NTACT.LOG) can be updated directly or via local routines. For example a customer may apply for a loan and be turned down, and then they
may re apply for a loan at a later date and be accepted. In both cases the CR.CONTACT.LOG could be updated
Set Up
The following files need to be updated to enable the process of Prospect Management
COMPANY – this is used to define the defaults setup
CR.CONTACT.LOG.PARAM – this is used for an application to override the defaults.
CUSTOMER – the Customer.Type is used to denote that the customer is either a PROSPECT
Or ACTIVE (blank defaults active)
Company record
The above company has been set up to retain a Prospective Customer for 90 days without any contacts, after which all data for the prospective
customer will be deleted.
CR.CONTACT.LOG.PARAMETER record SYSTEM
Please refer to previous section of CRM User Guide on CR.CONTACT.LOG.PARAM
C R.CONTACT.LOG.PARAMETER record LIMIT
This allows LIMIT input against a Prospect Customer, and will activate this Customer.
CUSTOMER.PROSPECT
CUSTOMER record
Note that a LIMIT may be input against this Prospect Customer 900288 and will activate it.
LIMIT record
LIMIT
CUSTOMER.PROSPECT
CUSTOMER record.
After the LIMIT has been input against Prospect Customer 900288, it is no longer a Prospect and has now Customer Type as ACTIVE.
CR.CONTACT.LOG.PARAMETER
CUSTOMER.SECURITY
This inhibits the input of a Prospect Customer as a Customer. Security.
COMPANY
CUSTOMER PROSPECT
LOANS.AND.DEPOSITS record.
Note that if System default is NO prospect allowed, it cannot be overridden.
C U STOMER PR OSPEC T
CUSTOMER.PROSPECT list
CUSTOMER.PROSPECT
CUSTOMER An example of a prospect Customer 900287
C U STOMER .PU R GE
This is done during the Close of Business process, to remove the Prospect customers that have had no contact for the retention period.
List of customers who are prospective.
Enquiry on Customer who has passed retention period.
Customer has been deleted
Prospect Customers that have passed Retention period are completely deleted.
Sales Opportunity Management
Company And Locking File

The Company record need to have the PGM.AUTOM.ID set for application PW.ACTIVITY.TXN and PW.PROCESS as shown.
Company record
Locking record
Locking record
C R .OPPOR TU N ITY. PA R A METER

This file contains details regarding the initial setup needed for both Propensity and Campaigns that lead to the final creation of CR.O-
PPORTUNITY. The ID of the Parameter table is SYSTEM.
You will have to give instructions to the system as to what needs to be done when an INBOUND or OUTBOUND opportunity already exists.
This is given in the associated multi value fields Prop Overwrite until Prop Action. This action can be performed based on the existing status of
the Propensity. In the example given below the parameter record is setup to duplicate the propensity if the status is NOT.CO-
MMUNICATED.YET
CR.OPPORTUNITY.PARAMETER Record
The Rejected Period gives the period until which the CUSTOMER should not be disturbed with the propensity or campaign if it’s been rejected
already
The Period and the MAX.OB.OPPOR field is where we need to give the duration and the maximum number of Propensity or Campaigns that
can be created. We denote Propensities as INBOUND operations and Campaigns as OUTBOUND operations.
The Prop Prior Status is linked to the different status found in the CR.OPPORTUNITY.STATUS file. The Prop Action can take 3 values Dupli-
cate, Overwrite and Skip. The difference in all these is as follows
When set to Duplicate what happens is, if a Propensity / Campaign already exists for the Customer based on same selection criteria then dupli-
cate entries of CR.OPPORTUNITY records get created.
When set to Skip what happens is, if a Propensity / Campaign already exists for the Customer then the new creation of CR.OPPORTUNITY rec-
ords are not created.
When set to Overwrite what happens is, if a Propensity / Campaign already exists for the Customer then new creation of CR.OPPORTUNITY
records are created, but for the old CR.OPPORTUNITY records the OPPOR.STATUS field is set to SUPERCEDED.
C R .OPPOR TU N ITY.D EFIN ITION

This file is where we set up the Definitions for both INBOUND and OUTBOUND opportunities.
CR.OPPORTUNITY.DEFINITION Record
The ID of the CR.OPPORTUNITY.DEFINITION record is a free text. Here we define the Purpose of having this definition. In our example we
have it as CAR LOANS.
The first 2 fields are used to describe the purpose of having this CR.OPPORTUNITY.DEFINITION record. The Product field accepts only value
from the AA.PRODUCT.CATALOG file. If AA product is not installed then it refers to any CATEGORY record.
The Direction has only 2 options INBOUND / OUTBOUND. For a propensity this should be always INBOUND and for a Campaign this field
should be OUTBOUND.
The QUAL Rule defines the Rule(s) to be applied against the Context. This rule should have a valid entry in the EB.RULE file.
The OPPOR Channel field describes the channel(s) by which the opportunity is communicated to the client. The channels are defined in the
EB.CHANNEL file in T24 .
OPPOR Channel and ORIG process defines the PW activity that is attached to this definition which creates the process workflow based on the
Trigger Status defined.
The OPPR Workflow will be used, in conjunction with the channel. The opportunity will employ different workflows for each channel used. An
opportunity workflow can be appended to both an inbound and an outbound communication. However, only an outbound communication will
automatically generate a PW Process. An inbound opportunity will generate an outbound opportunity if the customer indicates that they are
interested in the opportunity.
The ORIG Process defines the PW.PROCESS that will be initiated if the opportunity to be generated is taken up by the customer.
The TRIGGER Status field is used to indicate the status code of the Opportunity which, when reached, should initiate the origination Process.
Since this is Opportunity is created automatically when a Service is run it needs an OFS Source record to be defined which is of Source type
GLOBUS. In the example shown above we have attached PW.OFS which is of GLOBUS source type and a version to process this as PW.PRO-
CESS. The Version should be PW.PROCESS only and no other version is allowed to be entered in this field.
When opportunities are generated, they can only be applied to specific customers. Therefore, the OPPORTUNITY records should be CUS level
files. However, some opportunities may only be applicable to specific companies – for example, when a campaign relates to a single company,
or when a product is only available in a restricted set of companies. This field enables the user to specify in which companies. The AVAIL.CO-
MPANY field specifies for which company the Opportunity will be created.
C R .OPPOR TU N ITY.GEN ER A TOR

This file specifies the customers and opportunity templates that should be run in a specific circumstance. There are multiple different cir-
cumstances that could apply. An example would be that during a Batch an opportunity record could be generated to select a group of cus-
tomers and run a set of templates against them, to generate a number of propensity opportunities.
An additional role of the opportunity generator is to generate the contexts that need to be passed to the rules engine for evaluation, when deter-
mining whether opportunities should be generated. The Opportunity Table therefore contains two multi value sets. The first indicates which
table will provide the ‘starting point’ list of records that will be used in the rules. The second multi value set would use these records and iden-
tify the fields on the records which themselves hold ids which link to other contexts
For example, there may be a rule which is based on mortgages, which effectively says ‘Find all Platinum Rated customers who have a mortgage
worth more than $1, 000,000’. We want to offer them a new Home Improvement Loans product’. This rule would be initially based on the
Mortgage (mortgages with values greater than $1, 000, 000), so this would be the ‘Primary Context Table’. However, in order to evaluate
whether they are ‘Platinum Customers’ we would also need to view the Customer table. So we would need to specify in the Mortgage appli-
cation which field indicates the Customer that should be passed across as well, to evaluate whether they are a Platinum customer.
CR.OPPORTUNITY.GENERATOR record
The OPPOR.DEF field is linked to the CR.OPPORTUNITY.DEFINITION file. Only an INBOUND opportunity can be linked to a CR.O-
PPORTUNITY.GENERATOR. The Type field gets automatically updated with Propensity.
The fields relating to the primary Context can be defined in the fields relating to PRIM.CTX. PRIM.CTX.TBL should have a File that is present
in the STANDARD.SELECTION record. The Field should be a valid field of the application. The thing to note here is that it should be a single
value field or a Local Ref field. This does not accept Multi value fields. A few examples of how the operands can be used along with Criteria are
illustrated below.
The fields Cust Ctx Fld is where we need to specify the field in the Primary Ctx field that has the Customer Code defined. Since in our example
the PRIMARY CTX is CUSTOMER we have @ID in this field. For Example in an MM / LD Applications it could have CUSTOMER.ID. The
Linked CTX field gets updated automatically on Commit which is nothing but the EB.CONTEXT which is attached to the EB.RULES. All con-
texts required by all rules and the opportunity templates must be given a source ID– an ID from which the relevant data can be derived. There-
fore, every Linked Context multi value set must be told which field contains the value which can be used as an ID for this context
LINKED.CTX.FLD tells the system the field in the Primary Context table that contains the value which can be used as an ID for the linked con-
text. Must be a single value field on Primary context table.
The STATUS field is a System updated field that has value like PENDING, RUNNING,
GENERATED etc. When the CR.OPPORTUNITY.GENERATOR file is verified this Status moves to Pending. The TSA service selects only rec-
ords that are in PENDING status for processing. This is changed to RUNNING when the records are being processed and moved to GEN-
ERATED once completed.
The START.DAY represents the Starting day of the Opportunity. This should be TODAY or a date greater than TODAY. Duration which is noth-
ing but the day until such time the Opportunity is valid is given in this field. It can take values in Days, Months, Week or Year. Ex 1Y, 2W, 3M
etc.
C R .C A MPA IGN .GEN ER A TOR

Set up of the CR.CAMPAIGN.GENERATOR a record is done to create Opportunities for Customers where a Campaign can be generated. This
file is similar to the CR.OPPORTUNITY.GENERATOR for most of the fields expect for some.
CR.CAMPAIGN.GENERATOR Record
The OPPOR.DEF field takes only CR.OPPORTUNITY.DEFINTION s which is only OUTBOUND. The Camp Start Day and End day are given to
specify the period for which the generated OUTBOUND opportunities for the Campaign is valid. The Sample size specifies the number of rec-
ords that will be generated finally based on the Criteria that are specified. Although the selection criteria may fetch more records only the
number of records that are given in the sample size is created. The fields Iteration Status, Iteration Number, Run Date are updated when
OPPORTUNITYis created using the Service is run.
C R .C U ST.OPPOR .H IST
This file will be automatically populated by the system, to reflect for this customer the update caused by the raising of this opportunity. For the
purposes of this scenario, it is assumed that there were no other opportunities present at the moment that this opportunity was generated
CR.CUST.OPPOR.HIST record
Here the Product field describes the product for which an OPPORTUNITY was created. The CR.OPPORTUNITY ID is updated in the next field
OPPORTUNITY. Date Created holds the date when this was created. Direction is OUTBOUND for CAMPAIGN and INBOUND for PRO-
PENSITY. Campaign id denoted the CR.CAMPAIGN.GENERATOR or CR.OPPORTUNITY.GENERATOR id which leads to the creation of this
opportunity for the Customer. This is a Live File and the ID is that of the CUSTOMER to whom the Opportunity was created.
C R .OPPOR TU N ITY
The file contains the Opportunities that are created for the CUSTOMERS. Both the INBOUND and OUTBOUND are stored here. The record
that is created here based on some business requirements. Opportunities are raised through propensity or campaigns. These records are gen-
erating by the OPPORTUNTIY PROCESSING Services that are available. The processing of INBOUND is different to that of the OUTBOUND.
The OUTBOUND processing involves processing using a Process Workflow that is attached. Given below is an example of a CR.O-
PPORTUNITY record that was created automatically by a Service that was run.
CR.OPPORTUNITY record for INBOUND
The CR.OPPORTUNITY is an AUTO generated number. Here we have the CUSTOMER details to which this INBOUND propensity was
created in the CR.OPPORTUNITY file. This file also records the CR.OPPORTUNITY.DEFINITION and the CR.OPPORTUNITY.GENERATOR
details. The Start and End date until which this Opportunity is valid is also updated. The Company where this Opportunity is valid and the
mode of communication to the Customer is updated in the INBOUND Channel field. The Opportunity Status is updated as well. This is a valid
entry in CR.OPORTUNITY.STATUS file.
If the opportunity is inbound, then this field INBOUND Channel will list the channels through which the user can be contacted for this oppor-
tunity. This field will have been validated against both the opportunity template for available channels, and also the customer profile to deter-
mine through which channels they can be contacted. This field will be cleared when the opportunity is changed from inbound to outbound.
A sample of a CR.OPPORTUNITY for an OUTBOUND Campaign is shown in the figure below.
CR.OPPORTUNITY for an OUTBOUND Campaign
In the Figure above you will see that the Campaign ID field is updated for OUTBOUND and not OPP. GENR.ID field. The OPPOR Proc ID is
updated as well. This is the ID of the PW.PROCESS that is attached as a workflow for the creation of this OUTBOUND campaign.
C R .OPPOR TU N ITY pr oc e s s c r e a tion for pr ope ns ity
Here we try to explain the process involved in the creation of CR.OPPORTUNITY for a CUSTOMER. When we say propensity we mean an
INBOUND operation. This process involves the setup of the CR.OPPORTUNITY.DEFINITION initially. Then the CR.O-
PPORTUNITY.GENERATOR record is created. We need to verify the record that is created in this file to move the OPPOR.STATUS to PEND-
ING. A TSA Service called CR.OPPORTUNITY.PROCESSING is run. This Service will select all the PENDING records and process the
opportunities based on the specific selection criteria given.
C R .OPPOR TU N ITY pr oc e s s c r e a tion for C a m pa ign

The Process of creating opportunity for Campaigns is different from those of propensity. The process is the same for the creation of the CR.O-
PPORTUNITY.DEFINITION and CR.CAMPAIGN.GENERATOR but the difference lies in the Services that are run to generate the OPPOR-
TUNITY. The TSA Service CR.CAMPAIGN.PROCESSING is run initially to process these records in PENDING status. The Services that needs
to be run are shown below. This needs to be run in order.
TSA Service - CR.CAMPAIGN.PROCESSING
The above CR.CAMPAIGN.PROCESSING Service is run first to process the CR.CAMPAIGN.GENERATOR record where the OPPOR.STATUS
is set to PENDING. The status changes to Pending when the record is verified. This service is run to form a PW.PROCESS message as an OFS
String into the OFS.MESSAGE.QUEUE.
Above we see the CR.CAMPAIGN.PROCESSING service being run and below we have the records in the OFS.MESSAGE.QUEUE.
Another service is run to process these OFS strings which are formed in the OFS.MESSAGE.QUEUE. Care should be taken to have the PW
Setup in place. A PW workflow is necessary for any OUTBOUND creation of CR.OPPORTUNITY . The Next Service that is run is the OFS.ME-
SSAGE.SERVICE which converts the PW.PROCESS message to actual transactions and updates or writes it in another file called the OFS.R-
ESPOSE.QUEUE.
TSA Service - OFS.MESSAGE.SERVICE
The record as seen in the OFS.MESSAGE.QUEUE is shown
The above figure shows the records in the OFS.RESPONSE.QUEUE. The PW.PROCESS record is also created simultaneously.
PW.PROCESS
TSA Service - OFS.RESPONSE.QUEUE
All that the OFS.RESPONSE.QUEUE service does is the purging of records from the OFS.RESPONSE.QUEUE created by the OFS.ME-
SSAGE.SERVICE while creating the PW.PROCESS.
TSA Service – PW.MAPPING
The above PW.MAPPING service is run to create the CR.OPPORTUNITY and also to map the PW.PROCESS to the CR.OPPORTUNITY.
This is the final service that is run to generate the CR.OPPORTUNITY for CAMPAIGNS. Once this service is run the PW.ACTIVITY.TXN rec-
ord gets updated with few details like the Transaction Ref of the CR.OPPORTUNITY record and the TARGET.
The iteration Status field in CR.CAMPAIGN.OPPORTUNITY record is also updated as GENERATED An Opportunity which is a propensity
can be changed to a Campaign. The process it to convert an INBOUND opportunity to an OUTBOUND opportunity. The reverse is not pos-
sible. The only difference here is that the first service to be started in this case is the CR.OPPORTUNITY.PROCESSING instead of the CR.CA-
MPAIGN.GENERATOR followed by OFS.MESSAGE.SERVICE, OFS.RESPONSE.QUEUE and the PW.MAPPING.
Enquir y for C R .OPPOR TU N ITY
CR.CUST.OPPORTUNITIES Enquiry
An ENQUIRY CR.CUST.OPPORTUNITIES is available to select all CR.OPPORTUNITIES records, which have the corresponding item records
generated, various operations can be performed using this enquiry itself.
A Dropdown that is available help you to do certain operation like View, Edit, or Reject an Opportunity. There is an option to View the Oppor-
tunity / Campaign Generator that created the CR.OPPORTUNITY. You can also view the Customer for whom the opportunity was created.
The PW process workflow is also done using this Enquiry which caters to Initiating the Sales and Originating workflow.
Relationship Table
This will provide additional business functionality in CRM to create groups between the customers who have a relationship with the bank. New
tables CR.RELATIONSHIP and CR.INTRODUCTION.SOURCE are developed to register the relationships and to indicate the groupings within
the customers.
CR.RELATIONSHIP
CR.RELATIONSHIP

@ID A Unique identifier of Relationship.Length of Key can contain 35 character
RELATIONSHIP.NAME A Description of Relationship.Length can be 50L.Mandatory field for this
table
xx<xx.RISK A Description about the risks associated with the Relationship.
XX>xx.WHY.RISK.ACCEPTED A For each risk, bank details why it considers the risks acceptable
BOOKING.CENTER DAO BOOKING CENTRE FOR THE RELATIONSHIP.THIS FIELD IS LINKED

TO DEPT ACCT OFFICER TABLE.
BRANCH.CODE DAO HOLDS THE DETAILS ABOUT COMPANY IN WHICH RELATIONSHIP
IS AVAILABLE.THIS FIELD IS LINKED TO COMPANY TABLE
REL.MANAGER DAO HOLDS THE DETAILS ABOUT RELATIONSHIP MANAGER.THIS FIELD
IS LINKED TO DAO TABLE
XX.FURTHER.MANAGERS DAO HOLDS THE DETAILS ABOUT SUPPLEMENTARY MANAGERS WHO
ASSIST IN RELATIONSHIP.THIS FIELD IS LINKED TO DAO TABLE
MIS.CODE A HOLDS THE MISC NO ALLOCATED BY BANK MISC SYSTEM. LENGTH
CAN BE 10L ALPHANUMERIC VALUE.
XX<RELATIONSHIP.UPDATE Dropdown OPTIONS ARE NEW PWM RELATIONSHIP, EXISTING PWM RELA-
TIONSHIP, UPDATE TO EXISTING KYC/PERIODIC UPDATE.THIS IS
LINKED TO VIRTUAL EB.LOOKUP TABLE
XX-XX.UPDATE.REASON A HOLDS THE REASON FOR UPDATE
XX>UPDATE.DATE D HOLDS THE DATE OF UPDATE
REL.START.DATE D HOLDS THE DATE FOR START OF RELATIONSHIP.FORWARD VALUE
DATES ARE NOT ALLOWED
HOW.INTRODUCED Check file Linked to new table CR.INTRODUCTION.SOURCE
XX.INTRO.DETAILS A HOLDS THE INTRODUCTION DETAILS
MARKET.INDICATOR Dropdown DROPDOWN FIELD USES EB.LOOKUP TABLE.OPTIONS ARE TARGET
MARKET; NON-TARGET MARKET; SENSITIVE BACKGROUND.
RETROCESSION.PAYMENT Dropdown VALID OPTIONS :YES /NO
XX.RETROCESSION.DETAILS A HOLDS THE RETROCESSION DETAILS TO BE PAID AS RESULT OF
RELATIONSHIP.
XX.REFERENCES A REFERENCES USED IN THE GENERATION OF THIS RELATIONSHIP
XX.PRIMARY.CONTACT A DETAILS ABOUT PRIMARY CONTACT PERSON FOR RELATIONSHIP
MANAGER
CALC.AML.EVALUATION Tick-Box DROPDOWN FIELD USES EB.LOOKUP TABLE.OPTIONS ARE LOW,
MEDIUM, PEP/HIGH
MANUAL.AML.EVALUATION Tick-Box DROPDOWN FIELD USES EB.LOOKUP TABLE.OPTIONS ARE LOW,
MEDIUM, PEP/HIGH
PROFILE.REVIEW.EVAL Tick-Box DROPDOWN FIELD USES EB.LOOKUP TABLE.OPTIONS ARE LOW,
MEDIUM, PEP/HIGH.
XX.REASON.DIFFT.RISK.EVAL A INDICATE REASON WHY CLIENT PROFILE REVIEW CAME UP WITH
A DIFFERENT PROFILE
XX.FOLLOW.UP.REQUIRED A ANY FOLLOW-UP ACTIONS TAKEN BY RM
TAGGING.REQUIRED Dropdown OPTIONS ARE RED-FLAG, STAFF, STAFF-RELATED, OTHER
XX.RESTRICTIONS.REQUIRED A ANY RESTRICTIONS / MONITORING TO BE PLACED ON CLIENT'S
ACCOUNT
CR.INTROLDUCTION.SOURCE
@ID 10,A Unique idenfifier of for source of introduction
DESCRIPTION 50L,A Standard Text field
xx.COMPANY.available COM Hold the details about companies where introduction is
Available. This field is linked to company table.
Setup
Installation Of Product
On receipt of the product code this must be entered into the SPF file called SYSTEM.
SPF
Product codes in the SPF
The product must then be included in the COMPANY records as required.
Company
Sample SPF screenshot
AUTO.ID.SETUP
Auto ID has to be setup for the 3 applications mentioned above in the COMPANY screenshot. A sample is shown below.
AUTO.ID.START
Sequencing for different tables are shown below
CR.CAMPAIGN.OPPORTUNITY – ‘CRCO’YYJJJnnnnn where YY=Year, JJJ=Julian Date and nnnnn=sequence number
CR.CONTACT.LOG - ‘CR’YYJJnnnnn
CR.OTHER.PRODUCTS – ‘CROP’YYJJnnnnn
Customer
Customer template has been updated to incorporate new fields required for CRM. The fields are shown below with more information available
in the CUSTOMER user guide.
The details of the fields added to CUSTOMER are as below

XX<PROFILE.TYPE 35,A Linked to PROFILE.TYPE table
NOINPUT
XX>PROFILE 35,A Linked to PROFILE table
NOINPUT
TITLE 6 Can have any of these values
MR_MRS_MS_MISS_DR_REV
GIVEN.NAMES 50, A Name of the customer
FAMILY.NAME 50, A Family name of the customer
GENDER 6, A MALE_FEMALE
DATE.OF.BIRTH 11, D
MARITAL.STATUS 11 Linked to the virtual table MARITAL.STATUS in EB.LOOKUP
NO.OF.DEPENDENTS 2
PHONE.1 17, ANY
SMS.1 17, ANY
EMAIL.1 35, ANY
XX<EMPLOYMENT.STATUS Linked to the virtual table EMPLOYMENT.STATUS in EB.LOOKUP
XX-OCCUPATION 35, A
XX-EMPLOYERS.NAME 35, A
XX-EMPLOYERS.ADD 35, A
XX-EMPLOYERS.BUSS 35, A
XX-EMPLOYMENT.START 11, D
XX-CUSTOMER.CURRENCY 3, CCY
XX-SALARY 10
XX-ANNUAL.BONUS 10
XX>SALARY.DATE.FREQ 17, FQU
NET.MONTHLY.IN 10
NET.MONTHLY.OUT 10
XX<RESIDENCE.STATUS 35 Linked to the virtual table RESIDENCE.STATUS in EB.LOOKUP
XX-RESIDENCE.TYPE 11, A
XX-RESIDENCE.SINCE 11, D
XX-RESIDENCE.VALUE 11
XX>MORTGAGE.AMT 11
XX<OTHER.FIN.REL 3 Linked to RELATION
XX>OTHER.FIN.INST 35
XX<COMM.TYPE 35
XX>PREF.CHANNEL 11, A Linked to EB.CHANNEL
XX<CR.CAMPAIGN.ID 35
XX>CR.OPPOR.ID 35
XX.INTERESTS 35, A
FAX.1 17
SECURITY.PASSWORD 35
XX<SECURITY.QUEST 35
XX>SECURITY.ANS 35
XX<PREVIOUS.NAME 35
XX-CHANGE.DATE 11
XX>CHANGE.REASON 35
CUSTOMER.SINCE 11
XX.RESERVED04 35, A Added for future use
to NOINPUT
XX.RESERVED01
CUSTOMER TABLE CR.PROFILE
CONT.
Customer profiles are updated by two ways.
Customer creation or updating: Whenever a customer record is created or updated that “CUSTOMER” is profiled to a group. Customer tem-
plate contains 2 fields called CR.PROFILE.TYPE and CR.PROFILE which are updated with the group. These fields are multi-value fields. Hence
a customer can be part of more than one group. (Screenshots above).
Service : A new TSA.SERVICE has been created called CR.PROCESSING which will update the customer record with a group assigned to him.
TSA SERVICE RECORD FOR CRM
CR.PROFILE.TYPE
Customers are classified into different groups via CR.PROFILE.TYPE table when satisfying specific criteria. This enables the bank to easily sell
products to them as well as group the customers accordingly.
CR.PROFILE.TYPE defines the different types of profiles.
CR.PROFILE.TYPE TABLE
CR.PROFILE
CR.PROFILE provides the condition based on which a customer would fall into a category in CR.PROFILE.TYPE.
A customer can be grouped under more than one category too.
In the below mentioned example A profile STUDENT is created with a rule associated with it.
CR.PROFILE TABLE
Screenshot of the rule is given below as part of PW.TRANSITION.
PW.TR A N STION
Rules for CR.PROFILE’ s are setup through an application called PW.TRANSITION (refer : Process Workflow user guide)
PW.TRANSITION RULE
CUSTOMER RECORD DISPLAYING NEW FIELDS
CONT.
Flow To Setup Customer Profile
When a customer is created, the PW.TRANSTION rule is checked for condition first. If customer satisfies the rule, a profile is associated with
the customer based on the CR.PROFILE which is linked to the PW.TRANSITION rule.
Updates To DE.ADDRESS
A few fields have been updated in DE.ADDRESS reflecting the contact details for a customer
DE.ADDRESS
The fields added are
1. Phone –Contains the telephone number of the customer.

2. SMS – Contains the mobile number of customer which can be used to send a sms messages.
3. Email – Holds the email address of customer through which a message can be mailed.
Customer Single View

Customer single view is the central information view of necessary customer data. The single window is a split up of
1. Customer Information – Basic static information of the customer.

2. Products held by customer information
* Products which are not held within the bank are recorded in a table called CR.OTHER.PRODUCT.
3. Customer Activity - All activities which have happened and will happen in future for the customer are displayed. This includes pay-
ments made and to be made.
4. Campaign and Opportunities – Information regarding the different campaigns sent out to the customer along with the response
received for the same.
A customer can amend data through the customer single window.
SINGLE CUSTOMER VIEW
BROWSER.PREFERENCES
CRM users have to have access to only the above mentioned window. To setup, create a record for the required user in BROWSER.PRE-
FERENCES indicating the main screen as CRM.START
BROWSER.PREFERENCES
Login Screen For A CRM User Is As Below

Selecting a customer can be done using any of the fields shown below.
MAIN SCREEN FOR CRM USER
A user can only access the customer single window. This user is specifically a CRM user and hence has no access to other areas of T24.
Customer Contact Information

Whenever a customer contacts the bank (be it for query or instruction), a log is created showing the history of the contact
The following tables are used for logging the information.
C R .C ON TA C T.LOG.PA R A M
A parameter table which holds information on which field should be the tracking field for a customer in any application. These records are then
recorded in CR.CONTACT.LOG. The screenshots below explain more.
A base record called SYSTEM is created to record how many transaction histories are to be held.
* The following example shows the max history to be 3.
Other than SYSTEM record, any application (with or without version) can be given as ID
Since customers are tracked with a customer number or account number (or both), we specify the same in parameter record. An example is
shown below.
Note: Though validation against the fields is done for the application, user has to make sure the correct customer and account fields are given.
Example
Let us track a mortgage for a customer
MORTGAGE RECORD FOR TRACKING CONTRACT LOG
We have given the mortgage tracking fields in CR.CONTACT.LOG.PARAM as given above.
CR.CONTACT.LOG FROM MORTGAGE RECORD
A manual entry done directly in CR.CONTACT.LOG table is shown below.
MANUAL UPDATE OF CR.CONTACT.LOG
C R .OTH ER .PR OD U C TS
Sometimes banks wish to record information regarding customers assets/liabilities held outside the bank. They can be recorded in an appli-
cation called CR.OTHER.PRODUCTS. This is an information only application and does not have any financial implication with T24.
This record is populated manually and CRM shows the information with regards to other products in the product window of the CUSTOMER
single view.
CR.OTHER.PRODUCTS
C R .C ON TA C T.LOG.FU TR a nd C R .C ON TA C T.LOG.H IST

There are two contact files named CR.CONTACT.LOG.FUTR and CR.CONTACT.LOG.HIST both of which holds CR.CONTACT.LOG table
information for a customer based on whether they are past or future events. Both these tables are updated when CR.CONTACT.LOG is updated
with a new record or an existing record is updated.
C R .C ON TA C T.LOG.FU TR
The example shows various Logs which are future events.
CR.CONTACT.LOG.FUTR
C R .C ON TA C T.LOG.H IST
CR.CONTACT.LOG.HIST
C A MPA IGN a nd OPPOR TU N ITY

A campaign is a event/publicity/contact held by the bank for its customer for the following purposes.
l A product announcement
l Targeting specific type of customers (based on income, location etc).
C R .C A MPA IGN .D EFIN ITION S

Before a bank selects customers to send a campaign too, a definition of the campaign has to be created.
CR.CAMPAIGN.DEFINITION records actual definition of the campaign. The record would be created with “CAMPAIGN.STATUS” as new. The
record should be verified after which it moves to pending status.
To build list of customers who become part of the campaign, the service “CR.PROCESSING” is to be verified.
Example : The below shown screenshot defines a car loan campaign being run for Students running from 30 th Nov to 4th Dec. The record cam-
paign status should contain New status
CAMPAIGN DEFINITION
TSA.SERVICE FOR CRM
*Note: Company Mnemonic will vary according to each bank’s setup.
Once the TSA.SERVICE is completed the record moves to ‘Launched’ status
CAMPAIGN DEFINITON SHOWING STATUS
The TSA.SERVICE also builds a list of opportunity records as explained below.
C R .C A MPA IGN .OPPOR TU N ITY

Once a campaign is defined and a list of customer’s is built, an opportunity table records the history of each of the targeted customer.
OPPORTUNITY RECORDS CREATED FROM CAMPAIGN
All the opportunity records will initially be in New status, once the bank receives a feedback from the customer, the status is moved by a cus-
tomer servicing executive.
CR.CAMPAIGN.OPPORTUNITY RECORD
A process is created for each customer to send out the information through the delivery channel mentioned.
Prospect Management
The Customer Type on the CUSTOMER table enables the differentiation between customers who are actively doing business with the bank
and Prospective Customers.
A customer with a Customer.Type of PROSPECT is only allowed a period of time (Cust.Retention) to be on the system, after which the pro-
spective customer information is removed by the Customer Purge process in the Close of Business.
A customer can have its Customer.Type set to ACTIVE by any one of the following activities and once Active cannot be reversed.
A prospective customer record is manually modified to activate the customer.
An unauthorised transaction is entered for a customer, for example an account or a limit is opened for a customer, or a customer takes out a
loan without having an account or limit with the bank.
The system defaults for allowing input of prospective customers are as follows: -
The default is YES for fields that do a direct check on the CUSTOMER table, i.e. they have SYS.REL.FILE (CHECKFILE) defined as CUS-
TOMER on the relevant STANDARD.SELECTION record.
The default is NO for fields that can either optionally consist of a customer code or free text, or fields that contain a customer code as a com-
ponent of the field.
However the system defaults can be overridden using the application CR.CONTACT.LOG.PARAM. For example Limit where the customer code
is the first part of the key delimited by ‘.’ can be set to YES to allow input for prospective customers, whereas CUSTOMER.SECURITY with a
key of customer code can be set to “NO” to block input for prospective customers.
It is not possible to reverse an active customer record, however a prospective customer record can be reversed, in fact all data relating to that
customer will be removed.
There is an existing mechanism to log customer contacts, this is normally related to authorised contracts, but the customer log (CR.CO-
NTACT.LOG) can be updated directly or via local routines. For example a customer may apply for a loan and be turned down, and then they
may re apply for a loan at a later date and be accepted. In both cases the CR.CONTACT.LOG could be updated
Set Up
The following files need to be updated to enable the process of Prospect Management
COMPANY – this is used to define the defaults setup
CR.CONTACT.LOG.PARAM – this is used for an application to override the defaults.
CUSTOMER – the Customer.Type is used to denote that the customer is either a PROSPECT
Or ACTIVE (blank defaults active)
Company record
The above company has been set up to retain a Prospective Customer for 90 days without any contacts, after which all data for the prospective
customer will be deleted.
CR.CONTACT.LOG.PARAMETER record SYSTEM
Please refer to previous section of CRM User Guide on CR.CONTACT.LOG.PARAM
C R.CONTACT.LOG.PARAMETER record LIMIT
This allows LIMIT input against a Prospect Customer, and will activate this Customer.
CUSTOMER.PROSPECT
CUSTOMER record
Note that a LIMIT may be input against this Prospect Customer 900288 and will activate it.
LIMIT record
LIMIT
CUSTOMER.PROSPECT
CUSTOMER record.
After the LIMIT has been input against Prospect Customer 900288, it is no longer a Prospect and has now Customer Type as ACTIVE.
CUSTOMER.SECURITY
This inhibits the input of a Prospect Customer as a Customer. Security.
COMPANY
CUSTOMER PROSPECT
LOANS.AND.DEPOSITS record.
Note that if System default is NO prospect allowed, it cannot be overridden.
C U STOMER PR OSPEC T
CUSTOMER.PROSPECT list
CUSTOMER.PROSPECT
CUSTOMER An example of a prospect Customer 900287
C U STOMER .PU R GE
This is done during the Close of Business process, to remove the Prospect customers that have had no contact for the retention period.
List of customers who are prospective.
Enquiry on Customer who has passed retention period.
Customer has been deleted
Prospect Customers that have passed Retention period are completely deleted.
Sales Opportunity Management
Company And Locking File

The Company record need to have the PGM.AUTOM.ID set for application PW.ACTIVITY.TXN and PW.PROCESS as shown.
Company record
Locking record
Locking record
C R .OPPOR TU N ITY. PA R A METER

This file contains details regarding the initial setup needed for both Propensity and Campaigns that lead to the final creation of CR.O-
PPORTUNITY. The ID of the Parameter table is SYSTEM.
You will have to give instructions to the system as to what needs to be done when an INBOUND or OUTBOUND opportunity already exists.
This is given in the associated multi value fields Prop Overwrite until Prop Action. This action can be performed based on the existing status of
the Propensity. In the example given below the parameter record is setup to duplicate the propensity if the status is NOT.CO-
MMUNICATED.YET
CR.OPPORTUNITY.PARAMETER Record
The Rejected Period gives the period until which the CUSTOMER should not be disturbed with the propensity or campaign if it’s been rejected
already
The Period and the MAX.OB.OPPOR field is where we need to give the duration and the maximum number of Propensity or Campaigns that
can be created. We denote Propensities as INBOUND operations and Campaigns as OUTBOUND operations.
The Prop Prior Status is linked to the different status found in the CR.OPPORTUNITY.STATUS file. The Prop Action can take 3 values Dupli-
cate, Overwrite and Skip. The difference in all these is as follows
When set to Duplicate what happens is, if a Propensity / Campaign already exists for the Customer based on same selection criteria then dupli-
cate entries of CR.OPPORTUNITY records get created.
When set to Skip what happens is, if a Propensity / Campaign already exists for the Customer then the new creation of CR.OPPORTUNITY rec-
ords are not created.
When set to Overwrite what happens is, if a Propensity / Campaign already exists for the Customer then new creation of CR.OPPORTUNITY
records are created, but for the old CR.OPPORTUNITY records the OPPOR.STATUS field is set to SUPERCEDED.
C R .OPPOR TU N ITY.D EFIN ITION

This file is where we set up the Definitions for both INBOUND and OUTBOUND opportunities.
CR.OPPORTUNITY.DEFINITION Record
The ID of the CR.OPPORTUNITY.DEFINITION record is a free text. Here we define the Purpose of having this definition. In our example we
have it as CAR LOANS.
The first 2 fields are used to describe the purpose of having this CR.OPPORTUNITY.DEFINITION record. The Product field accepts only value
from the AA.PRODUCT.CATALOG file. If AA product is not installed then it refers to any CATEGORY record.
The Direction has only 2 options INBOUND / OUTBOUND. For a propensity this should be always INBOUND and for a Campaign this field
should be OUTBOUND.
The QUAL Rule defines the Rule(s) to be applied against the Context. This rule should have a valid entry in the EB.RULE file.
The OPPOR Channel field describes the channel(s) by which the opportunity is communicated to the client. The channels are defined in the
EB.CHANNEL file in T24 .
OPPOR Channel and ORIG process defines the PW activity that is attached to this definition which creates the process workflow based on the
Trigger Status defined.
The OPPR Workflow will be used, in conjunction with the channel. The opportunity will employ different workflows for each channel used. An
opportunity workflow can be appended to both an inbound and an outbound communication. However, only an outbound communication will
automatically generate a PW Process. An inbound opportunity will generate an outbound opportunity if the customer indicates that they are
interested in the opportunity.
The ORIG Process defines the PW.PROCESS that will be initiated if the opportunity to be generated is taken up by the customer.
The TRIGGER Status field is used to indicate the status code of the Opportunity which, when reached, should initiate the origination Process.
Since this is Opportunity is created automatically when a Service is run it needs an OFS Source record to be defined which is of Source type
GLOBUS. In the example shown above we have attached PW.OFS which is of GLOBUS source type and a version to process this as PW.PRO-
CESS. The Version should be PW.PROCESS only and no other version is allowed to be entered in this field.
When opportunities are generated, they can only be applied to specific customers. Therefore, the OPPORTUNITY records should be CUS level
files. However, some opportunities may only be applicable to specific companies – for example, when a campaign relates to a single company,
or when a product is only available in a restricted set of companies. This field enables the user to specify in which companies. The AVAIL.CO-
MPANY field specifies for which company the Opportunity will be created.
C R .OPPOR TU N ITY.GEN ER A TOR

This file specifies the customers and opportunity templates that should be run in a specific circumstance. There are multiple different cir-
cumstances that could apply. An example would be that during a Batch an opportunity record could be generated to select a group of cus-
tomers and run a set of templates against them, to generate a number of propensity opportunities.
An additional role of the opportunity generator is to generate the contexts that need to be passed to the rules engine for evaluation, when deter-
mining whether opportunities should be generated. The Opportunity Table therefore contains two multi value sets. The first indicates which
table will provide the ‘starting point’ list of records that will be used in the rules. The second multi value set would use these records and iden-
tify the fields on the records which themselves hold ids which link to other contexts
For example, there may be a rule which is based on mortgages, which effectively says ‘Find all Platinum Rated customers who have a mortgage
worth more than $1, 000,000’. We want to offer them a new Home Improvement Loans product’. This rule would be initially based on the
Mortgage (mortgages with values greater than $1, 000, 000), so this would be the ‘Primary Context Table’. However, in order to evaluate
whether they are ‘Platinum Customers’ we would also need to view the Customer table. So we would need to specify in the Mortgage appli-
cation which field indicates the Customer that should be passed across as well, to evaluate whether they are a Platinum customer.
CR.OPPORTUNITY.GENERATOR record
The OPPOR.DEF field is linked to the CR.OPPORTUNITY.DEFINITION file. Only an INBOUND opportunity can be linked to a CR.O-
PPORTUNITY.GENERATOR. The Type field gets automatically updated with Propensity.
The fields relating to the primary Context can be defined in the fields relating to PRIM.CTX. PRIM.CTX.TBL should have a File that is present
in the STANDARD.SELECTION record. The Field should be a valid field of the application. The thing to note here is that it should be a single
value field or a Local Ref field. This does not accept Multi value fields. A few examples of how the operands can be used along with Criteria are
illustrated below.
The fields Cust Ctx Fld is where we need to specify the field in the Primary Ctx field that has the Customer Code defined. Since in our example
the PRIMARY CTX is CUSTOMER we have @ID in this field. For Example in an MM / LD Applications it could have CUSTOMER.ID. The
Linked CTX field gets updated automatically on Commit which is nothing but the EB.CONTEXT which is attached to the EB.RULES. All con-
texts required by all rules and the opportunity templates must be given a source ID– an ID from which the relevant data can be derived. There-
fore, every Linked Context multi value set must be told which field contains the value which can be used as an ID for this context
LINKED.CTX.FLD tells the system the field in the Primary Context table that contains the value which can be used as an ID for the linked con-
text. Must be a single value field on Primary context table.
The STATUS field is a System updated field that has value like PENDING, RUNNING,
GENERATED etc. When the CR.OPPORTUNITY.GENERATOR file is verified this Status moves to Pending. The TSA service selects only rec-
ords that are in PENDING status for processing. This is changed to RUNNING when the records are being processed and moved to GEN-
ERATED once completed.
The START.DAY represents the Starting day of the Opportunity. This should be TODAY or a date greater than TODAY. Duration which is noth-
ing but the day until such time the Opportunity is valid is given in this field. It can take values in Days, Months, Week or Year. Ex 1Y, 2W, 3M
etc.
C R .C A MPA IGN .GEN ER A TOR

Set up of the CR.CAMPAIGN.GENERATOR a record is done to create Opportunities for Customers where a Campaign can be generated. This
file is similar to the CR.OPPORTUNITY.GENERATOR for most of the fields expect for some.
CR.CAMPAIGN.GENERATOR Record
The OPPOR.DEF field takes only CR.OPPORTUNITY.DEFINTION s which is only OUTBOUND. The Camp Start Day and End day are given to
specify the period for which the generated OUTBOUND opportunities for the Campaign is valid. The Sample size specifies the number of rec-
ords that will be generated finally based on the Criteria that are specified. Although the selection criteria may fetch more records only the
number of records that are given in the sample size is created. The fields Iteration Status, Iteration Number, Run Date are updated when
OPPORTUNITYis created using the Service is run.
C R .C U ST.OPPOR .H IST
This file will be automatically populated by the system, to reflect for this customer the update caused by the raising of this opportunity. For the
purposes of this scenario, it is assumed that there were no other opportunities present at the moment that this opportunity was generated
CR.CUST.OPPOR.HIST record
Here the Product field describes the product for which an OPPORTUNITY was created. The CR.OPPORTUNITY ID is updated in the next field
OPPORTUNITY. Date Created holds the date when this was created. Direction is OUTBOUND for CAMPAIGN and INBOUND for PRO-
PENSITY. Campaign id denoted the CR.CAMPAIGN.GENERATOR or CR.OPPORTUNITY.GENERATOR id which leads to the creation of this
opportunity for the Customer. This is a Live File and the ID is that of the CUSTOMER to whom the Opportunity was created.
C R .OPPOR TU N ITY
The file contains the Opportunities that are created for the CUSTOMERS. Both the INBOUND and OUTBOUND are stored here. The record
that is created here based on some business requirements. Opportunities are raised through propensity or campaigns. These records are gen-
erating by the OPPORTUNTIY PROCESSING Services that are available. The processing of INBOUND is different to that of the OUTBOUND.
The OUTBOUND processing involves processing using a Process Workflow that is attached. Given below is an example of a CR.O-
PPORTUNITY record that was created automatically by a Service that was run.
CR.OPPORTUNITY record for INBOUND
The CR.OPPORTUNITY is an AUTO generated number. Here we have the CUSTOMER details to which this INBOUND propensity was
created in the CR.OPPORTUNITY file. This file also records the CR.OPPORTUNITY.DEFINITION and the CR.OPPORTUNITY.GENERATOR
details. The Start and End date until which this Opportunity is valid is also updated. The Company where this Opportunity is valid and the
mode of communication to the Customer is updated in the INBOUND Channel field. The Opportunity Status is updated as well. This is a valid
entry in CR.OPORTUNITY.STATUS file.
If the opportunity is inbound, then this field INBOUND Channel will list the channels through which the user can be contacted for this oppor-
tunity. This field will have been validated against both the opportunity template for available channels, and also the customer profile to deter-
mine through which channels they can be contacted. This field will be cleared when the opportunity is changed from inbound to outbound.
A sample of a CR.OPPORTUNITY for an OUTBOUND Campaign is shown in the figure below.
CR.OPPORTUNITY for an OUTBOUND Campaign
In the Figure above you will see that the Campaign ID field is updated for OUTBOUND and not OPP. GENR.ID field. The OPPOR Proc ID is
updated as well. This is the ID of the PW.PROCESS that is attached as a workflow for the creation of this OUTBOUND campaign.
C R .OPPOR TU N ITY pr oc e s s c r e a tion for pr ope ns ity
Here we try to explain the process involved in the creation of CR.OPPORTUNITY for a CUSTOMER. When we say propensity we mean an
INBOUND operation. This process involves the setup of the CR.OPPORTUNITY.DEFINITION initially. Then the CR.O-
PPORTUNITY.GENERATOR record is created. We need to verify the record that is created in this file to move the OPPOR.STATUS to PEND-
ING. A TSA Service called CR.OPPORTUNITY.PROCESSING is run. This Service will select all the PENDING records and process the
opportunities based on the specific selection criteria given.
C R .OPPOR TU N ITY pr oc e s s c r e a tion for C a m pa ign

The Process of creating opportunity for Campaigns is different from those of propensity. The process is the same for the creation of the CR.O-
PPORTUNITY.DEFINITION and CR.CAMPAIGN.GENERATOR but the difference lies in the Services that are run to generate the OPPOR-
TUNITY. The TSA Service CR.CAMPAIGN.PROCESSING is run initially to process these records in PENDING status. The Services that needs
to be run are shown below. This needs to be run in order.
TSA Service - CR.CAMPAIGN.PROCESSING
The above CR.CAMPAIGN.PROCESSING Service is run first to process the CR.CAMPAIGN.GENERATOR record where the OPPOR.STATUS
is set to PENDING. The status changes to Pending when the record is verified. This service is run to form a PW.PROCESS message as an OFS
String into the OFS.MESSAGE.QUEUE.
Above we see the CR.CAMPAIGN.PROCESSING service being run and below we have the records in the OFS.MESSAGE.QUEUE.
Another service is run to process these OFS strings which are formed in the OFS.MESSAGE.QUEUE. Care should be taken to have the PW
Setup in place. A PW workflow is necessary for any OUTBOUND creation of CR.OPPORTUNITY . The Next Service that is run is the OFS.ME-
SSAGE.SERVICE which converts the PW.PROCESS message to actual transactions and updates or writes it in another file called the OFS.R-
ESPOSE.QUEUE.
TSA Service - OFS.MESSAGE.SERVICE
The record as seen in the OFS.MESSAGE.QUEUE is shown
The above figure shows the records in the OFS.RESPONSE.QUEUE. The PW.PROCESS record is also created simultaneously.
PW.PROCESS
All that the OFS.RESPONSE.QUEUE service does is the purging of records from the OFS.RESPONSE.QUEUE created by the OFS.ME-
SSAGE.SERVICE while creating the PW.PROCESS.
TSA Service – PW.MAPPING
The above PW.MAPPING service is run to create the CR.OPPORTUNITY and also to map the PW.PROCESS to the CR.OPPORTUNITY.
This is the final service that is run to generate the CR.OPPORTUNITY for CAMPAIGNS. Once this service is run the PW.ACTIVITY.TXN rec-
ord gets updated with few details like the Transaction Ref of the CR.OPPORTUNITY record and the TARGET.
The iteration Status field in CR.CAMPAIGN.OPPORTUNITY record is also updated as GENERATED An Opportunity which is a propensity
can be changed to a Campaign. The process it to convert an INBOUND opportunity to an OUTBOUND opportunity. The reverse is not pos-
sible. The only difference here is that the first service to be started in this case is the CR.OPPORTUNITY.PROCESSING instead of the CR.CA-
MPAIGN.GENERATOR followed by OFS.MESSAGE.SERVICE, OFS.RESPONSE.QUEUE and the PW.MAPPING.
Enquir y for C R .OPPOR TU N ITY
CR.CUST.OPPORTUNITIES Enquiry
An ENQUIRY CR.CUST.OPPORTUNITIES is available to select all CR.OPPORTUNITIES records, which have the corresponding item records
generated, various operations can be performed using this enquiry itself.
A Dropdown that is available help you to do certain operation like View, Edit, or Reject an Opportunity. There is an option to View the Oppor-
tunity / Campaign Generator that created the CR.OPPORTUNITY. You can also view the Customer for whom the opportunity was created.
The PW process workflow is also done using this Enquiry which caters to Initiating the Sales and Originating workflow.
Relationship Table
This will provide additional business functionality in CRM to create groups between the customers who have a relationship with the bank. New
tables CR.RELATIONSHIP and CR.INTRODUCTION.SOURCE are developed to register the relationships and to indicate the groupings within
the customers.
CR.RELATIONSHIP
CR.RELATIONSHIP

@ID A Unique identifier of Relationship.Length of Key can contain 35 character
RELATIONSHIP.NAME A Description of Relationship.Length can be 50L.Mandatory field for this
table
xx<xx.RISK A Description about the risks associated with the Relationship.
XX>xx.WHY.RISK.ACCEPTED A For each risk, bank details why it considers the risks acceptable
BOOKING.CENTER DAOBOOKING CENTRE FOR THE RELATIONSHIP.THIS FIELD IS LINKED

TO DEPT ACCT OFFICER TABLE.
BRANCH.CODE DAO HOLDS THE DETAILS ABOUT COMPANY IN WHICH RELATIONSHIP
IS AVAILABLE.THIS FIELD IS LINKED TO COMPANY TABLE
REL.MANAGER DAO HOLDS THE DETAILS ABOUT RELATIONSHIP MANAGER.THIS FIELD
IS LINKED TO DAO TABLE
XX.FURTHER.MANAGERS DAO HOLDS THE DETAILS ABOUT SUPPLEMENTARY MANAGERS WHO
ASSIST IN RELATIONSHIP.THIS FIELD IS LINKED TO DAO TABLE
MIS.CODE A HOLDS THE MISC NO ALLOCATED BY BANK MISC SYSTEM. LENGTH
CAN BE 10L ALPHANUMERIC VALUE.
XX<RELATIONSHIP.UPDATE Dropdown OPTIONS ARE NEW PWM RELATIONSHIP, EXISTING PWM RELA-
TIONSHIP, UPDATE TO EXISTING KYC/PERIODIC UPDATE.THIS IS
LINKED TO VIRTUAL EB.LOOKUP TABLE
XX-XX.UPDATE.REASON A HOLDS THE REASON FOR UPDATE
XX>UPDATE.DATE D HOLDS THE DATE OF UPDATE
REL.START.DATE D HOLDS THE DATE FOR START OF RELATIONSHIP.FORWARD VALUE
DATES ARE NOT ALLOWED
HOW.INTRODUCED Check file Linked to new table CR.INTRODUCTION.SOURCE
XX.INTRO.DETAILS A HOLDS THE INTRODUCTION DETAILS
MARKET.INDICATOR Dropdown DROPDOWN FIELD USES EB.LOOKUP TABLE.OPTIONS ARE TARGET
MARKET; NON-TARGET MARKET; SENSITIVE BACKGROUND.
RETROCESSION.PAYMENT Dropdown VALID OPTIONS :YES /NO
XX.RETROCESSION.DETAILS A HOLDS THE RETROCESSION DETAILS TO BE PAID AS RESULT OF
RELATIONSHIP.
XX.REFERENCES A REFERENCES USED IN THE GENERATION OF THIS RELATIONSHIP
XX.PRIMARY.CONTACT A DETAILS ABOUT PRIMARY CONTACT PERSON FOR RELATIONSHIP
MANAGER
CALC.AML.EVALUATION Tick-Box DROPDOWN FIELD USES EB.LOOKUP TABLE.OPTIONS ARE LOW,
MEDIUM, PEP/HIGH
MANUAL.AML.EVALUATION Tick-Box DROPDOWN FIELD USES EB.LOOKUP TABLE.OPTIONS ARE LOW,
MEDIUM, PEP/HIGH
PROFILE.REVIEW.EVAL Tick-Box DROPDOWN FIELD USES EB.LOOKUP TABLE.OPTIONS ARE LOW,
MEDIUM, PEP/HIGH.
XX.REASON.DIFFT.RISK.EVAL A INDICATE REASON WHY CLIENT PROFILE REVIEW CAME UP WITH
A DIFFERENT PROFILE
XX.FOLLOW.UP.REQUIRED A ANY FOLLOW-UP ACTIONS TAKEN BY RM
TAGGING.REQUIRED Dropdown OPTIONS ARE RED-FLAG, STAFF, STAFF-RELATED, OTHER
XX.RESTRICTIONS.REQUIRED A ANY RESTRICTIONS / MONITORING TO BE PLACED ON CLIENT'S
ACCOUNT
CR.INTROLDUCTION.SOURCE
@ID 10,A Unique idenfifier of for source of introduction
DESCRIPTION 50L,A Standard Text field
xx.COMPANY.available COM Hold the details about companies where introduction is
Available. This field is linked to company table.
Campaign Processing
This guide will show you how to use and configure Campaign Processing in order to sell a product. Campaign processing is also called out-
bound processing.
We will now take an example to understand campaign processing. Assume that a new product CAR.LOAN has been created in the Bank and it
is targeted at customers who belong to SECTOR 1001.
The first step is to identify customers who qualify for the product. This is done using rules engine. We need to create rules which specify the
qualifying criteria. Rules are created using RULES ENGINE.
After the rule is created, we must execute the rule to find out the qualifying customers. This done by launching the enquiry EB.RULE.CLIENT.
Let’s take the customer 111512 to see if the customer satisfies the rule, in other words we are about to check if the customer is eligible for the
product.
Now that the customer is eligible for the product, let’s see how to set up outbound processing for this particular customer.
Any campaign should have a workflow associated with it. Banks can decide their own Workflow to process the campaign. There will be two
workflows associated with a campaign. A Sales Workflow and an Origination Workflow, created using the PW module. The Sales Workflow
starts the moment the campaign is instantiated. It comes to an end when the customer confirms his participation in the campaign, and then
the Origination Workflow begins.
The following diagram shows the Overview of the required workflows:
The actual activities that happen during each step of the above algorithm:
From the above diagram, it is clear that the activities that come as part of the sales workflow are:
a. Input Contact details in CR.CONTACT.LOG. - Sending e-mail to identified customers is recorded in this activity.
b. Update CR.CONTACT.LOG with customer’s interest – If the customer is interested in the offer, update the same in CR.CONTACT.LOG.
c. Create CR.OPPORTUNITY record with opportunity details for the customer.
d. Update CR.OPPORTUNITY with customer’s final confirmation.
Activities that are part of the Origination Workflow are:
a. Input Loan Contract in T24
b. Authorize the Loan Contract
Sales Workflow
Activity 1: Creation of CR.CONTACT.LOG
Create an activity which uses a zero authorizer version to input a new record in CR.CONTACT.LOG.
Activity 2: Update CR.CONTACT.LOG with customer’s initial response
Create an activity which uses the above version to record the initial response of the customer in CR.CONTACT.LOG. Allow users to update the
field CONTACT.STATUS in CR.CONTACT.LOG from ‘New’ to ‘Confirmed’ or ‘Pending’. Design the Sales Workflow in such a way, that if the
CONTACT.STATUS is set to ‘Confirmed’, allow the workflow to proceed further, else the workflow should be terminated.
Activity 3: Create an Activity to automatically create a CR.OPPORTUNITY record for customers whose CR.CONTACT.LOG is updated with
‘Confirmed’ status.
Activity 4: Create an activity to update the automatically created CR.OPPORTUNITY record with the customer’s final response. The values
can be ‘ACCEPTED’ or ‘REJECTED’.
Once the Activities are created, the next step is to create the Sales workflow, which is done using PW.PROCESS.DEFINITION.
Origination Workflow
Once the Sales Workflow comes to an end, the Origination Workflow begins, provided the Customer accepts the offer and the CR.O-
PPORTUNITY is updated with the status ‘Accepted’.
Activity 1: This PW.ACTIVITY is used to input the LD Loan contract, only when the customer has accepted the offer i.e. when the Sales Cam-
paign Workflow is completed.
Activity 2: Create an Activity which is used to authorize the LD Loan contact which was input in the previous activity.
After the activities have been defined, we can now define the Origination Workflow which is done using PW.PROCESS.DEFINITION.
CAMPAIGN DEFINITION
So far, all we have done is create a rule to find out Target Customers, create a Sales Workflow and Origination Workflow.
Once done, the next step is to define the Campaign. Definition of campaign involves the linking of the Rule created, the Sales Workflow and the
Origination Workflow.
Campaign is defined in the application CR.OPPORTUNITY.DEFINITION. The same can done by navigating through the menu path
Admin Menu > CRM Administration > Opportunities > Opportunity Definition Manager
The ID of the CR.OPPORTUNITY.DEFINITION record can be any user defined alphanumeric text
GB Short Desc and Description : Holds the description of the campaign
Product : Specifies the product in T24 that is being used in the campaign. Value picked from AA.PRODUCT.CATALOG
Direction : Specifies whether it is a campaign (Outbound) or opportunity (Inbound) processing
Qual Rule : Qualification Rule.T24 rule that evaluates whether a customer qualifies for the rule or not. If the rule variable RULE.STATUS
returns a value TRUE for the customer, the customer qualifies for the rule. RULE.STATUS is the only rule variable that is checked at this stage.
Must have an entry in EB.RULE application
Prob Rule : Probability Rule. Rule to be applied to calculate the probability that the opportunity will be accepted by the customer, if the cus-
tomer qualifies for the product. This rule will be initiated and the result placed on the Opportunity record. Must have an entry in the EB.RULE
application. The rule variable RULE.MESSAGE is used for this purpose.
Value Rule : Rule to be applied to calculate the value that will be stored when the opportunity will be accepted by the customer, if the cus-
table. The rule value RULE.SCORE is used for this purpose.
You can create 3 different rules which return values such as RULE.STATUS, RULE.MESSAGE and RULE.SCORE.
These can then be attached to the three fields that we had just discussed. Alternatively, you can define one rule which returns all the three
values and specify the same rule name in all the 3 fields.
Oppor Channel : Contains the means of communication or execution of the opportunity. Should be a valid record in the EB.CHANNEL appli-
cation
Oppor Workflow : Contains the name of the Sales Workflow
Trigger Status : This is a crucial field to understand. We know that when the ‘Opportunity Status’ in the CR.OPPORTUNITY record is set to
ACCEPTED, the Origination workflow will get triggered. There is more to this. Only if the Opportunity Status field in the CR.OPPORTUNITY
record matches the value in this field, will the Origination workflow be triggered. This way, we are controlling at the opportunity definition
level, when the sales workflow ends and when the origination workflow commences.
This field should contain one of the valid values of the field Opportunity Status in CR.OPPORTUNITY.
Orig Process : Contains the name of Origination Workflow
OFS Source : Contains the OFS.SOURCE ID that will be used in OFS.PROCESSING. have the source type set to GLOBUS. You will learn
more about this in the section on a background process named CR.CAMPAIGN.PROCESSING
OFS Version : Zero authorizer version of the PW.PROCESS application. You will learn more about this in the section on a background proc-
ess named CR.CAMPAIGN.PROCESSING
Next step is to instantiate the campaign. This is done using the application CR.CAMPAIGN.GENERATOR. Alternately, this can be accessed by
navigating through the menu path
Admin Menu > CRM Administration > Opportunities > Generate Campaign Opportunities
This application is used to select a group of Customers in conjunction with the Campaign definition specified in CR.O-
PPORTUNITY.DEFINITION. It is used to generate a number of Opportunities. An additional role is to generate the contexts that need to be
passed to the Rules Engine for evaluation, when determining for which Customers, Opportunities need to be generated.
Short Description and Description contain description of the generator.
Oppor Def field contains ID of the CR.OPPORUNITY.DEFINITION record, which will be used to generate the Campaign.
Camp Start Date field refers to the start date of the campaign i.e. Date before which this campaign cannot be instantiated
Camp End Date field refers to the campaign end date i.e. Date after which this campaign cannot be instantiated
PRIM.CTX.TBL, FLD, OPR, CRI fields compare this to fixed selection in the ENQUIRY application. Using these set of fields, we can spec-
ify selection criteria that will be executed before the rules specified in the CR.OPPORTUNITY.DEFINITION record are deployed. Specify the
application name in the field Primary Context Table and the conditions to be executed in Selection Field or Operator or Criteria. In the sample
screen shot above, the Context passed to the Rules Engine is the CUSTOMER application with ID equal to 111512.
CUST.CTX.FLD holds the field name in the application specified in the Primary Context Table that holds the Customer ID, since Primary
Context Table itself is CUSTOMER, its @ID has been specified as the Customer Content Field.
LINKED.CTX.FLD: The linked context is a no input field and is populated based on the context specified in the rule. Since the rule is based
on the CUSTOMER application, you see a value CUSTOMER specified here. The field @ID is specified to denote that this is the field that con-
tains the Customer number in the application specified in Linked Context.
Campaign Execution
The next step is the execution of Campaign. Once the Campaign Generator record has been defined, in order to trigger Campaign Processing it
needs to be verified, since CR.CAMPAIGN.GENERATOR is a ‘W’ type of application.
Once the record is verified, the ‘Iter Status’ field is set to ‘PENDING’, denoting that the Campaign processing has been instantiated.
Next step is to start the service BNK/CR.CAMPAIGN.PROCESSING. Running this service creates an OFS string to create a PW.PROCESS rec-
ord for the Sales Workflow, which is part of the Campaign Processing.
After execution of the service, the OFS string is created, and the ‘Iter.Status’ field in CR.CAMPAIGN.GENERATOR is changed to ‘GEN-
ERATED’.
This OFS string is stored in a file called F.OFS.MESSAGE.QUEUE. This OFS string is used to create a record in PW.PROCESS for the Sales
Workflow.
Once the OFS string is created, we need to process it, so that the PW.PROCESS record is created, and thus the Sales Workflow can be started.
To process the OFS string, we need to run the service OFS.MESSAGE.SERVICE.
After the execution of the service the Sales Workflow is started. This reflects in the SCV, under the ‘Active Process’ sub tab in the Customer
tab.
To execute the activities in the Sales Workflow, we can either run the enquiry ENQ TODO.LIST, or click on the highlighted icon in the above
screenshot.
So the first activity as defined is to ‘Create a New Customer Contact’. This is done when the target customer is sent an email regarding the
Opportunity that he or she can avail of.
Once this activity is executed, the ‘Contacts’ tab in the SCV is updated with the Customer Contact that we created.
After execution of the first activity, the ‘Active Process’ tab in the SCV displays the next Activity which is ready to be executed in the Sales
Workflow.
So the next activity is Update Customer Contact. This activity is executed when the Customer is interested in the offer. This is done by chang-
ing the ‘Contact.Status’ from ‘New’ to ‘Confirmed’
The next activity is to create the CR.OPPORTUNITY record. This is an AUTO activity, i.e. the Activity.Type field will have the value as ‘AUTO’.
To execute this auto activity we must run the service PW.MAPPING.
Once the activity is executed the CR.OPPORTUNITY record is created. This is reflected in the SCV under the ‘Opportunities’ Tab.
After creation of CR.OPPORTUNITY, when the customer confirms participation in the Campaign, the Status field in CR.OPPORTUNITY
should be changed to ‘ACCEPTED’, this denotes the end of the Sales Workflow and triggers the Origination Workflow.
Once the Sales Workflow is over the Origination workflow is triggered. To execute the Origination Workflow, we need to create a record in
PW.PROCESS
This is can be achieved by running the service CR.CAMPAIGN.PROCESSING and OFS.MESSAGE.SERVICE.
CR.CAMPAIGN.PROCESSING once executed, creates the OFS string to create a record in PW.PROCESS. To process the OFS string, we need
to run the service OFS.MESSAGE.SERVICE.
Using this PW.PROCESS record, the Origination Workflow is instantiated, which is reflected in the SCV as shown in the below screen shot.
Again to execute the activities in the Origination Workflow, execute the enquiry TODO.LIST, or use the icon highlighted in the above picture.
Completion of the first activity prompts the second activity to be executed.
The Loan Contract must be authorised. With this, the product associated with the Campaign can be processed in T24.
Campaign Reporting
This section explains the reporting of campaigns run by different branches in the bank for branch management, area management, marketing on
their home pages to track the progress of the campaign.
In this scenario, the reports of the following campaigns are provided to the bank management.:
l Short Term Fixed Deposit

l ARC IB Access
Short Term Deposit Campaign
This campaign (STFD.CAMPAIGN) is targeted at customers who satisfy the following rules listed below:
l If the Savings Account has Account Category = 6000, 6001, 6003, 6004, 6005
l If the balance of this Savings Bank (SB) Account is greater than 5000, then the rule status is set to True.
ARC IB Access Campaign
This campaign (ARCIB.ACCESS.CAMPAIGN) is targeted at individual customers who do not access ARC Internet Banking and satisfy the fol-
lowing rules:
l If the customer is belonging to Sector = 1001 (Individual)

l If the field INTERNET.BANKING.SERVICES is equal to Null, then the rule status is set to True.
Define these rules for STFD.CAMPAIGN abd ARCIB.ACCESS.CAMPAIGN and attach them to CR.OPPORTUNITY.DEFINITION.
Note: Here, Short Term Deposit (STFD.CAMPAIGN) is chosen for explaining the campaign reporting.
After defining the opportunities, Campaign is started using CAMPAIGN.GENERATOR . Below is the navigation path to CAM-
PAIGN.GENERATOR:
Admin Menu > CRM Administration > Opportunities > Generate Campaign Opportunities
Based on CR.OPPORTUNITY records with different status, a service CR.CAMPAIGN.DETAILS should run on or before COB to create/update
records in CR.CAMPAIGN.STATISTICS.
CR.CAMPAIGN.STATISTICStable is used to store the details of the opportunities on a daily basis based on the progress of the campaign. Each
record of the CR.CAMPAIGN.STATISTICS is identified by an unique auto-generated @ID. The table can not be manually recorded by user and
hence it will be a live table.
Short Term Deposit Campaign
The field descriptions of the CR.CAMPAIGN.STATISTICS are given below :
BANK.ID: This field stores ID of the master company.
CAMPAIGN.ID : This field stores the campaign generator ID. It can be STFD.CAMPAIGN for Short Term Deposit or ARCIB.A-
CCESS.CAMPAIGN for ARC IB access.
START.DATE: Specifies Start Date of the campaign.
END.DATE: Specifies End Date of the campaign.
LENGTH.IN.DAYS: This field stores the period of the campaign based on the Start Date and the End Date.
COMPANY.1:This field stores the ID of the Branch Company. This is a multi-value set.
STATUS.1.1:This field stores the opportunity with the status specified in CR.OPPORTUNITY.STATUS.
OPP.COUNT.1.1: Specifies the total opportunity count for status.
LEAD.COMPANY.1: This field stores the ID of the Lead Company. This is a multi-value set.
COMP.TOTAL .OPP.1: Specifies the total opportunity count created for the company. This field is a multi-value set.
CHANNEL.1: This field stores the channels through which the campaign was run. This field is a multi-value set.
CH.STATUS.1.1: This field stores the opportunity with the status specified in CR.OPPORTUNITY.STATUS.
CH.OPP.COUNT.1.1:Specifies the count of opportunities created through channel for a particular status.
CH.TOTAL.OPP.1: Specifies the count of opportunities created through channel. This field is a multi-value sub set.
TOTAL.BANK.OPP:Specifies the total opportunities created for the bank/ Master company under different branch companies.
LAST.UPDATED: Specifies the last updated date of the Campaign report.
Opportunity Processing
This User Guide will show you how to use and configure Opportunity Processing in order to sell a product. Opportunity processing is also
called as inbound processing.
Let us take an example to understand opportunity processing. Assume that a new loan product has been created in the Bank and it is targeted
at customers who belong to SECTOR 1001.
Let us take the product CAR.LOAN as an example.
The first step is to identify customers who qualify for the product. This is done using rules engine. We need to create rules which contain the
qualifying criteria. Rules are created using RULES ENGINE.
Once the rule is created, we must execute the rule to find out the qualifying customers. This done by launching the enquiry, EB.RULE.CLIENT
Let’s take the customer 111530 to see if the customer satisfies the rule, in other words we are about to check if the customer is eligible for the
product.
Now that the customer is eligible for the product, let’s see how to set up inbound processing for this particular customer.
Opportunity processing will have workflows associated with it. Banks can decide their own Workflow to process the campaign. There will be
two workflows associated with a campaign. A Sales Workflow and an Origination Workflow, created using the PW module. The Sales Workflow
starts the moment the campaign is instantiated. It comes to an end when the customer confirms participation in the campaign. The Origination
Workflow begins after the sales workflow.
The following algorithm shows an overview of the required workflows:
The actual activities that happen during each step of the above algorithm:
From the above diagram, we can see that the activities that are part of the Sales workflow are:
a. Update CR.OPPORTUNITY record, with a status as CAMP.GENERATED. This is an ‘Auto’ activity.
b. Create a CR.CONTACT.LOG for the Customer. This is an ‘Auto’ activity as well.
c. Update CR.CONTACT.LOG with status ‘Confirmed’.
d. Update CR.OPPORTUNITY with customer’s final confirmation.
Activities that are part of the Origination Workflow are:
a. Input Loan Contract in T24
b. Authorize the Loan Contract
Sales Workflow
Activity 1: Updating CR.OPPORTUNITY with the status as CAMP.GENERATED. This is an auto activity.
Activity 2: Create a record for the customer in CR.CONTACT.LOG. This is also an auto activity.
Activity 3: Update CR.CONTACT.LOG with customer’s interest.
Activity 4: Update the CR.OPPORTUNITY with customer’s final confirmation.
Once the Activities are created, the next step is to create the Sales workflow, which is done using PW.PROCESS.DEFINITION.
Origination Workflow
Once the Sales Workflow comes to an end, the Origination Workflow begins, provided the Customer accepts the offer and the CR.O-
PPORTUNITY is updated with the status ‘Accepted’.
Activity 1: Create an activity to create a LD loan record.
Activity 2: Create an Activity to authorize the LD Loan contact that was input in the previous activity.
After the activities in Sales Workflow have been defined, we can now define the Origination Workflow.
OPPORTUNITY DEFINITION
So far, we have created
• A rule to find out Target Customers,
• Sales Workflow
• Origination Workflow
The next step is to define the Opportunity. Definition of opportunity involves the linking of the Rule created, the Sales Workflow and the Orig-
ination Workflow.
Inbound Opportunities are defined in the application CR.OPPORTUNITY.DEFINITION. The same can done by navigating through the menu
path
Admin Menu > CRM Administration > Opportunities > Opportunity Definition Manager
For explanation of the fields in the above application, refer to the Campaign Processing guide.
Next step is to instantiate the Inbound Opportunity. This is done using the application CR.OPPORTUNITY.GENERATOR. Alternately, this
can be accessed by navigating through the menu path
Admin Menu > CRM Administration > Opportunities > Generate Propensity Opportunities
Once the record is verified, the Inbound Opportunity is Instantiated.
The next step is to start the service CR.OPPORTUNITY.PROCESSING.
By running the service CR.OPPORTUNITY.PROCESSING an Opportunity record for the target customers with the ‘Direction’ as Inbound is
created automatically. This is reflected in the target customer’s Single Customer View as shown in the below screenshot.
This denotes that the customer is a qualified customer for the product.
Now when the customer calls the bank for an enquiry, the bank staff need to intimate the customer about the offer by viewing the customer’s
SCV.
If the customer is interested in that offer, the bank must send him an email or probably fix an appointment. This must be recorded in T24
(CR.CONTACT.LOG). Before we record the contact we need to change the ‘Direction’ in CR.OPPORTUNITY from ‘Inbound’ to
‘Outbound’.
After this is done, the service CR.OPPORTUNITY.PROCESSING must be started again. This is done to create a process for the Sales Work-
flow. After executing the service CR.OPPORTUNITY.PROCESSING, you will find an OFS string being created, which is stored in the file
OFS.MESSAGE.QUEUE.
To process the above OFS message, you must start the service OFS.MESSAGE.SERVICE. The OFS string is responsible for creating the
PW.PROCESS record for the sales workflow.
The screenshot below shows a Process being created for the Sales Workflow in the target customer’s SCV.
The first activity is an ‘Auto’ activity. To execute an Auto activity, you need to run the service PW.MAPPING. Upon execution of the activity,
you will notice that the ‘Oppor Status’ in CR.OPPORTUNITY changes to ‘CAMP.GENERATED’.
Once the first activity is over, it triggers the second activity. The second activity is to create a Contact Log for the customer. This is also an
Auto activity, which means that you need to start the service PW.MAPPING again.
Once activity 2 is over, the third activity is triggered, which is a manual activity. This third activity is to update the Status of Contact Log from
‘New’ to ‘Confirmed’.
The next activity is also a manual activity. Here you have to change the status in CR.OPPORTUNITY to ACCEPTED.
This marks the end of the Sales Workflow, and it triggers the Origination Workflow.
To start the Origination Workflow, we need to start the services CR.OPPORTUNITY.PROCESSING and OFS.MESSAGE.SERVICE. Once these
services are run, a process is initiated for the Origination Workflow.
This is reflected in the SCV of the customer.
The first activity is a manual activity. It is to create a loan.
End of first activity triggers the second activity. The second activity is to authorize the loan that was created in the previous activity.
This is how an Inbound opportunity is executed.
Note: All the services that were run so far had their respective Service.Control field set to ‘START’ in their TSA.SERVICE record. But in a live
scenario, these services are set to ‘AUTO’.
CR.OPPORTUNITY.PARAMETER
CR.OPPORTUNITY.PARAMETER defines the rules for handling opportunity records. The role of this table is to define the actions that should
be performed if the system is looking to raise a new opportunity, and there is already an opportunity stored for that customer for that product.
In this case, the actions the system could follow are:
• skip this record (leave the existing opportunity intact)
• replace this record (close the existing opportunity, add a new opportunity)
• duplicate the opportunity (leave the existing opportunity intact, raise a new opportunity)
PROP.OVERWRITE : This multivalue set describes what will be done when there is an existing campaign/propensity/customer initiated
opportunity (depending on the selection in this field) for a particular product, and the sales opportunity functionality is proposing to overwrite
it with a propensity-generated opportunity for the same product. Options are Propensity and Campaign. If left blank, this defines the ‘catchall’
setting for all products not defined.
PROP.PRIOR : This field contains every possible status that a pre-existing opportunity can hold
PROP.ACTION : Action to be done for above Opportunity that is to be created. The possible values are
• Skip this record (leave the existing opportunity intact)
• Overwrite this record (close the existing opportunity, add a new opportunity)
• Duplicate the opportunity (leave the existing opportunity intact, raise a new opportunity)
CAMP.OVERWRITE : This multivalue set describes what will be done when there is an existing campaign/propensity/customer initiated
opportunity (depending on the selection in this field) for a particular product, and the sales opportunity functionality is proposing to overwrite
it with a campaign-generated opportunity for the same product.
CAMP.PRIOR : This field contains every possible status that a pre-existing opportunity can hold
CAMP.ACTION : Action to be done for above Opportunity that is to be created
REJECTED.PERIOD: For an opportunity, the period during which the customer should not have a new opportunity raised, if a previous
opportunity for the same product has already been declined . The duration is in C = Calendar Days; D = Working Days; W = Weeks; M =
Months
PERIOD: Period field indicates duration of time over which the number of outbound opportunities should be measured. Outbound oppor-
tunities which are generated as a result of customers responding positively to an inbound opportunity should not be counted in this period
MAX.OB.OPPOR: Number of opportunities that can be defined in the above period.
OPPOR.STATUS : Status of opportunities that are to be archived after the number of days specified in DAYS.PAST.EXPIRY field. This is a
no input field
DAYS.PAST.EXPIRY : Number of days after which opportunities need to be purged
1) When a new inbound opportunity (Propensity) is to be generated for a customer, check if an inbound opportunity already exists for the cus-
tomer. If an inbound opportunity exists for the customer and if the status of that opportunity is ‘Not Communicated Yet’, then create the new
inbound opportunity as the ‘Prop Action’ field is set to DUPLICATE.
When a new inbound opportunity (Propensity) is to be generated for a customer, check if an inbound opportunity already exists for the cus-
tomer. If an inbound opportunity exists for the customer and if the status of that opportunity is ‘ACCEPTED’, then do not create the new
inbound opportunity as the ‘Prop Action’ field is set to SKIP.
When a new inbound opportunity (Propensity) is to be generated for a customer, check if an inbound opportunity already exists for the cus-
tomer. If an inbound opportunity exists for the customer and if the status of that opportunity is ‘REJECTED’, then overwrite the existing
opportunity with the new inbound opportunity as the ‘Prop Action’ field is set to OVERWRITE.
2) When a inbound opportunity (Propensity) is to be generated for a customer, check if an outbound opportunity already exists for the cus-
tomer. If an outbound opportunity exists for the customer, irrespective of the status of that opportunity, don’t create a new inbound oppor-
tunity for the customer as the ‘Prop Action’ field is set to SKIP.
3) When a new outbound opportunity (Campaign) is to be generated for a customer, check if an outbound opportunity already exists for the
customer. If an outbound opportunity exists for the customer and if the status of that opportunity is ‘Awaiting sales workflow’, the anyway
create the new outbound opportunity as the ‘Prop Action’ field is set to DUPLICATE.
When a new outbound opportunity (Campaign) is to be generated for a customer, check if an outbound opportunity already exists for the cus-
tomer. If an outbound opportunity exists for the customer and if the status of that opportunity is anything other than ‘Awaiting sales work-
flow’, then don’t create the new outbound opportunity as the ‘Prop Action’ field is set to SKIP.
4) When a new outbound opportunity (Campaign) is to be generated for a customer, check if an inbound opportunity already exists for the cus-
tomer. If an inbound opportunity exists for the customer, irrespective of the status of the opportunity, don’t create a new outbound oppor-
tunity as the ‘Prop Action’ field is set to SKIP.
Real Time Opportunity Processing
This section explains the generation and processing of Opportunity in real time.
The generation of the real time opportunities involves the following steps:
l Defining a set of rules for each opportunity using T24 Tool box
l Creating new record in CR.OPPORTUNITY.DEFINITION and attaching the rules
l Adding the application/version name along with the CR.OPPORTUNITY.DEFINITION @ID in the application CR.O-
PPORTUNITY.PARAMETER
Defining Rules using T24 Tool box

A set of rules is defined for the following opportunities using T24 tool box:
l Short Term Fixed Deposit

l Long Term Fixed Deposit
l Overdraft Account
Short Term Fixed Deposit
The rules for satisfying the Short Term Fixed Deposit (APPLY.STFD.RT) are listed below:
l Check 1: Is it a Savings Account (Account Category = 6000, 6001, 6003, 6004, 6005).
l Check 2: If the balance of this Savings Account is greater than 5000, then the rule status is set to “True”.
Long Term Fixed Deposit
The rules for satisfying the Long Term Fixed Deposit (APPLY.LTFD.RT) are listed as follow:
l Check 2: If the balance (Online Working Balance from ECB) of this Savings Account is greater than 10000, then the rule status is set
to “True”.
Overdraft Account
The following are the rules for satisfying the Overdraft Account (APPLY.OD.RT):
l Check 2: Customer of the account should be a Retail HNI customer. In the customer record the field CUSTOMER.STATUS = 3.
l Check 3: Customer’s age is not less than18.
l Check 4: If the balance (Online Working Balance from ECB) of this Savings Account is less than zero, then the rule status is set to
“True”.
Attaching Rules in CR.OPPORTUNITY.DEFINITION

A new record is created for each Opportunity in CR.OPPORTUNITY.DEFINITION and the corresponding rules are attached to it. The navi-
gation to the CR.OPPORTUNITY.DEFINITION is as follow :
Click Admin Menu --> CRM Administration --> Opportunities --> Opportunities definition Manager
Select Deposits--> Term Deposits --Long Term Deposit --> Apply for Long Term Deposit in T24 product Browser screen.
Note: Here, Long Term Deposit is chosen as an example for attaching the rules at definition level. Below shows the screen shot of the rec-
ord created for Long Term Fixed Deposit.
CR.OPPORTUNITY.DEFINITION record
The ID of the CR.OPPORTUNITY.DEFINITION record can be any user defined alphanumeric text.
GB Short Desc and Description : Holds the description of the opportunity
Product : Specifies the product in T24 that is being used in the opportunity. Value picked from AA.PRODUCT.CATALOG
Direction : Specifies whether it is a campaign (Outbound) or opportunity (Inbound) processing
Qual Rule : Qualification Rule.T24 rule that evaluates whether a customer qualifies for the rule or not. If the rule variable RULE.STATUS
returns a value TRUE for the customer, the customer qualifies for the rule. RULE.STATUS is the only rule variable that is checked at this stage.
Must have an entry in EB.RULE application
Prob Rule : Probability Rule. Rule to be applied to calculate the probability that the opportunity will be accepted by the customer, if the cus-
application. The rule variable RULE.MESSAGE is used for this purpose.
Value Rule : Rule to be applied to calculate the value that will be stored when the opportunity will be accepted by the customer, if the cus-
table. The rule value RULE.SCORE is used for this purpose.
Oppor Channel : Contains the means of communication or execution of the opportunity. Should be a valid record in the EB.CHANNEL appli-
cation
Oppor Workflow : Used only for opportunity creation.
Trigger Status : This is not applicable.
Orig Process : Used only for opportunity creation.
OFS Source : Contains the OFS.SOURCE ID that will be used in OFS.PROCESSING. have the source type set to GLOBUS. You will learn
more about this in the section on a background process named CR.CAMPAIGN.PROCESSING
OFS Version : Zero authorizer version of the PW.PROCESS application. You will learn more about this in the section on a background proc-
ess named CR.CAMPAIGN.PROCESSING
Rt Start Date: Specifies the date from when a particular opportunity will be available to customer. This field is applicable only for real time
opportunities.
Rt Duration: Specifies the duration of the days for which a particular opportunity will be available for the customer. This field value only
applicable for real time opportunities.
Adding Application / Version name along with definition record in CR.OPPORTUNITY.PARAMETER

The definition record is attached with Version or Application name in CR.OPPORTUNITY.PARAMETER, after the records are created.
1. Provide Real Time related details like Composite Screen name (Rt Opp Cos) and Rejected Period in parameter level.
CR.OPPORTUNITY.PARAMETER defines the rules for handling opportunity records. The role of this table is to define the actions that should
be performed if the system is looking to raise a new opportunity, and there is already an opportunity stored for that customer for that product.
In this case, the actions the system could follow are:
• skip this record (leave the existing opportunity intact)
• replace this record (close the existing opportunity, add a new opportunity)
• duplicate the opportunity (leave the existing opportunity intact, raise a new opportunity)
CR.OPPORTUNITY.PARAMETER
Prop Overwrite : This multivalue set describes what will be done when there is an existing campaign/propensity/customer initiated oppor-
tunity (depending on the selection in this field) for a particular product, and the sales opportunity functionality is proposing to overwrite it
with a propensity-generated opportunity for the same product. Options are Propensity and Campaign. If left blank, this defines the ‘catchall’ set-
ting for all products not defined.
Prop Prior : This field contains every possible status that a pre-existing opportunity can hold.
Prop Action : Action to be done for above Opportunity that is to be created. The possible values are
l Skip this record (leave the existing opportunity intact)
l Overwrite this record (close the existing opportunity, add a new opportunity)
l Duplicate the opportunity (leave the existing opportunity intact, raise a new opportunity)
Camp Overwrite : This multivalue set describes what will be done when there is an existing campaign/propensity/customer initiated oppor-
tunity (depending on the selection in this field) for a particular product, and the sales opportunity functionality is proposing to overwrite it
with a campaign-generated opportunity for the same product.
Camp Prior : This field contains every possible status that a pre-existing opportunity can hold
Camp Action : Action to be done for above Opportunity that is to be created
Rejected Period: For an opportunity, the period during which the customer should not have a new opportunity raised, if a previous oppor-
tunity for the same product has already been declined . The duration is in C = Calendar Days; D = Working Days; W = Weeks; M = Months
Period: Period field indicates duration of time over which the number of outbound opportunities should be measured. Outbound oppor-
tunities which are generated as a result of customers responding positively to an inbound opportunity should not be counted in this period
Max Ob Oppor: Number of opportunities that can be defined in the above period.
Oppor Status : Status of opportunities that are to be archived after the number of days specified in DAYS.PAST.EXPIRY field. This is a no
input field
Days Past Expiry : Number of days after which opportunities need to be purged
Application: Specifies name of the T24 application for which real-time opportunities to be triggered. It is mutually exclusive with the field
“VERSION”
Version: Specify the Versions for which real-time opportunities to be generated. It is mutually exclusive to APPLICATION name field. All sub
value field should contain versions belonging to one application.
Customer Field: Specifies the field which holds the customer code in Application/ Version. It is mutually exclusive with ACCOUNT.FIELD.
Account Field:Specifies the field which holds the account number in Application/Version. It is mutually exclusive with CUSTOMER.FIELD.
Oppor Id:This field specifies the Opportunity generator id which gets triggered on committing.
Rt Opp Cos: This field specifies the composite screen name to be displayed when the real-time opportunities are generated.
Opportunity Generation
The opportunities like Short Term Deposit and Long Term Deposit get triggered when any one of the transactions including Cash
Deposit, Cheque deposit, Cheque encashment, Transfer of funds, Local Cheque clearing, Buying and selling of Travellers cheque is complete.
Overdraft Account opportunity gets triggered when any one of the transactions like bill payment, funds transfer, outward remittance or any
payment is done.
The generation of opportunity is explained using the Teller Transaction Services.
Cash / cheque Transaction
The opportunities are generated for eligible customer based on the rules, and displayed on the transaction complete screen along with below
options :
Transaction Completion
Apply Now
Choose Apply Now if the customer needs the opportunity.
Applying Opportunity
Click Commit to confirm the opportunity selection. The following PW.AF.DEPOSIT version gets invoked and requests the customer to enter
the details for applying the opportunity.
PW.AF.DEPOSIT version
Product
There can be three products (DEPOSIT.SHORT, DEPOSIT.LONG, PREFER.ACCOUNT)
Term
The term for Short Deposit can be from 7 Days to 90 Days and Long Deposit can be from 5 Years to 10 Years.
After committing the PW.AF.DEPOSIT, New Arrangement for the corresponding opportunity gets created and updated with Account details
(Account Title and Account Reference), Commitment details (Amount and Term) and Repayment instructions (as shown below.
New Arrangement for Opportunity
Pay In displays Debit Account Number and Pay Out displays Credit Account Number as mentioned in PW.AF.DEPOSIT version.
New Arrangement - Repayment Instructions (Pay In)
New Arrangement - Repayment Instructions (Pay Out)
On committing the New Arrangement, PW.AF.DEPOSIT with Product applied Successfully message appears on the screen.
Successful Application of Opportunity
May be Later
Click May be Later on transaction complete screen if the customer needs to discuss about the opportunity later. The other available oppor-
tunity will be displayed on the screen
Transaction Completion - May be Later
Transaction Completion - No Opportunities
This opportunity to be discussed later, gets stored in SCV as shown below and it will reappear if the same opportunity is available.
Opportunities displayed in SCV
No Thanks
Choose No Thankson transaction complete screen if the customer declines the opportunity. The declined opportunity disappears from the
screen and the other available opportunity remains on the screen.
Transaction Completion - No Thanks
If No Thanks is clicked for the other opportunity also, then No opportunities for this customer will be displayed as shown below.
Transaction Completion - No Opportunities
The status of the opportunity gets updated as REJECTED. The Rejected Date and Rejection Period are checked if the same opportunity is
regenerated for the same customer. The same opportunity will be regenerated only if the Rejection Period gets exceeded.
More Info
Click More Info if the customer wants to know more about the opportunity. The static html page about the opportunity will be displayed.
Long Term Fixed Deposits - More Info
Short Term Fixed Deposits - More Info
Note: If no option is chosen, the status of each option will be set as NOT.COMMUNICATED.YET. If the customer has chosen one
option, the remaining options will be updated with COMMUNICATED.BUT.NOT.RESPONDED. The opportunities will appear on the
SCV under Opportunities tab if the screen gets closed.

CRM User Guide

Uploaded by

Copyright:

Available Formats

CRM User Guide

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CRM User Guide

Uploaded by

Copyright:

Available Formats

CRM User Guide

CRM is broadly classified into two, they are:

We will now see how to configure CRM.

A customer can be grouped under more than one category also.

Single Customer View (SCV)

Creating a contact for the customer

This application can have various types of IDs. They are:

Valid T24 application name (Example : FUNDS.TRANSFER)

Valid T24 version name (Example : FUNDS.TRANSFER,TRG)

• A prospective customer record is manually modified to activate the customer.

Prospect Management Configuration:

COMPANY – used to define the default setup

Settings in COMPANY record

CR.CONTACT.LOG.PARAM record for ACCOUNT application

A prospect customer is created as shown above.

Customer Record after Account Input

Settings in CR.CONTACT.LOG.PARAM for ACCOUNT application

New Prospect Customer

Creating New Account Record for PROSPECT customer

CUSTOMER.PROSPECT LIVE File

Customer Prospect Record

Client Static Data – Name, profile, goal etc.

Product codes in the SPF

The product must then be included in the COMPANY records as required.

Sequencing for different tables are shown below

CR.CAMPAIGN.OPPORTUNITY – ‘CRCO’YYJJJnnnnn where YY=Year, JJJ=Julian Date and nnnnn=sequence number

The details of the fields added to CUSTOMER are as below

Field Name Type Description

CUSTOMER TABLE CR.PROFILE

Customer profiles are updated by two ways.

TSA SERVICE RECORD FOR CRM

CR.PROFILE.TYPE defines the different types of profiles.

A customer can be grouped under more than one category too.

Screenshot of the rule is given below as part of PW.TRANSITION.

Flow To Setup Customer Profile

The fields added are

1. Phone –Contains the telephone number of the customer.

Customer Single View

1. Customer Information – Basic static information of the customer.

A customer can amend data through the customer single window.

Login Screen For A CRM User Is As Below

Customer Contact Information

The following tables are used for logging the information.

* The following example shows the max history to be 3.

Let us track a mortgage for a customer

We have given the mortgage tracking fields in CR.CONTACT.LOG.PARAM as given above.

A manual entry done directly in CR.CONTACT.LOG table is shown below.

C R .C ON TA C T.LOG.FU TR a nd C R .C ON TA C T.LOG.H IST

C A MPA IGN a nd OPPOR TU N ITY

C R .C A MPA IGN .D EFIN ITION S

*Note: Company Mnemonic will vary according to each bank’s setup.

Once the TSA.SERVICE is completed the record moves to ‘Launched’ status

The TSA.SERVICE also builds a list of opportunity records as explained below.

C R .C A MPA IGN .OPPOR TU N ITY

A prospective customer record is manually modified to activate the customer.

COMPANY – this is used to define the defaults setup

CR.CONTACT.LOG.PARAM – this is used for an application to override the defaults.

Or ACTIVE (blank defaults active)