So this will be the first blog within our Salesforce Financial Services Cloud (FSC) series that will cover modelling relationships. In this blog we will mainly focus on “Households”.
Purpose of relationship modelling
Firstly, lets look at why this is such a key part of Salesforce FSC for banking. The value and the complexity of a relationship are the deciding factors in the use of this feature. The ability to visualise, monitor and control relationships becomes increasingly important for the higher value relationships. The reason for this is simple. It is far more likely that there will be many more parties involved, each with unique roles to play in the overall relationship. This is as true in Wealth as it is in Corporate.
At the opposite end of the scale, in mass market relationships, this tends to be far less true. The business-as-usual relationship for the majority of customers is simplistic – they are the owner of their financial products and services, perhaps with one other party on joint accounts. Even here however, there are use cases where relationship modelling will serve a useful purpose:
Third parties – for example powers of attorney, executors, trustees are still true in retail banking even if less common
Mortgages – for example brokers, solicitors, guarantors
Being able to visualise the network of relationships does add value in itself, but equally important, linking parties in this manner also allows you to view data at an aggregated level and see the overall value of a particular relationship. This can be as important as the net £ value of a given group.
Our apocryphal example is the son or daughter of a wealthy Chief Executive of an important corporate client who receives very poor customer service. This may result in the loss of significant business not only from the said son or daughter, but also from the both the CEO’s personal wealth and his firm. Being able to see the full context of the individual and their relationship with the financial institution, helps prevent such scenarios.
How FSC works for modelling relationships
FSC allows us to model both complex multi-party relationships, and one-to-one relationships. The primary vehicle for creating groups of related parties is through Households. Households are a type of Account record (not specific to FSC) that enables some special features to provide an insight and an overview into the collective position for that group of related people and/or businesses. This helps fill some of the gap left over from Person Accounts as Person Accounts cannot form part of an Account hierarchy.
Group membership is modelled through the Account Contact Relationship object (also not specific to FSC) which allows direct membership (for individuals) or indirect (for business).
There are two further concepts that come with group membership:
Primary Group – people can only be a member of a single Primary Group. This has a huge impact on Roll Ups (to be covered in a following article).
Everything covered so far (Households/Account to Contact) is actually part of Sales/Service Cloud so what does Financial Services Cloud add?
The relationship between businesses, institutions, and groups.
The relationship between two people.
The nature of the relationship between a person and another person, business, or other account. For example, Proprietor and Owned Business. Used on the Account-Account Relationship and Contact-Contact Relationship objects.
Essentially, FSC adds the ability to handle the more complex relationships and overcome the limits of account to contact (as by definition they can only handle those particular object relationships).
Account to Account
Salesforce themselves provide an excellent view for this use case:
“Create business and personal account relationship hierarchies using the enhanced Account-Account Relationship entity. Directly associate businesses and legal entities, such as trusts, to households and groups. It’s easy to view a parent company and its subsidiaries, as well as family relationships, in the enhanced Relationship Map.”
Contact to Contact
Represents the relationship between any two individuals. This will be particularly useful when you are modelling the relationship between two non-customers i.e. who will not have an Account record. To reuse our example from earlier with a slight tweak, where a party related to the CEO of a corporate customer (who in this case does not have a personal relationship) is a customer of the bank. In that case the party we are dealing with would have an Account and a Contact, the Corporate would be an Account, and the CEO would be a Contact. We can link the two Contacts directly.
Reciprocal roles are something of a ‘behind the scenes’ object, but are extremely useful to standardise the definition of the role (and its reciprocation) between any two entities. When you create either an Account to Account or Contact to Contact relationship, this will come into play and automatically prompt you to create a reciprocal role i.e. spouse to spouse, stock broker to client etc.
One final point, there is currently an omission (in my view at least) in that it is not as easy to model the roles of different internal users (for example a wealth relationship manager, the corporate manager etc). It would of course be possible to simply model them as contacts, but it would be more useful to have an account/contact to user relationship, along with the nature of that role, modelled in the same way. At the moment this would need to be customised.
Next time I will cover the visualisation of these elements via the Actionable Re lationship Centre and the Relationship Map.
If you would like to find out more about how Salesforce Financial Services Cloud can help optimise employee productivity and customer experience, give us a call or email us at email@example.com.