CRM PDF

TEMENOS T24
CRM
Customer Relationship Management
User Guide
No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.
Copyright 2005 TEMENOS Holdings NV. All rights reserved.

Table of Contents
INTRODUCTION ................................................................................................................................. 4
APPLICATION OVERVIEW................................................................................................................. 5
SETTING UP THE SYSTEM ............................................................................................................... 6
INSTALLATION OF PRODUCT....................................................................................................... 6
CUSTOMER..................................................................................................................................... 8
CR.PROFILE.TYPE ....................................................................................................................... 12
CR.PROFILE.................................................................................................................................. 13
UPDATES TO DE.ADDRESS ........................................................................................................ 18
CUSTOMER SINGLE VIEW .......................................................................................................... 19
CUSTOMER CONTACT INFORMATION ...................................................................................... 21
CR.CONTACT.LOG.PARAM...................................................................................................... 21
CR.OTHER.PRODUCTS............................................................................................................ 25
CR.CONTACT.LOG.FUTR and CR.CONTACT.LOG.HIST ....................................................... 26
CR.CONTACT.LOG.FUTR......................................................................................................... 26
CR.CONTACT.LOG.HIST .......................................................................................................... 28
CAMPAIGN and OPPORTUNITY .............................................................................................. 28
CR.CAMPAIGN.DEFINITIONS .................................................................................................. 28
CR.CAMPAIGN.OPPORTUNITY ............................................................................................... 31
PROSPECT MANAGEMENT......................................................................................................... 33
SET UP .......................................................................................................................................... 34
CUSTOMER PROSPECT .......................................................................................................... 42
CUSTOMER.PURGE ................................................................................................................. 43
SALES OPPORTUNITY MANAGEMENT ......................................................................................... 44
Overview of Input and Processing ................................................................................................. 44
Definition and input of parameters and controls......................................................................... 44
COMPANY and LOCKING file ....................................................................................................... 44
CR.OPPORTUNITY. PARAMETER ........................................................................................... 45
CR.OPPORTUNITY.DEFINITION .............................................................................................. 46
CR.OPPORTUNITY.GENERATOR............................................................................................ 47
CR.CAMPAIGN.GENERATOR .................................................................................................. 50
CR.CUST.OPPOR.HIST ............................................................................................................ 51
CR.OPPORTUNITY.................................................................................................................... 51
CR.OPPORTUNITY process creation for propensity ................................................................. 54
CR.OPPORTUNITY process creation for Campaign ................................................................. 54
Enquiry for CR.OPPORTUNITY ................................................................................................. 60
TEMENOS T24 User Guide

Page 2 of 66
Relationship Table.......................................................................................................................... 61

Page 3 of 66
INTRODUCTION
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 CRM systems has been around for a long time and it is now more relevant than ever.
Whilst TEMENOS T24 does not currently have a “CRM Module” it has the potential to offer significant
CRM functions by virtue of its client centric and integrated nature. However, this capability has yet to
be fully exploited and this document sets out to propose a number of enhancements that would
transform TEMENOS T24 from a world class back office system to a leading integrated front and back
office solution.

Page 4 of 66
APPLICATION OVERVIEW
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 system 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.

Page 5 of 66
SETTING UP THE SYSTEM

INSTALLATION OF PRODUCT
On receipt of the product code this must be entered into the SPF file called SYSTEM.
Figure 1 Product codes in the SPF
The product must then be included in the COMPANY records as required.

Page 6 of 66
Figure 2 – 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.
Figure 3 – 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

Page 7 of 66
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

35,A
XX<PROFILE.TYPE Linked to PROFILE.TYPE table
NOINPUT
35,A
XX>PROFILE Linked to PROFILE table
NOINPUT
Can have any of these values
TITLE 6 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
Linked to the virtual table MARITAL.STATUS in
MARITAL.STATUS 11 EB.LOOKUP
NO.OF.DEPENDENTS 2
PHONE.1 17,ANY
SMS.1 17,ANY
EMAIL.1 35,ANY
Linked to the virtual table EMPLOYMENT.STATUS
XX<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- 11,D

Page 8 of 66
EMPLOYMENT.START
XX-
CUSTOMER.CURRENCY 3,CCY
XX-SALARY 10
XX-ANNUAL.BONUS 10
17,FQU
XX>SALARY.DATE.FREQ
NET.MONTHLY.IN 10
NET.MONTHLY.OUT 10
Linked to the virtual table RESIDENCE.STATUS in
35 EB.LOOKUP
XX<RESIDENCE.STATUS
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
to Added for future use
XX.RESERVED01 NOINPUT

Page 9 of 66
Profile Type
Figure 4 – CUSTOMER TABLE CR.PROFILE

Page 10 of 66
Figure 5 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 template 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.

Page 11 of 66
Figure 6 – 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.
Figure 7 – CR.PROFILE.TYPE TABLE

Page 12 of 66
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.
Figure 8 – CR.PROFILE TABLE
Screenshot of the rule is given below as part of PW.TRANSITION.
PW.TRANSTION
Rules for CR.PROFILE’ s are setup through an application called PW.TRANSITION (refer :
Process Workflow user guide)

Page 13 of 66
Figure 9 – PW.TRANSITION RULE

Page 14 of 66
Figure 10 – CUSTOMER RECORD DISPLAYING NEW FIELDS

Page 15 of 66
Figure 11 – CONT.
Flow to setup Customer profile

Page 16 of 66
CR.PROFILE.TYPE
CR.PROFILE
PW.TRANSITION
CUSTOMER
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.

Page 17 of 66
UPDATES TO DE.ADDRESS
A few fields have been updated in DE.ADDRESS reflecting the contact details for a customer
Figure 12 – 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.

Page 18 of 66
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 thecustomer.

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 payments 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.
Figure 13 -SINGLE CUSTOMER VIEW

Page 19 of 66
CRM users have to have access to only the above mentioned window. To setup, create a record for
the required user in BROWSER.PREFERENCES indicating the main screen as CRM.START
Figure 14 – BROWSER.PREFERENCES

Page 20 of 66
Login screen for a CRM user is as below.
Selecting a customer can be done using any of the fields shown below.
Figure 15 – 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.
CR.CONTACT.LOG.PARAM
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.

Page 21 of 66
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.
Figure 16 – CR.CONTACT.LOG.PARAM
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.
Figure 17 – CR.CONTACT.LOG.PARAM

Page 22 of 66
Example
Let us track a MORTGAGE for a customer
Figure 18 – MORTGAGE RECORD FOR TRACKING CONTRACT LOG

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

Page 23 of 66
Figure 19 –CR.CONTACT.LOG FROM MORTGAGE RECORD
A manual entry done directly in CR.CONTACT.LOG table is shown below.

Page 24 of 66
Manual update
Figure 20 –MANUAL UPDATE OF CR.CONTACT.LOG
CR.OTHER.PRODUCTS
Sometimes banks wish to record information regarding customers assets/liabilities held outside the
bank. They can be recorded in an application 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.

Page 25 of 66
Figure 21 – CR.OTHER.PRODUCTS
CR.CONTACT.LOG.FUTR and CR.CONTACT.LOG.HIST
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.
CR.CONTACT.LOG.FUTR
The example shows various Logs which are future events.

Page 26 of 66
Figure 22 – CR.CONTACT.LOG.FUTR

Page 27 of 66
CR.CONTACT.LOG.HIST
Figure 23 – CR.CONTACT.LOG.HIST
CAMPAIGN and OPPORTUNITY
A campaign is a event/publicity/contact held by the bank for its customer for the following purposes.
• A product announcement
• Targeting specific type of customers (based on income, location etc).
CR.CAMPAIGN.DEFINITIONS
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.

Page 28 of 66
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 30th Nov to 4th Dec. The record campaign status should contain New status
Figure 24 – CAMPAIGN DEFINITION.

Page 29 of 66
Figure 25 – 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

Page 30 of 66
Figure 26 – CAMPAIGN DEFINITON SHOWING STATUS
The TSA.SERVICE also builds a list of opportunity records as explained below.
CR.CAMPAIGN.OPPORTUNITY
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.

Page 31 of 66
Figure 27 – 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 customer servicing executive.

Page 32 of 66
Figure 28 – 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 prospective 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 CUSTOMER on the relevant
STANDARD.SELECTION record.

Page 33 of 66
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 component 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.CONTACT.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)

Page 34 of 66
Figure 29 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.
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.
Figure 30 CR.CONTACT.LOG.PARAMETER record SYSTEM

Please refer to previous section of CRM User Guide on CR.CONTACT.LOG.PARAM

Page 35 of 66
Figure 31 C R.CONTACT.LOG.PARAMETER record LIMIT

This allows LIMIT input against a Prospect Customer, and will activate this Customer.
Figure 32 CUSTOMER.PROSPECT

Page 36 of 66
Figure 33 CUSTOMER record

Note that a LIMIT may be input against this Prospect Customer 900288 and will activate it.
Figure 34 LIMIT record

Page 37 of 66
Figure 35 LIMIT

Page 38 of 66
Figure 37 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.
Figure 38 CR.CONTACT.LOG.PARAMETER

Page 39 of 66
Figure 39 CUSTOMER.SECURITY
This inhibits the input of a Prospect Customer as a CUSTOMER. SECURITY.
Figure 40 COMPANY
Figure 41 CR.CONTACT.LOG.PARAMETER

Page 40 of 66
Figure 42 CUSTOMER PROSPECT
Figure 43 LOANS.AND.DEPOSITS record.

Note that if System default is NO prospect allowed, it cannot be overridden .

Page 41 of 66
CUSTOMER PROSPECT
Figure 44 CUSTOMER.PROSPECT list

Page 42 of 66
Figure 46 CUSTOMER An example of a prospect Customer 900287
CUSTOMER.PURGE
This is done during the Close of Business process, to remove the Prospect customers that have had
no contact for the retention period.
Figure 47 List of customers who are prospective.

Page 43 of 66
Figure 48 Enquiry on Customer who has passed retention period.
Figure 49 Customer has been deleted

Prospect Customers that have passed Retention period are completely deleted.
SALES OPPORTUNITY MANAGEMENT

Overview of Input and Processing
Definition and input of parameters and controls
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.
Figure 50 Company record
Figure 51 Locking record

Page 44 of 66
Figure 52 Locking record
CR.OPPORTUNITY. PARAMETER
This file contains details regarding the initial setup needed for both Propensity and Campaigns that
lead to the final creation of CR.OPPORTUNITY. 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.COMMUNICATED.YET
Figure 53 – 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

Page 45 of 66
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 Duplicate, 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 duplicate 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 records 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.
CR.OPPORTUNITY.DEFINITION
This file is where we set up the Definitions for both INBOUND and OUTBOUND opportunities.

Page 46 of 66
Figure 54 – 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.PROCESS. 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.COMPANY field specifies for which company the Opportunity will be
created.
CR.OPPORTUNITY.GENERATOR
This file specifies the customers and opportunity templates that should be run in a specific
circumstance. There are multiple different circumstances that could apply. An example would be that
during a Batch an opportunity record could be generated to select a group of customers and run a set
of templates against them, to generate a number of propensity opportunities.

Page 47 of 66
An additional role of the opportunity generator is to generate the contexts that need to be passed to
the rules engine for evaluation, when determining 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 identify 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 application which field indicates the
Customer that should be passed across as well, to evaluate whether they are a Platinum customer.
Figure 55 – CR.OPPORTUNITY.GENERATOR record

Page 48 of 66
The OPPOR.DEF field is linked to the CR.OPPORTUNITY.DEFINITION file. Only an INBOUND

opportunity can be linked to a CR.OPPORTUNITY.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.
Figure 56
Figure 57
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 contexts required by all rules and the opportunity templates must be given a
source ID– an ID from which the relevant data can be derived. Therefore, 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 context. Must be a single value field on Primary context
table.
Figure 58
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 records that are in PENDING status for processing. This is
changed to RUNNING when the records are being processed and moved to GENERATED once
completed.

Page 49 of 66
The START.DAY represents the Starting day of the Opportunity. This should be TODAY or a date
greater than TODAY. Duration which is nothing 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.
CR.CAMPAIGN.GENERATOR
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.
Figure 59 – 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

Page 50 of 66
OUTBOUND opportunities for the Campaign is valid. The Sample size specifies the number of records
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 OPPORTUNITY is
created using the Service is run.
CR.CUST.OPPOR.HIST
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
Figure 60 - 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 PROPENSITY.
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.
CR.OPPORTUNITY
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 generating 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.OPPORTUNITY record that was
created automatically by a Service that was run.

Page 51 of 66
Figure 61 - 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 opportunity. This field will have been validated against both the
opportunity template for available channels, and also the customer profile to determine through which
channels they can be contacted. This field will be cleared when the opportunity is changed from
inbound to outbound.

Page 52 of 66
A sample of a CR.OPPORTUNITY for an OUTBOUND Campaign is shown in the figure below.
Figure 62 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.

Page 53 of 66
CR.OPPORTUNITY process creation for propensity
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.OPPORTUNITY.GENERATOR record is created. We need to verify the record that is created
in this file to move the OPPOR.STATUS to PENDING. 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.
CR.OPPORTUNITY process creation for Campaign
The Process of creating opportunity for Campaigns is different from those of propensity. The process
is the same for the creation of the CR.OPPORTUNITY.DEFINITION and
CR.CAMPAIGN.GENERATOR but the difference lies in the Services that are run to generate the
OPPORTUNITY. 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.
Figure 63- 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.

Page 54 of 66
Figure 64
Above we see the CR.CAMPAIGN.PROCESSING service being run and below we have the
records in the OFS.MESSAGE.QUEUE.
Figure 65
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.MESSAGE.SERVICE
which converts the PW.PROCESS message to actual transactions and updates or writes it in another
file called the OFS.RESPOSE.QUEUE.

Page 55 of 66
Figure 66 - TSA Service - OFS.MESSAGE.SERVICE
The record as seen in the OFS.MESSAGE.QUEUE is shown
Figure 67
Figure 68
The above figure shows the records in the OFS.RESPONSE.QUEUE. The PW.PROCESS record
is also created simultaneously.

Page 56 of 66
Figure 69 – PW.PROCESS
TSA Service - OFS.RESPONSE.QUEUE

Page 57 of 66
Figure 70 - 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.MESSAGE.SERVICE while creating the
PW.PROCESS.
Figure 71

Page 58 of 66
Figure 72 - 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.
Figure 73
This is the final service that is run to generate the CR.OPPORTUNITY for CAMPAIGNS. Once this
service is run the PW.ACTIVITY.TXN record gets updated with few details like the Transaction Ref
of the CR.OPPORTUNITY record and the TARGET.

Page 59 of 66
Figure 74
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 possible. The only
difference here is that the first service to be started in this case is the
CR.OPPORTUNITY.PROCESSING instead of the CR.CAMPAIGN.GENERATOR followed by
OFS.MESSAGE.SERVICE, OFS.RESPONSE.QUEUE and the PW.MAPPING.
Enquiry for CR.OPPORTUNITY
Figure 75 – CR.CUST.OPPORTUNITIES Enquiry

Page 60 of 66
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.
Figure 76
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 Opportunity / 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.

Page 61 of 66
Figure 77 CR.RELATIONSHIP

Page 62 of 66
Figure 78 CR.RELATIONSHIP

Unique identifier of Relationship.Length of Key can
@ID A contain 35 character
Description of Relationship.Length can be
RELATIONSHIP.NAME A 50L.Mandatory field for this table
A Description about the risks associated with the

XX<XX.RISK Relationship.
XX>XX.WHY.RISK.ACCEPTED A For each risk, bank details why it considers the risks

Page 63 of 66
acceptable
Booking centre for the relationship.This field is linked to Dept

BOOKING.CENTER DAO Acct officer table.
Holds the details about company in which relationship is
BRANCH.CODE DAO available.This field is linked to company table
Holds the details about relationship manager.This field is linke
REL.MANAGER DAO to DAO table
Holds the details about supplementary managers who assist i
XX.FURTHER.MANAGERS DAO relationship.This field is linked to DAO table
Holds the MISC no allocated by bank MISC system. Length
MIS.CODE A be 10L Alphanumeric value.
Options are New PWM Relationship, Existing PWM Relations
XX<RELATIONSHIP.UPDATE Dropdown Update to existing KYC/Periodic Update.This is linked to virtu
EB.LOOKUP table
XX-XX.UPDATE.REASON A Holds the Reason for update
XX>UPDATE.DATE D Holds the Date of update
Holds the Date for start of relationship.Forward value dates ar

REL.START.DATE D not allowed
HOW.INTRODUCED Check file Linked to new table CR.INTRODUCTION.SOURCE

A Holds the Introduction details
XX.INTRO.DETAILS
Dropdown field uses EB.LOOKUP table.Options are Target

MARKET.INDICATOR Dropdown Market; Non-Target Market; Sensitive background.
RETROCESSION.PAYMENT Dropdown Valid options :YES /NO
A Holds the Retrocession details to be paid as result of relations

XX.RETROCESSION.DETAILS
XX.REFERENCES A References used in the generation of this relationship
XX.PRIMARY.CONTACT A Details about primary contact person for relationship manage

Page 64 of 66
Dropdown field uses EB.LOOKUP table.Options are Low,

CALC.AML.EVALUATION Tick-Box Medium, PEP/High
MANUAL.AML.EVALUATION Tick-Box Medium, PEP/High
PROFILE.REVIEW.EVAL Tick-Box Medium, PEP/High.
A Indicate reason why Client Profile Review came up with a

XX.REASON.DIFFT.RISK.EVAL different profile
A Any follow-up actions taken by RM

XX.FOLLOW.UP.REQUIRED
TAGGING.REQUIRED Drop down Options are Red-flag, staff, staff-related, Other
A Any restrictions / monitoring to be placed on client's account

XX.RESTRICTIONS.REQUIRED
Figure 79 CR.INTROLDUCTION.SOURCE

Page 65 of 66

@ID 10,A Unique idenfifier of for source of introduction
DESCRIPTION 50L,A Standard Text field

Hold the details about companies where introduction is
XX.COMPANY.AVAILABLE COM Available. This field is linked to company table.

Page 66 of 66

CRM PDF

Uploaded by

Copyright:

Available Formats

CRM PDF

Uploaded by

Document Information

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 PDF

Uploaded by

Copyright:

Available Formats

TEMENOS T24

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

TEMENOS T24 User Guide

TEMENOS T24 User Guide

TEMENOS T24 User Guide

TEMENOS T24 User Guide

SETTING UP THE SYSTEM

Figure 1 Product codes in the SPF

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

TEMENOS T24 User Guide

Figure 2 – Sample SPF screenshot

Sequencing for different tables are shown below

TEMENOS T24 User Guide

The details of the fields added to CUSTOMER are as below

Field Name Type Description

GIVEN.NAMES 50,A Name of the customer

FAMILY.NAME 50,A Family name of the customer

GENDER 6,A MALE_FEMALE

TEMENOS T24 User Guide

TEMENOS T24 User Guide

Figure 4 – CUSTOMER TABLE CR.PROFILE

TEMENOS T24 User Guide

Customer profiles are updated by two ways.

TEMENOS T24 User Guide

Figure 6 – TSA SERVICE RECORD FOR CRM

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

Figure 7 – CR.PROFILE.TYPE TABLE

TEMENOS T24 User Guide

Figure 8 – CR.PROFILE TABLE

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

TEMENOS T24 User Guide

Figure 9 – PW.TRANSITION RULE

TEMENOS T24 User Guide

Figure 10 – CUSTOMER RECORD DISPLAYING NEW FIELDS

TEMENOS T24 User Guide

Flow to setup Customer profile

TEMENOS T24 User Guide

TEMENOS T24 User Guide

The fields added are

TEMENOS T24 User Guide

CUSTOMER SINGLE VIEW

1. Customer Information – Basic static information of thecustomer.

A customer can amend data through the CUSTOMER single window.

Figure 13 -SINGLE CUSTOMER VIEW

TEMENOS T24 User Guide

TEMENOS T24 User Guide

Login screen for a CRM user is as below.

Figure 15 – MAIN SCREEN FOR CRM USER

CUSTOMER CONTACT INFORMATION

TEMENOS T24 User Guide

TEMENOS T24 User Guide

Figure 18 – MORTGAGE RECORD FOR TRACKING CONTRACT LOG

TEMENOS T24 User Guide

Figure 19 –CR.CONTACT.LOG FROM MORTGAGE RECORD

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

TEMENOS T24 User Guide

Figure 20 –MANUAL UPDATE OF CR.CONTACT.LOG

TEMENOS T24 User Guide

CR.CONTACT.LOG.FUTR and CR.CONTACT.LOG.HIST