Addendum to Detailed Design Document

CEEMEA CRM PHASE 1 – Ver 1.0

Citibank, Poland

MphasiS Software,
Mumbai
Date – May 27th 2003
MphasiS Software,
Mumbai
 MPH_CITICEEMEA_POL_DESIGN_ADDENDUM_VER_1.0 Design
Document

Revision History

Version Created By Reviewed by Date Sections Remarks

No. Affected

0.1 Anuradha Rao Minal Dukle, 24th May, All First draft
Kumar 2003
Suryanarayan
1.0 Anuradha Rao Minal Dukle, 27th May, All First release
Kumar 2003
Suryanarayan

Confidential – Internal Use Only 2

MPH_CITICEEMEA_POL_DESIGN_ADDENDUM_VER_1.0 Design
Document

TABLE OF CONTENTS

1 Introduction........................................................................................................... ....4
2 Scope....................................................................................................... .................4
3 Assumptions and Dependencies.................................................. .............................4
4 Reference Documents............................................................................... ................5
5 Detailed Design................................................................................................... .....6
5.1 SMS............................................................................................... .....................6
5.1.1 Records................................................................................................... .....6
5.1.2 People Code.......................................................................................... .......6
5.1.3 Application Engine Program................................................................. ........6
5.2 Internet................................................................................. .............................8
5.2.1 PeopleSoft Configuration.................................................. ...........................8
5.2.2 To send campaign details to IPT For Targeted Campaigns............................8
5.2.2.1 People Code........................................................................... ...............8
5.2.2.2 Application Engine Program.................................................. ................9
5.2.3 To receive responses/registrations from IPT.................................. .............10
5.3 Email........................................................................................... .....................13
5.3.1 Sending emails from the CRM application.................................................. 13
5.3.2 Receipt of Emails in the CRM Application............................................. ......15
5.3.3 Display of emails to user.............................................. .............................15

Confidential – Internal Use Only 3

MPH_CITICEEMEA_POL_DESIGN_ADDENDUM_VER_1.0 Design
Document

1 Introduction

This document is an addendum to the detailed design document and addresses the
detailed design for the areas of SMS, Email and IPT requirements.

2 Scope

1. This document includes the design for generation of an XML file to be used for
SMS.
2. Read receipts will not be handled as a part of this design document.

3 Assumptions and Dependencies

1. The SMS messages will not exceed 160 chars

2. The product codes in the email messages from IPT will be the same as the
product Ids in the CRM application.
3. If a customer holds more than one credit card, there will be as many entries in
the download for a campaign as the number of cards.
4. There is only one debit card per customer in the CRM system.
5. The banner code entered with the waves will match the banner codes used in
IPT.
6. At the time of preparation of this document, it is assumed that PESEL will be
provided during a registration from IPT.
7. If an email is received from a prospect, a new prospect record will not be
created automatically by the CRM system. After studying the email, the users
can manually create prospects or leads as necessary.
8. The email body that is received from IPT will not be longer than 512 bytes.
9. The responses from IPT and Email will be received in different inboxes.
10. Automation of the correspondence in PeopleSoft is to be tested and verified.

Confidential – Internal Use Only 4

MPH_CITICEEMEA_POL_DESIGN_ADDENDUM_VER_1.0 Design
Document

4 Reference Documents

Document Name Description Dated

MPH_CITICEEMEA_POL_FSD_Ver 1.0 Functional 21st Apr
Specifications ‘03
Document
MPH_CITICEEMEA_POL_SRS_Ver 2.0 Systems Requirement 6th Mar ‘03
Document
MPH_CITICEEMEA_POL_CIF Ver 1.7 CIF attribute master 24th Apr
document ‘03
MPH_CITICEEMEA_POL_ADDENDUM 2.0 Addendum to functional 25th Apr
specifications ‘03
MPH_CITICEEMEA_POL_FSD_INTERNET_Ver Functional 21st May
2.0 specifications for ‘03
internet
MPH_CITICEEMEA_POL_ARCHITECTURE 1.4 Architecture Design 3rd May ‘03
document
MPH_CITICEEMEA_POL_DESIGN_VER 2.1 Detailed Design 21st May
Document ‘03

Confidential – Internal Use Only 5

MPH_CITICEEMEA_POL_DESIGN_ADDENDUM_VER_1.0 Design
Document

5 Detailed Design

5.1 SMS
When a campaign wave intended for SMS channel is executed, the CRM system will
generate a XML file containing the mobile numbers and a message. This XML file has
to be generated with a MD5 hash key at the end of the XML file.

The application server generates the file using ‘XMLDoc’ Class, it will call java class to
generate MD5 hash. The application server has the java runtime environment
installed to invoke the java class “com.java.security.MessageDigest

5.1.1 Records
A new record will be defined for the XML file generation. The structure of this record
will be as follows

Column Data Type Length Remarks

WAVE_ID CHAR 15 Wave for which SMS being sent
MOBILE CHAR 50 Mobile number to which message is to be
sent

5.1.2 People Code

Record RA_CMPGN_WAVE
Name
Field RA_CMPGN_STATUS_
CD
Event FieldChange

1. Check if value of RA_CMPGN_STATUS_CD = ‘Executing’

2. Check if Channel = ‘SMS’
3. If yes, call the application engine program CTP_GENERATE_SMS

5.1.3 Application Engine Program

This program will generate an XML file using the XMLDoc class. The file generated will
then be appended with a MD5 hash key and saved as a text file and placed on a
specified directory in the batch server.

The steps in the application engine program will be as follows:

1. Get all audience records for the wave being executed

2. For each person in the audience list repeat steps 3 and 4
3. Check if a mobile number with the status ‘Active’ is available for the person.
a. If yes, check if optimum contact for person is reached.
i. If not, add WaveID and Mobile number into CTP_WAVE_SMS
ii. If yes, skip the record
4. If not, skip the record.
5. Call a section that creates an XML file

Confidential – Internal Use Only 6

MPH_CITICEEMEA_POL_DESIGN_ADDENDUM_VER_1.0 Design
Document

6. Call a section that gets the MD5 hash key

7. Append the hash key from step 6 to the XML string from step 5.
8. Save as a text file in the location specified.

Section to generate XML

To generate an XML file, use the following logic

1. Create an empty XMLDoc class

2. Add nodes and attributes to the class using AddNode, AddDocumentElement
and AddAttribute functions
3. Get the mobile number from the CTP_WAVE_SMS table and the text for SMS
from the Wave content.
4. Build the XML file as specified in the definition below.
5. Get the XML string for this file using the GenXMLString function.

The DTD for the XML file is

<!ELEMENT sms_set (header, sms_list, trailer)>
<!ELEMENT header (creation_timestamp)>
<!ELEMENT creation_timestamp (#PCDATA)>
<!ELEMENT sms_list (sms)*>
<!ELEMENT sms (sms_type, msisdn, text)>
<!ELEMENT sms_type (#PCDATA)>
<!ELEMENT msisdn (#PCDATA)>
<!ELEMENT text (#PCDATA)>
<!ELEMENT trailer (sms_count)>
<!ELEMENT sms_count (#PCDATA)>

Section to get the MD5 hash key

1. Create an instance of the java object java.security.MessageDigest

2. Get an instance to the MessageDigest object for MD5
3. Pass the XML string generated in the section above, to the Update method
4. Use the Digest method to generate the hash key.

Confidential – Internal Use Only 7

MPH_CITICEEMEA_POL_DESIGN_ADDENDUM_VER_1.0 Design
Document

5.2 Internet
This section addresses the requirements in the functional specifications for Internet.
The various scenarios to be considered are

1. A new registration on the IPT

2. A guest expressing interest in certain products
3. A targeted campaign with the channel as Internet.

5.2.1 PeopleSoft Configuration

In the OOTB PT_EMAIL_POP3 node, edit the transaction, EMAIL_REQ_READALL and set
the following connector properties.

1. Server
2. User
3. Password
4. Port

The message used for the same is the EMAIL_REQ_READDELALL. The underlying
record to be used is the EMAIL_REQ_WRK. The message will read all messages from
the inbox and delete them.

The response to the request is provided in the EMAIL_RES_WRK record. Using the
EMAIL_TEXTLONG field from the record, the body of the email can be obtained.
The email body will be in XML.

An application engine program CTP_POLL_INBOX will be written which sends a

request to the POP3 target connector to read mails from a specified inbox.

5.2.2 To send campaign details to IPT For Targeted Campaigns

5.2.2.1People Code

To send campaign details to IPT For Targeted Campaigns

On execution of a wave if the channel is Internet, a list is to be extracted from the

CRM system to be provided to the IPT system.

Record RA_CMPGN_WAVE
Name
Field RA_CMPGN_STATUS_
CD
Event FieldChange

1. Check if value of RA_CMPGN_STATUS_CD = ‘Executing’

2. Check if Channel = ‘Internet’
3. If yes, call the application engine program CTP_GENERATE_LIST_IPT

Confidential – Internal Use Only 8

MPH_CITICEEMEA_POL_DESIGN_ADDENDUM_VER_1.0 Design
Document

5.2.2.2Application Engine Program

The steps in the application engine program follow the given algorithm

1. For every person in the target list in PS_RA_LIST_REC, generate leads that are
unassigned
2. From the PS_RSF_LEAD table, find all leads generated for the wave
3. Get the BO_ID_CUST from the lead
4. Find the Debit card number for the BO_ID, if available
5. Find the Credit card number for the BO_ID if available. If more than one credit
card found for a customer, each one is to be considered separately.
6. Get the Portal login Id from the PS_BC table.
7. Get the banner code from the wave
8. The magic number is the same as the lead ID
9. Get the wave end date. This will be the expiry date for the campaign display
in IPT.
10. Write the information from steps 2-9 into the file.

Confidential – Internal Use Only 9

MPH_CITICEEMEA_POL_DESIGN_ADDENDUM_VER_1.0 Design
Document

5.2.3 To receive responses/registrations from IPT

An application engine program is to be written which sends a message request to

check if any responses are received in the inbox.

The following peoplecode will be called in the application engine program. Pass the
value “NEW” in UIDL so that all messages in the inbox are fetched.

A synchronous request is sent to the POP3 connector and the response returned in
the EMAIL_RES_WRK record.

The process flow for the application engine program is as follows

Send Get all emails

synchronous and for each
request to read
email
Get email content in
work record
EMAIL_RES_WRK

Get tokens from field

EMAIL_LONG and find tag

Process Process Guest Process

Registration response campaign
request response

Following is the algorithm for the application engine.

1. Create a message of the Message.EMAIL_REQ_READDELALL

2. Set the values of the UIDL filed in the EMAIL_REQ_WRK record to ‘NEW’. This
will ensure that all mails are read.
3. Use the syncRequest method of the message to the PT_EMAIL_POP3 node.
4. Check if the response status = 0
5. If yes, get the level 0 rowset of the response
6. Get records from 2 to the ActiveRowCount. The number should start from 2 as
one empty record is always returned.
7. Read the content in the field EMAIL_TEXTLONG
8. Parse the XML string using the ParseXMLString function.
9. Search for tag <BannerResponse>. If the banner code is found, the email is in
response for a guest campaign. Call function
CTP_HandleGuestResponse(BannerCode, FirstNAme, LastName, Email
Address, Field1, Field2, Field3, Field4, Field5)
10. Search for tag <UserRegistration>. If this tag is found, it means the email is in
response to a user registration on the portal. Call function
CTP_HandleUserRegistration(Firstname, Lastname, Email address, PESEL,
ProspectLogin, Prod1, Prod2, Prod2, Prod4, Prod5, Field1, Field2, Field3, Field4,
Field5)

Confidential – Internal Use Only 10

MPH_CITICEEMEA_POL_DESIGN_ADDENDUM_VER_1.0 Design
Document

11. Search for tag <CampaignResponse>. If this tag is found, it means the email
is in response to a targeted campaign. Call function
CTP_HandleCampaignResponse (Magic Number, InterestedYN, Comments)

The functions to handle responses will work on the following algorithm.

1. Guest Responses and Application forms

The code to handle guest responses to a wave, will de-duplicate the record
against the existing customer and prospect database in CRM. If no match is
found, the record will be entered into CRM as a new prospect.

The function receives the Banner code to which the user has responded and
details of the customer as input values.

1. Call the Deduplication function with the First name, last name and Email
address as parameters.
2. If the function returns No Match, the person can be added into the CRM
system as a prospect. Follow steps 3-9
3. Create a new prospect record
4. Set the source of the person as Internet
5. Set the customer indicator to ‘P’ to indicate a prospect.
6. Find the wave to which the banner code in the response is attached.
7. Enter one lead for the banner that has been passed in the email.
8. Set the wave in the lead to the wave ID obtained in step 6.
9. Assign leads to telemarketing agents
10. If the function returns Perfect Match, the person exists in the CRM system and
should not be added. Follow step 11 and 12
11. Add a source of the customer as Internet.
12. Enter the Firstname, Lastname and Email address into a reject file. Add the
reason as ‘PerfectMatch found’
13. If the function returns Partial Match, the person exists in the CRM system and
should not be added. Follow step 14
14. Enter the Firstname, Lastname and Email address into a reject file. Add the
reason as ‘Partial Match found’

2. User Registrations

When a user registers through a portal, the customer details are to be entered
into the CRM system. Deduplication of the entry against the existing prospect and
customer database is to be done.

The function receives the firstname, lastname, email address, PESEL, login name
and a list of a maximum of five product lines that the customer is interested in.

1. Call the Deduplication function with the First name, last name, PESEL and
Email address as parameters.
2. If the function returns No Match, the person can be added into the CRM
system as a prospect. Follow steps 3-8
3. Create a new prospect record
4. Set the source of the person as Internet
5. Set the customer indicator to ‘P’ to indicate a prospect.
6. Enter the login name as the Portal login ID

Confidential – Internal Use Only 11

MPH_CITICEEMEA_POL_DESIGN_ADDENDUM_VER_1.0 Design
Document

7. For each product line in the fields Field1 to 5, find the ongoing registration
wave for the product line and assign the lead to a telemarketing agent.
8. Create one lead for each product that the user expresses interest in and set
the wave to for that to be the lead from step 7.
9. If the Deduplication returns a perfect match, follow steps 7-8.
10. Set the CUST_BO_ID in the lead record with the BO_ID of the person found in
step 9.
11. If the Deduplication returns a partial match, the record is to be rejected
15. Enter the Firstname, Lastname and Email address into a reject file. Add the
reason as ‘Partial Match found’

3. Campaign Responses

In the case of a targeted campaign, the emails contain a token with the magic
number, which can be used to link the response to an existing lead.

In this case, there is no need for Deduplication as the emails are only for targeted
customers and no responses will be received from prospects.

The function receives a magic number, an interested flag and comments.

1. Locate the lead with the magic number = LEAD_ID

2. If the flag is ‘N’ change status to ‘Closed unsuccessful’ and enter REASON as
the comments.
3. If the flag is ‘Y’ change status to ‘In Progress’ and enter comments in Notes.
4. Assign the lead to a telemarketing agent.

Confidential – Internal Use Only 12

MPH_CITICEEMEA_POL_DESIGN_ADDENDUM_VER_1.0 Design
Document

5.3 Email

5.3.1 Sending emails from the CRM application

If the channel selected for a wave is EMAIL, the user will be able to send emails to all
persons in the target list using the Correspondence management feature of
PeopleSoft CRM.

The following steps need to be carried out to have the ability to send emails from the
CRM system.
1. Configure correspondence management in PeopleSoft
2. Set up templates to be used in email campaigns
3. Define tokens to be used in the templates, if necessary.
4. Customize the campaign waves to allow linking to a correspondence template

PeopleSoft Configuration

The setting up of the Correspondence management is to be done as per the

instructions provided in PeopleBooks.

Creation of a Correspondence Template

A correspondence template will allow the user to define templates with tokens, which
will be merged with data from the system when the correspondence is sent.

A template is to be created for a wave that will use Email as a channel and use the
correspondence management feature. The template can be created using OOTB
components. Navigate using SetUp CRM -> Common Definitions -> Correspondence
-> Template.

Text files that can be created by the user can be uploaded as templates into the CRM
system. Please note that any tokens used in the template are to be delimited by
{{ and }}.

A predefined set of tokens is available OOTB. These can be used to define templates.

PeopleSoft Customization

Record definition

Record: RA_CMPGN_WAVE
Column Name Data Type Description
CTP_EMAIL_TEMPLAT CHAR (90) Name of template to be used for
E correspondence during wave execution

Wave screen should allow entry of the template name, which will be linked to the
correspondence when the wave is executed.

Validation: If the channel on the wave is EMAIL, the template name is mandatory.

Confidential – Internal Use Only 13

MPH_CITICEEMEA_POL_DESIGN_ADDENDUM_VER_1.0 Design
Document

PeopleCode

Record RA_CMPGN_WAVE
Field RA_CMPGN_STATUS_C
D
Event FieldChange

Create a work record CTP_EMAIL_CONTEXT_WRK to which valid audience records are

added. Correspondence will be sent only to the records in this record. The structure
of this record is the same as the RA_LIST.

Step 1 – Validate the records in the audience can be sent email.

1. If the Wave.CHANNEL = ‘EMAIL’

2. Get all persons from the audience associated with the wave
3. For each person, check if negative listed
4. If yes, skip the record
5. If not, check if person has reached optimum contact
6. If yes, skip the record
7. If not, Check If the person has the OK_TO_EMAIL set to True
8. If yes, check that an email address for the person exists.
9. If not, skip the record

Step 2 – Create a request for correspondence

1. Create a request using the RBC_REQUEST_API:Request() method

2. Set the properties of the request, set component, disallow edits, disallow changes to
recipient list, set delivery channel as email.
3. Create and add a transaction to the request
4. Add a runtime context record to the transaction. This will be the RA_LIST record
5. Add the SETID and the LIST_ID as the context fields
6. Fetch the audience from the CTP_EMAIL_CONTEXT_WRK for the specified
SETID and LIST_ID
7. Create a recipient for the request.
8. Set the properties for a recipient like First name, Last name and email address
9. Add the recipient to the transaction.
10. Save the request and close it. On save a CMF_ID is allotted to the request. The
request is now added to the correspondence request list.
11. Enter the CMF_ID into a table CTP_SEND_CORRESPONDENCE

Step 3 – Send correspondence

The request once created, can be merged and submitted using the Manage
correspondence page. Automation process for the same is to be determined.

Confidential – Internal Use Only 14

MPH_CITICEEMEA_POL_DESIGN_ADDENDUM_VER_1.0 Design
Document

5.3.2 Receipt of Emails in the CRM Application

PeopleSoft Configuration

Emails will be received in the CRM system on a specified email address. The OOTB
POP3 connector will be configured to check emails on a specified inbox.

The system will use the EMAIL_REQ_READALL message to read all the emails in the
inbox. The response is available in the EMAIL_RES_WRK record.

The configuration of the POP3 connector is to be done as explained in the section on

Internet above.

PeopleSoft Customization

Application Engine Program

An app engine program is to be written which is scheduled to send a request to get

any mail that has arrived into the pre-defined inbox. This program will be scheduled
to run at regular intervals.

The following are the steps in the application engine program

1. Send a synchronous request to get all emails using the message

EMAIL_REQ_READDELALL.
2. For every mail returned by the request do steps 3-5
3. Get the value in the field EMAIL_FROM
4. Find the BO_ID for the person who the email belongs to.
5. Populate the table CTP_EMAIL_RESPONSE table with the following fields
a. UIDL
b. WL_SUBJECT
c. EMAIL_TEXTLONG
d. DATE_FROM
e. BO_ID from step 4, if found, else enter NULL

5.3.3 Display of emails to user

The emails read using the application engine program above, will be displayed using
the following interface.

Record Definition

Define a new record in PeopleSoft to store the email read from the application engine
program.

Record Name: CTP_EMAIL_RESPONSE

Column Name Data Type Comments

CTP_SEQ NUMBER Auto number
(9)
CTP_EMAIL_FRO CHAR (254) From address
M

Confidential – Internal Use Only 15

MPH_CITICEEMEA_POL_DESIGN_ADDENDUM_VER_1.0 Design
Document

CTP_UIDL CHAR (70)

CTP_SUBJECT CHAR (254) Subject
CTP_EMAIL_BODY LONG Body of the mail
FROMDATE DATE Date sent
BOID CHAR (31) BOID of person identified in CRM
system

Page Definition

Two new pages are to be defined based on the record CTP_EMAIL_RESPONSE

Page: CTP_CUST_EMAIL_RESP

The page will display a grid with the details of the email. The following will be the
columns in the GRID

Column Name Label Description

FROM DATE Date
CTP_EMAIL_FRO From
M
BO_NAME Customer Get BO_NAME from PS_BO using the
Name BO_ID
CTP_SUBJECT Subject
CTP_EMAIL_BODY Message

The contents of the grid are to be populated on the basis of the algorithm given
below.

1. Get all records from CTP_EMAIL_RESPONSE WHERE BO_ID IS NOT NULL.

2. For each record get BO_NAME from PS_BO_NAME with a join on BO_ID.

A button will be displayed after the customer name and another after the email
message. On the click of the button after the customer name, the 360-view for that
customer is to be displayed.

Please refer to section 6.1 in the detailed design document for details on launching
the 360 view using a BO_ID. The same algorithm is to be used to launch the 360-view
from this page.

On clicking the button after the email, display a secondary page,

CTP_CUST_EMAIL_RESP_SBP, with the details of the email. This page will be used to
view the entire email message.

Please note that the page CTP_CUST_EMAIL_RESP_SBP is a read-only page. No

changes or updates will be allowed.

The secondary page will display the following fields from the CTP_EMAIL_RESPONSE
table.

1. FROM_DATE
2. CTP_EMAIL_FROM
3. CTP_SUBJECT
4. CTP_EMAIL_BODY

Confidential – Internal Use Only 16

MPH_CITICEEMEA_POL_DESIGN_ADDENDUM_VER_1.0 Design
Document

Page: CTP_ EMAIL_RESPONSE

This page will be used to display the emails that have been sent by persons that the
CRM system is unable to recognize. I.e. persons for whom a BO_ID cannot be resolved
based on the email address.

This page will be used to display emails from Systems Administrators in the case of
bounced emails or errors. It will also display emails from prospects for whom an entry
is still not made in the CRM system.
The page will display a grid with the following details.

Column Name Label Description

FROM DATE Date
CTP_EMAIL_FRO From
M
CTP_SUBJECT Subject
CTP_EMAIL_BODY Message

The contents of the grid will be displayed based on the following rule

1. Get all records from CTP_EMAIL_RESPONSE where the BO_ID IS NULL.

A button will be shown at the end of the email message. On clicking the button,
display the secondary page, CTP_CUST_EMAIL_RESP_SBP as explained above.

Confidential – Internal Use Only 17