Next best action for a retail bank, built on its own customer data.
A retail bank wanted to decide, customer by customer, whether the next conversation should be about activation, salary and savings, a new product or keeping an account open. Plexe built a next-best-action proof of concept on the bank's own customer snapshot: four baseline propensity and churn models, and a lookalike demo that turns similar customers' outcomes into a recommended action. The lift has not yet been measured in production.
How it fits together
- Bank workbookscustomer, behaviour, accounts
- Data pipelineParquet on S3
- Baseline modelsgradient-boosted trees
- Lookalike retrievalembeddings, FAISS
- Next best actionReact and FastAPI demo
The challenge
- Customer data arrived as raw spreadsheet workbooks, not modelling-ready tables
- Four separate questions: activation, salary and savings, cross-sell and churn
- Rare products such as credit cards make up a small share of customers
- Only one snapshot of data, so most labels describe today, not the future
What we built
- A pipeline that turns the bank's workbooks into Parquet tables on S3
- Four baseline models for activation, salary relationship, cross-sell and churn
- Customer embeddings with lookalike retrieval for any chosen customer
- A demo that shows the next best action, prioritised by churn risk
Four questions, one foundation
The proof of concept is organised around four problem statements. Which customers have opened an account but not yet funded it? Which are likely to bring a salary or savings relationship to the bank? Who is a candidate for a credit card or personal finance? And who is likely to close an account? Rather than four separate projects, all four are answered from one data foundation, and the demo then combines them to choose the single action that matters most for each customer.
How it works
The bank's raw workbooks are converted into Parquet tables in a private S3 bucket: a customer snapshot, a month of behaviour data and account data. Gradient-boosted baseline models are trained for each of the four problem statements, with the feature list for each task restricted so that no field gives the answer away.
A second layer builds behavioural embeddings for every customer, so that customers who bank in similar ways sit close together. In the demo, a banker picks a customer, the system retrieves the nearest lookalikes with FAISS, and what happened to those lookalikes drives a recommended next best action: retention, activation, cross-sell or engagement. Where several actions apply, churn risk sets the order, so a customer about to leave is offered a retention conversation before a new product.
What the first models show
Every model is scored on a held-out 25% test split, using ROC-AUC, PR-AUC and lift in the top-scored 10% of customers, because the top decile is what a campaign team actually works from. Each model's top-decile lift is reported against random selection, so the team can see what a shortlist of the highest-scored customers would be worth. These are cross-sectional baselines from a single snapshot, where most labels describe a customer's current state rather than a future outcome, so they are a floor to beat, not a forecast of campaign lift.
Where it stands
This is a proof of concept running on the bank's own customer data, not a production system. The next step written into the project is to re-cut every model on genuine forward-looking labels once the bank's outcome file and further monthly snapshots arrive. Because the pipeline, the models, the embedding index and the demo share one codebase, that re-run uses the same code on new data rather than a fresh build.
Under the hood
Stack
- Python
- Parquet
- AWS S3
- FAISS
- FastAPI
- React
- Vite