Skip to content

Reference journey · illustration

Reference Salesforce CRM journey of a regional bank.

Disclaimer: this is not a named client, but a reference journey built from situations common in the sub-region. It serves to show how we reason, in what order we work and where we focus our attention. As a matter of principle, it contains no outcome figures.

Journey fact sheet

The starting situation.

Context

A commercial bank present in several UEMOA States, with head office in Senegal, a branch network, a call centre and a mobile app. The customer relationship is scattered: the core banking system knows the accounts, advisers keep their prospects in spreadsheets, the call centre logs complaints in its own tool, marketing sends its campaigns from yet another. A customer who complains on the phone is not recognised in the branch the next day.

Trigger

Competition that is now decided on the quality of the relationship, between regional banks, microfinance institutions and mobile money services, and a management team that wants a single customer relationship, whatever the channel, before launching new digital services.

AGILICIS role

Scoping of the journeys, then iterative implementation and adoption support: mapping of customer data sources, design of the single customer view, Salesforce configuration, integration with the core banking system and SAP via MuleSoft, compliance with Law No. 2008-12 and the frameworks of the other countries, training of advisers and the call centre.

Scope

Branch relationship (portfolio, appointments, credit, savings and bancassurance opportunities), call centre (requests, complaints, turnaround times), campaigns and journeys on the mobile app; sales steering for the network management.

Solutions

Salesforce Financial Services Cloud for advisers · Salesforce Service Cloud for the call centre · Salesforce Marketing Cloud for campaigns, where the bank chooses it · MuleSoft for integration with the core banking system and SAP · Tableau for network steering.

Status

Reference journey, presented as an illustration. Comparable real engagements are presented in a meeting, with the consent of the clients concerned.

The story

From decision to roll-out.

The decision

Management first settles a question of service, not of tooling: should a customer of the bank be recognised and served the same way in the branch, on the phone and on mobile? The answer commits the network, the call centre, marketing and compliance. It is taken by the executive committee, before any platform choice, and it sets the order of the workstreams.

Scoping

A few weeks to describe the priority journeys as they are experienced today: account opening, credit application, complaint, sales follow-up. Scoping maps every customer data source, measures the quality of contact details, lists the processing operations to declare to the CDP and to the authorities of the other countries, and checks the actual connectivity of the branches. It delivers an order of iterations, with a pilot country and observable success criteria.

The scenario

For this type of bank, the chosen scenario is often the following: the core banking system remains the master of accounts, balances and transactions; Salesforce becomes the master of the relationship, interactions and opportunities. MuleSoft exposes the core banking system and SAP through governed APIs, without copying what need not be copied. Roll-out advances in short iterations, country by country, starting with head office.

The iterations

First iteration: the single customer view and the call centre in the head office country, with a complaint tracked end to end as the success criterion. Following iterations: the branches, region by region, then campaigns and mobile journeys, then the other countries, each with its own declaration and consent rules. At each iteration, key advisers are trained ahead of the others and become the relays of adoption.

Points of attention

What makes the difference in the sub-region.

01

Law No. 2008-12, the CDP and national frameworks

A banking CRM processes sensitive personal data, in several countries. Processing operations are listed and declared to the CDP from scoping onwards; consent, retention periods and data location are designed country by country, not added afterwards. Banking secrecy and the regulator's requirements are built into the access rights model.

02

The core banking system remains the master

Balances, transactions and contracts live in the core banking system and leave it only through supervised APIs. The CRM displays, it does not duplicate. The line between what is consulted in real time and what is synchronised later is decided journey by journey, according to usage and connectivity, and documented. Where the bank runs SAP for its finance and procurement, the same MuleSoft layer serves both platforms.

03

Adviser adoption

A CRM that advisers do not fill in is worth nothing. Screens are designed with them, for the tablet and the phone as much as for the branch workstation, with as little data entry as possible and immediate value: the customer, their history, the next action. Branches with variable connectivity are tested at peak hours. Sales targets are aligned with the tool, otherwise the spreadsheets come back.

04

Customer data

The same customer often exists several times, under several spellings, with out-of-date phone numbers. Deduplication, the matching rule with the core banking system and the appointment of a customer data owner start before the first iteration. A single customer view is built on clean master data, not on a promise.

Deliverables

What the bank holds in its hands.

The deliverables of a journey of this type, as we produce them. Without quantified indicators: real results are presented in a meeting, with the consent of the clients concerned.

Scoping

Target journeys and customer data map

Priority journeys described end to end, map of customer data sources and quality, register of processing operations to declare by country, iteration plan with pilot country and success criteria.

Design

Relationship model and integration architecture

Customer data model and matching rules, allocation of roles between the core banking system, SAP and Salesforce, MuleSoft API catalogue, access rights model compliant with banking secrecy and Law No. 2008-12.

Implementation

A single customer view in service

Salesforce Financial Services Cloud and Service Cloud configured to standard, supervised integrations, customer data migrated and deduplicated, a complaint tracked end to end as the success milestone, network steering dashboards.

After the project

Teams that keep the relationship alive

Key advisers and administrators trained, guides by role, customer data governance in place, Salesforce support and application management provided from Dakar, during the network's and the call centre's working hours.

From the illustration to your case

And for your bank?

Thirty minutes with an AGILICIS expert to compare this reference journey with your network, your channels and your obligations in each country.

Let's talk