• Business value
• Personas and usage
• Channels and usage
• Example: Web self-service
• Example: Web chatbot
• Example: Interaction Portal
• Stages and steps
• Data model
• Extending the Microjourney

Business value

The ability for customers to make payments on their bank liabilities is essential to financial institutions, and it should be as frictionless as possible. This Microjourney enables banks to offer this ability through convenient channels: Web self-service, Web chatbot, and assisted channels, in a simple yet effective way. The two self-service channels make the process quick and easy, limiting the volume of calls to the more costly assisted channel, while maintaining high customer satisfaction. 

Personas and usage

• Customer – The bank customer who wants to make a one-time payment to any lending account (for example, credit card, line of credit, loan, or mortgage) by using Web self-service or a chatbot.
• Customer Service Representative (CSR) – The bank representative who uses assisted channels to capture the payment information.

Channels and usage

In this Microjourney, all channel interactions take place in the Intake stage. The rest of the stages have no channel because they are automated.

• Web self-service – This Microjourney assumes that the web self-service channel is the primary means by which clients initiate payment inquiries. This channel allows the use of payment dates other than the payment due date. It uses payment methods that are already set up.
   
• Web chatbot – Customer Service for Financial Services includes a sample configuration for using a chatbot. This channel uses payment methods that are already set up. It does not require a payment date, because it defaults to the payment due date, allowing the chatbot to provide a more focused and guided user experience. 
   
• Interaction Portal – The CSR's user interface supports live and asynchronous customer interactions by using telephone, chat, email, and text. This channel allows adding payment methods and selecting payment dates other than the due date.

Example: Web self-service

1. Customers select the payment amount. Suggested quantities vary between loans and cards, and the actual amounts are retrieved from the account. The following example is for a credit card payment. In this screen the customer also selects the payment date, which defaults to the payment due date but can be easily changed.

   

   

2. Customers select the deposit account from which to make the payment.

   

   

Example: Web chatbot

1. Customers select the payment amount. Suggested quantities vary between loans and cards, and the actual amounts are retrieved from the account. The following example is for a credit card payment.
   
   
2. Customers select the deposit account that will fund the payment. To provide a more focused experience, the payment date defaults to the payment due date.
   
   
3. The chatbot provides confirmation.

Example: Interaction Portal

1. The CSR selects the payment amount. Suggested quantities vary between loans and cards, and the actual amounts are retrieved from the account. The payment date defaults to the payment due date but can be easily changed.
    

   

   

2. The CSR selects the deposit account that will fund the payment.
    

   

   

3. If the customer would like to choose a different account, the CSR can add that account by selecting the bank name, which populates the routing number, and then adding the name on the account, and the account number.

   

   

Stages and steps

The project team can modify and extend most areas of this Microjourney in App Studio, thereby supporting users to Build for Change®. The following figure shows the stages and steps in this Microjourney. 

1. Eligibility – Determines whether the case can run or additional verification is required. This stage is disabled out-of-the-box. If you need more information about the new case template and how to enable this stage, refer to the < documentation new community link here>.
2. Intake – Most of the Microjourney happens in this stage, where the payment choices are provided and submitted. Email confirmation of successful intake is sent.
3. Process request – The payment is processed. There is an extension point to connect to your payment system for executing of the actual payment.
4. Resolve – The case is resolved. Resolution notifications are sent with either successful or failed payment.
5. Payment not received– This is an alternate stage that is used when a payment is not completed within the scheduled date. It sends a "payment not received" email.

Data model

Use the Data model page in App Studio to quickly view and understand the relationship between all data objects in the application. You can add, update, and delete data objects without exiting the visual data model. For information about the Data model page, see Data Modeling. For information about connecting to external data entities, see Managing data and integrations with the Integration Designer.  

The following figure shows the entity relationship diagram (ERD) for this Microjourney.  For each data object, the ERD shows only the properties that apply to this Microjourney.

Extending the Microjourney

The out-of-the-box Make payment case allows the customer to make a payment from a deposit account that is held either within the organization, or comes from an external source. This case can be used in other cases where payment is expected from a customer.  You can update the D_RelAccountList data page to get the credit or loan account of a customer and the D_PaymentMethodList data page to get the list of all available payment methods for the customer to process the payment. 

The D_PaymentOptions data page lists the options to make a payment such as Minimum Due, Last statement balance, Current Balance, and Next Payment Amount, if it is a loan account. Additional extension points are described in the following section.

Extension points

The following table lists and describes the extension points in this Microjourney that you can use to modify payment methods, payment options, notifications, and service-level agreements (SLAs).