Simplifying Fulfillment process from PEGA Decisioning/Marketing recommendations

Most of the times recommending the offer from PEGA as part of the Decision making process and  Acceptance rate is being considered as a SUCCESS of Marketing campaign. As a Marketing Manager, I would like to see the overall success by measuring the Impressions, Acceptance and the Orders completed following an existing fulfillment process.

Let’s look at the sample Decisioning response with various scenarios used to achieve this.

Option#1 (Populate CallToAction link for each Proposition response to redirect the Sales Landing Page)

Let’s look at the following PEGA Decisioning response for one of the sales scenario. You could see only CustomerID and List of Top X propositions recommended from the PEGA Decisioning Engine. Click of the CallToAction link would be considered as SUCCESSS. This might be TRUE for all the informational/Nurture propositions. Do you think the same solution would work for Sales Proposition where the Order fulfillment needed? I don’t think so.

PEGA RESPONSE:

<DecisionResponse>
       <CustomerID>CE-1</CustomerID>
       <InteractionID>641889359827003657</InteractionID>
       <PropositionPropositionResults>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner1</Name>
                     <Rank>1</Rank>
                     <CallToAction>http://abcbank.com/CCLandingPage</CallToAction>
              </PropositionResult>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner2</Name>
                     <Rank>2</Rank>
                     <CallToAction>http://abcbank.com/CurrentAccountLandingPage</CallToAction>
              </PropositionResult>
       </PropositionPropositionResults>
</DecisionResponse>

Sample Self Service channel application screen post Clicking the CallToAction Landing Page:

    We can clearly see that both Customer Information & Proposition information is not pre-populated. Customer has to key all the mandatory input to full-fill the application process & regular eligibility check has to done even though the system has most of the required data to complete the fulfillment process. 

 

Option#2 (Populate CallToAction link for each Proposition response + Proposition specific payload and redirect the Sales Landing Page)

Let’s look at the following PEGA Decisioning response for another sales scenario. You could see only CustomerID and List of Top X propositions recommended from the PEGA Decisioning Engine. One Difference here is Proposition contains all the Payload information required to complete the fulfillment process. Along with CallToActionLink, payload information required to fulfill the order also being supplied.

<DecisionResponse>
       <CustomerID>CE-1</CustomerID>
       <InteractionID>641889359827003657</InteractionID>
       <PropositionPropositionResults>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner1</Name>
                     <Rank>1</Rank>
                     <CallToAction>http://abcbank.com/CCLandingPage</CallToAction>
                     <PropositionPayLoad>
                           <AccountPayLoad>
                                  <AccountGroup>CreditCard</AccountGroup>
                                  <AccountType>Classic</AccountType>
                                  <PreApprovedLimit>800</PreApprovedLimit>
                           </AccountPayLoad>
                           <AppointmentPayLoad>
                                  <BranchCode></BranchCode>
                           </AppointmentPayLoad>
                     </PropositionPayLoad>
              </PropositionResult>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner2</Name>
                     <Rank>2</Rank>
                     <CallToAction>http://abcbank.com/CurrentAccountLandingPage</CallToAction>
              </PropositionResult>
       </PropositionPropositionResults>
</DecisionResponse>

Sample Self Service channel application screen post Clicking the CallToAction Landing Page:

    We can clearly see that only Proposition information is pre-populated based on the decision made earlier. Customer has to key all the mandatory input to full-fill the application process & regular eligibility check has to done even though the system has most of the required data to complete the fulfillment process. 

PEGA Decision Engine owns most of the customer data as part of Customer Analytical Records.  Can't we use the same to pre-populate the application form to make the fulfillment easier? Yes, this brings the option#3

Option#3 (Populate CallToAction link for each Proposition response +Customer Information + Proposition specific payload and redirect the Sales Landing Page)

PEGA can play a major role to simplify the fulfillment process by passing all the required payload information (Customer Data and OfferData) to make the fulfillment process easy and smooth.

<DecisionResponse>
       <CustomerInfo>
              <CustomerID>CE-1</CustomerID>
              <FirstName>ABC</FirstName>
              <FirstName>XYZ</FirstName>
              <AddressLine1></AddressLine1>
              <AddressLine2></AddressLine2>
              <AddressLine3></AddressLine3>
              <AddressCity></AddressCity>
              <AddressCountry></AddressCountry>
              <AddressPostcode></AddressPostcode>
              <Email>abc@gmail.com</Email>
              <MobileNo>XXXXXX3923</MobileNo>
              <DOB>01/01/1970</DOB>
       </CustomerInfo>
       <InteractionID>641889359827003657</InteractionID>
       <PropositionPropositionResults>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner1</Name>
                     <Rank>1</Rank>
                     <CallToAction>http://abcbank.com/CCLandingPage</CallToAction>
                     <PropositionPayLoad>
                           <AccountPayLoad>
                                  <AccountGroup>CreditCard</AccountGroup>
                                  <AccountType>Classic</AccountType>
                                  <PreApprovedLimit>800</PreApprovedLimit>
                           </AccountPayLoad>
                           <AppointmentPayLoad>
                                  <BranchCode></BranchCode>
                           </AppointmentPayLoad>
                     </PropositionPayLoad>
              </PropositionResult>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner2</Name>
                     <Rank>2</Rank>
                     <CallToAction>http://abcbank.com/CurrentAccountLandingPage</CallToAction>
              </PropositionResult>
       </PropositionPropositionResults>
</DecisionResponse>

Sample Self Service channel application screen post Clicking the CallToAction Landing Page:

    We can clearly see that both Customer and  Proposition information is pre-populated based on the decision made earlier. Customer can validate (make the amendment if needed to key all the mandatory input) and complete the application process. 

Option#4 (Making PEGA Response API Generic to populate the fulfillment process to all types of Landing Pages)

    Option#3 sounds interesting right? If PEGA passes the required customer & sales payload, the fulfillment process would be easy! There is a design constraint here. The payload information required to complete the loan account is different from Creditcard. If post started sending additional proposition like appointment booking decision rom PEGA, the payload structure will be completely different from Sales proposition. Considering there is PEGA Decisioning HUB & the logic is exposed as a Headless Decision. We would be having only one Decisioning API to manage the Decisioning requests across the channel and propositions.

The complexity comes when having one headless PEGA Decisioning API to manage the different Sales Propositions passing the payload from PEGA. To manage this API response payload complexity, PEGA could send the Proposition/Action specific payload in a generic response using xml CDATA option.
 
What is XML CDATA?
CDATA is defined as blocks of text that are not parsed by the parser, but are otherwise recognized as markup.

<![CDATA[ <message> CDATA test message </message> ]] >

Characters between these two enclosures are interpreted as characters, and not as markup. This section may contain markup characters (<, >, and &), but they are ignored by the XML processor.

How to Apply CDATA feature to manage the fulfillment need for dynamic payload from PEGA response?

Let’s look at the Payload being populated for Proposition#1.  PropositionPayLoad is the generic tag used to populate the Payload. It’s not bound to any proposition contract. PropositionPayLoad is populated with the payload required for CreditCard Limit increase offer.

<DecisionResponse>
       <CustomerInfo>
              <CustomerID>CE-1</CustomerID>
              <FirstName>ABC</FirstName>
              <FirstName>XYZ</FirstName>
              <AddressLine1></AddressLine1>
              <AddressLine2></AddressLine2>
              <AddressLine3></AddressLine3>
              <AddressCity></AddressCity>
              <AddressCountry></AddressCountry>
              <AddressPostcode></AddressPostcode>
              <Email>abc@gmail.com</Email>
              <MobileNo>XXXXXX3923</MobileNo>
              <DOB>01/01/1970</DOB>
       </CustomerInfo>
       <InteractionID>641889359827003657</InteractionID>
       <PropositionPropositionResults>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner1</Name>
                     <Rank>1</Rank>
                     <CallToAction>http://abcbank.com/CCLandingPage</CallToAction>
                     <PropositionPayLoad>
                           <![CDATA[
                                  <AccountPayLoad>
                                         <AccountGroup>CreditCard</AccountGroup>
                                         <AccountType>Classic</AccountType>
                                         <PreApprovedLimit>800</PreApprovedLimit>
                                  </AccountPayLoad>
                            ]]>
                     </PropositionPayLoad>
              </PropositionResult>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner2</Name>
                     <Rank>2</Rank>
                     <CallToAction>http://abcbank.com/CurrentAccountLandingPage</CallToAction>
              </PropositionResult>
       </PropositionPropositionResults>
</DecisionResponse>

 

Let’s look at the Payload being populated for Proposition#1 for a scenario.  PropositionPayLoad is the generic tag used to populate the Payload. It’s not bound to any proposition contract. PropositionPayLoad is populated with the payload required for Appointment booking offer.

<DecisionResponse>
       <CustomerInfo>
              <CustomerID>CE-1</CustomerID>
              <FirstName>ABC</FirstName>
              <FirstName>XYZ</FirstName>
              <AddressLine1></AddressLine1>
              <AddressLine2></AddressLine2>
              <AddressLine3></AddressLine3>
              <AddressCity></AddressCity>
              <AddressCountry></AddressCountry>
              <AddressPostcode></AddressPostcode>
              <Email>abc@gmail.com</Email>
              <MobileNo>XXXXXX3923</MobileNo>
              <DOB>01/01/1970</DOB>
       </CustomerInfo>
       <InteractionID>641889359827003657</InteractionID>
       <PropositionPropositionResults>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>ApptmentBooking</Name>
                     <Rank>1</Rank>
                     <CallToAction>http://abcbank.com/AppointmentBookingPage</CallToAction>
                     <PropositionPayLoad>
                           <![CDATA[
                                  <AppointmentPayLoad>
                                  <BranchCode></BranchCode>
                                  </AppointmentPayLoad>
                            ]]>
                     </PropositionPayLoad>
              </PropositionResult>
              <PropositionResult>
                     <Issue>Banners</Issue>
                     <Group>Sales</Group>
                     <Name>Banner2</Name>
                     <Rank>2</Rank>
                     <CallToAction>http://abcbank.com/CurrentAccountLandingPage</CallToAction>
              </PropositionResult>
       </PropositionPropositionResults>
</DecisionResponse>

 

What do you think? Do you think using CDATA in a xml response help us to manage & decouple the payload contact to ease the fulfillment process from PEGA response? Feedback appreciated. This solution can also address the Data quality issue being introduced to the system.

Mitigate the Data Quality Issue:

    Pre-populated the customer data from System Of Record along with payload information would prevent the data quality issue. Managing the single source of Truth information about the customer is very critical to any organization to deliver the Decisioning & Marketing actions timely & contextual manner.

Simplify the Order Fulfillment Experience:

    In order to drive Upsell/cross sell new products to the customers, you have to make the fulfillment process easy and exciting for people to order again. If most of the customer and proposition information pre-populated, fulfillment process could be done with very few clicks. It would create memorable experience for the customers & it would stand out from other competitors

Conclusion:

As part of PEGA Decision making process, PEGA could send the payload information needed to make the Order fulfillment process for both Inbound & outbound channels. Its all about the making customer journey smooth & easier from Decisioning->Impression->Acceptance->Orderfulfillment. 

Happy Learning,

Nanjundan Chinnasamy | PEGA Lead Decicioning Architect