Customer Interaction & CRM

The memory of the bank

Customer interaction and CRM are the bank's memory. They capture who the customer is, what relationship the customer has with the bank, what the customer asked, what the bank promised, what actions were taken, what cases are open, what complaints exist, what opportunities are relevant, what preferences and consents apply, and what should happen next. Without this memory, every channel behaves like it is meeting the customer for the first time.

A customer may contact the bank through mobile chat, branch, contact centre, relationship manager, email, secure message, social channel, or partner journey. A business customer may speak to a relationship manager, upload documents, raise a payment investigation, request a new user, negotiate a facility renewal, complain about a fee, or ask for card controls. The CRM layer should connect these interactions into one usable customer story.

CRM is not only a sales tool. In banking, CRM is a servicing, conduct, complaint, risk, relationship, operations, and evidence system. It helps the bank support customers, manage cases, follow up promises, route work, monitor service quality, and understand the customer relationship. A bank that uses CRM only for leads misses the point. A bank that uses CRM only for notes creates risk because notes cannot control workflows.

This chapter explains customer interaction and CRM from a functional implementation view for consumer and business banking. It covers customer 360, interaction history, cases, complaints, service requests, relationship management, business hierarchies, consent, contactability, next best action, staff permissions, integration, data quality, reporting, testing, operations, and production support.

Learning objectives

By the end of this chapter, you should be able to explain what CRM means in banking, how customer 360 differs from a static profile, how interaction history supports omnichannel service, how cases and service requests should work, how complaints need evidence and root cause, how relationship managers use CRM, how business hierarchies affect servicing, how consent and preferences shape contact, and how CRM integrates with channels, core systems, notifications, analytics, and operations.

You should also be able to identify weak CRM implementations: free-text notes replacing workflows, duplicate customer records, staff unable to see digital history, complaints not linked to root cause, sales offers made without eligibility, vulnerable-customer indicators ignored, business hierarchy missing, and service-level breaches hidden in queues.

What CRM means in banking

CRM in banking is the controlled management of customer relationships, interactions, cases, opportunities, preferences, and service evidence. It is not simply a database of names and phone numbers. It is the workbench that helps staff understand the customer, serve the customer, protect the customer, and coordinate action across the bank.

A customer 360 view should show identity, contact details, relationships, products, account summaries, recent interactions, open cases, complaints, alerts, preferences, consent, vulnerability indicators where applicable, risk flags, assigned relationship manager, and relevant next actions. It should not expose more data than the user is allowed to see. A collections user, branch teller, contact-centre agent, fraud analyst, and relationship manager may need different views.

Interaction history should capture the channel, date, customer, staff member, intent, outcome, related product, related case, customer sentiment where used, promised action, and follow-up. A useful interaction history is structured enough to search and report, but human enough to explain context. It should not become a dumping ground for uncontrolled notes.

Customer 360 and the party model

A bank's customer is rarely just one record. A person may be an individual customer, joint-account holder, cardholder, borrower, guarantor, director, beneficial owner, business administrator, and household member. A company may have subsidiaries, branches, authorised signers, employees, guarantors, related parties, and group exposure. CRM should represent these relationships accurately.

The party model should distinguish person, organisation, household, business group, role, relationship, authority, and product relationship. A customer may be allowed to view one account but not another. A director may be authorised for a company but not personally liable for a loan unless a guarantee exists. A relationship manager may cover a portfolio but not have authority to approve every action. The CRM view should not flatten these distinctions.

Customer 360 should include context, not only data. It should show recent failed digital journeys, open disputes, pending documents, upcoming renewal, complaint history, missed callbacks, vulnerable-customer support needs, and service promises. Context is what turns CRM from a profile screen into a service tool.

Cases, service requests, and complaints

A case is a unit of work that needs ownership, status, SLA, evidence, communication, and closure. Cases may include address change, card replacement, payment investigation, loan servicing, complaint, document request, fraud report, dispute, KYC refresh, deceased customer handling, mandate update, or technical issue. The case should have type, reason, customer, product, priority, owner, status, due date, channel, attachments, notes, tasks, decisions, and closure reason.

A service request is often an operational case with a defined fulfilment path. It may require validation, approval, downstream action, and customer confirmation. A complaint requires stronger controls: acknowledgement, classification, investigation, root cause, regulatory timeframe, outcome, compensation where applicable, customer response, escalation, and reporting.

Free-text notes cannot replace cases. A note saying customer unhappy does not create SLA, owner, root cause, or reporting. A complaint hidden as a note creates regulatory risk. A payment investigation hidden as a note creates customer harm. Work that needs action should be a case or task.

CRM and relationship management

Relationship managers use CRM differently from contact-centre agents. They need portfolio view, customer group exposure, products, profitability, upcoming maturities, renewal dates, covenants, opportunities, risks, complaints, service issues, meeting notes, call reports, and action plans. A business relationship is ongoing and advisory, not only transactional.

A relationship-manager call report should capture who attended, topics discussed, financial updates, customer needs, risks, commitments, follow-up actions, documents requested, opportunities, and issues escalated. It should be structured enough to support credit review and customer continuity. If a relationship manager leaves, the next manager should understand the history without hunting emails.

CRM should also protect customers from poor sales behaviour. Offers should respect eligibility, affordability, consent, contactability, suitability, and conduct rules. Next-best-action should not push products into unsuitable contexts. A customer in hardship should not receive aggressive credit marketing. A business with a complaint should not be treated as a normal sales opportunity until the issue is understood.

Functional CRM implementation catalogue

A world-class banking CRM is built from owned capabilities. Each capability should have a clear purpose, data owner, workflow owner, entitlement rule, audit record, integration contract, reporting use, and support process.

Customer 360 profile

Customer 360 profile should define the customer or party scope, eligible channels, staff roles, required data, source of truth, workflow status, SLA, audit fields, reporting dimensions, and downstream integrations. Runtime behaviour should make the customer's context visible without exposing data unnecessarily. The CRM should connect interactions, cases, products, consents, preferences, complaints, tasks, and communications so staff can serve the customer without asking the same questions repeatedly.

For consumer banking, Customer 360 profile should support simple service, clear ownership, vulnerable-customer care, complaint evidence, preference-respecting communication, and fast handoff between digital and human support. For business banking, it should also support company hierarchy, authorised contacts, relationship-manager coverage, product complexity, mandate changes, renewal cycles, document tracking, and multi-user interactions. Staff permissions must decide who can view, edit, assign, close, escalate, or export information.

Testing should cover new customer, existing customer, duplicate customer, joint relationship, business group, missing consent, communication restriction, vulnerable customer, open complaint, SLA breach, staff reassignment, branch-to-contact-centre handoff, digital escalation, attachment upload, downstream failure, audit retrieval, report extract, privacy request, and production support correction. A CRM capability is complete only when the bank can prove what happened and who owns the next action.

Party and relationship model

Party and relationship model should define the customer or party scope, eligible channels, staff roles, required data, source of truth, workflow status, SLA, audit fields, reporting dimensions, and downstream integrations. Runtime behaviour should make the customer's context visible without exposing data unnecessarily.

For consumer banking, Party and relationship model should support simple service, clear ownership, vulnerable-customer care, complaint evidence, preference-respecting communication, and fast handoff between digital and human support. Staff permissions must decide who can view, edit, assign, close, escalate, or export information.

A CRM capability is complete only when the bank can prove what happened and who owns the next action.

For consumer banking, Staff permissions should support simple service, clear ownership, vulnerable-customer care, complaint evidence, preference-respecting communication, and fast handoff between digital and human support. Staff permissions must decide who can view, edit, assign, close, escalate, or export information.

CRM data model

A practical CRM data model should include party, customer, relationship, household, organisation, contact point, preference, consent, interaction, case, task, complaint, opportunity, product relationship, staff owner, business hierarchy, document, communication, SLA, queue, root cause, and audit event.

The interaction record should capture channel, intent, customer, staff actor if any, date, outcome, related case, related product, and follow-up. The case record should capture type, reason, priority, owner, status, due date, evidence, decisions, communications, and closure. The complaint record should add regulatory clock, root cause, resolution, compensation, escalation, and reportability.

The CRM data model must avoid uncontrolled duplication. If the bank has separate records for the same person, service history becomes fragmented and risk controls weaken. Duplicate resolution should be controlled because merging customers can expose data or corrupt history if done casually.

Acceptance scenarios

Common implementation mistakes

CRM as only free-text notes

Notes are useful, but workflows need statuses, owners, SLAs, evidence, and closure. A bank cannot manage service quality through unstructured notes alone.

No business hierarchy

Business banking CRM fails when it cannot show companies, subsidiaries, authorised contacts, administrators, products, and relationship coverage.

Sales without conduct controls

CRM should not push offers without eligibility, consent, suitability, and customer context. Sales relevance must not override customer care.

Poor complaint classification

Complaints hidden as service notes create regulatory and conduct risk. Complaint intake must be explicit and reportable.

Duplicate customer records

Duplicates fragment history, cause repeated questions, and can create privacy issues. Matching and merge need controlled workflow.

Best-practice principles

Make CRM the bank's operational memory. Structure cases. Preserve interaction history. Respect consent and preferences. Model business relationships deeply. Link complaints to root cause. Connect digital and assisted channels. Give staff the right context and no more than they need. Measure service quality, not only sales. Make every promise traceable to an owner and due date.

Practical example: payment investigation

A customer reports that a payment has not reached the beneficiary. The agent searches transaction history, creates a payment investigation case, links the payment reference, records customer explanation, assigns operations, and sends acknowledgement. Operations updates the case after checking payment status. The customer receives updates through preferred channel. If the issue becomes a complaint, the case is reclassified without losing history.

Practical example: business relationship review

A relationship manager meets a business client before facility renewal. CRM shows open service issues, profitability, products, upcoming maturity, covenant due date, documents missing, previous complaints, and new opportunity notes. The RM records meeting notes, assigns tasks for financial statements, and links the action plan to the renewal case. Credit can later see the relationship context.

Final perspective

Customer interaction and CRM are the bank's memory, coordination layer, and service conscience. They help the bank remember the customer, honour promises, route work, manage complaints, support staff, and learn from every interaction. A world-class CRM does not feel like admin. It feels like continuity.

The best CRM implementations make the bank more human because staff are not blind. They know what happened, what matters, who owns the next action, and how to help without making the customer restart the story.

Standards and authoritative references

Implementations should use current official and bank-approved sources covering privacy, consent, complaints, conduct, accessibility, data retention, outsourcing, operational resilience, marketing, sales suitability, vulnerable customers, and customer communications. Bank CRM policy, complaint policy, contact policy, data-quality standards, role-access model, and service procedures should be treated as binding implementation inputs.

Turn a missed promise into owned work

A sole trader reports a failed payroll payout and a duplicate fee during a contact-centre call. Create linked payment-investigation, billing-correction and complaint records rather than a note saying 'call back'. Assign named queues, local complaint deadlines, promised callback and the original instruction identifier. The relationship manager can explain status but cannot invent a settled outcome or approve their own fee concession. Confirm the recovered payout from the payment service and the fee adjustment from the ledger before closing the service request.

The CRM contains references and permitted views of financial records; it does not become the balance source of truth. A case summary must distinguish customer allegation, staff observation and verified system result. Restrict health or vulnerability data, use approved structured support needs, and apply a documented legal basis and retention schedule. Do not assume every service interaction or use of personal data requires marketing consent. Under the EU GDPR, consent is one of several legal bases and special-category data has additional conditions; see GDPR Articles 6 and 9.