Payment Analysis Dashboard Prototype Review 30 th October 2013

Prototype Objectives  Demonstrate improved report formatting and visualisation  KPI Dashboard  Detailed Analysis  Rescue Analysis  Trends  Gather feedback from stakeholders  Confirm that QlikView PAD reporting fits business needs  Not meant to be a tactical or the final solution 2

Prototype Definitions  Processed = Records submitted to the payment processing partner resulting in either a successful payment or rejection  Decline rate = Total rejected in a given time period/Total processed in the same time period  Initial Payment Attempt = The date on which payment processing was attempted for the very first time; could result in success or rejection  Rescue Attempt = The date on which payment processing was attempted after an initial or subsequent payment rejection  Rescue = A successful payment attempt made either after an initial payment attempt or any subsequent payment rejection 3

Prototype Design Principles  Dashboard provides information on areas needing immediate attention  Detailed view leading from the dashboard will allow marketer/financial controller to drill down to identify areas causing higher decline rates  Decline rate displayed in dashboard is cumulative decline over selected time period  Rescue analysis is always linked to the initial payment attempt for any given time period i.e. it is not cumulative in nature  Rescue analysis allows marketer to review and analyse effectiveness of bounce process  Trends allow marketer/financial controller to view historical data and ascertain how things have progressed over various payment attempt time periods 4

Prototype Constraints/Assumptions  Data used is from existing QSS feeds without any modifications  Accuracy of data has not been ascertained and is work in progress  Thresholds have been set based on YTD averages and will need to be changed in the final solution as needed by the business  Data mappings currently used will need updating  Currency conversions rates from PeopleSoft have not been applied  Assumed that bounce process marketing efforts are consistent with the payment rescue attempts by QSS  Assumed that if there is only one payment attempt record, then it is a successful payment  All business requirements have not been added to the prototype yet 5

Prototype  6

Next Steps  Consolidate business requirements based on feedback  Update prototype based on feedback  Business testing 7