Customers, partners, suppliers – all of these are managed in the Salesforce object Accounts. In addition to the account information, topics such as account management, visit planning, and access management can also be mapped on this database. But be careful: The complexity of this object should not be underestimated.
At first glance, the Salesforce Account object seems easy to implement. But with a closer look it turns out to be not as trivial as one might think. After all, it serves to map the data of the companies with which you have (or should have) a business relationship, i.e. customers, partners, suppliers, etc.
Accounts are central to every Salesforce implementation, as additional objects such as contacts, opportunities, contracts, customer cases etc. are linked to accounts.
Before we go on: Do not discuss whether the Account object should have a different name. Account is simply the best term and will integrate very quickly into the corporate language.
An account is used to record comprehensive and diverse information about a company. But it only begins with the entry of the name: ZKB or Zürcher Kantonalbank? The legally correct name, of course, and best of all, the UID and the legal form are also entered in predefined fields. In addition, I recommend that you enter a unique short name and an account number, if not already available. But please no speaking number ranges 😉
Let’s continue to the address: Should the street and number be separated into 2 fields? Out of the box it is not like this… And do we really only need 2 addresses, or should we talk about an address object? Here, too, sufficient time must be invested to evaluate the business processes around addresses, from the capture to the proofing of documents, whether digital or printed.
It is therefore always worthwhile to consider and discuss the individual fields as a whole. Always pay attention to this and always ask: What do we want to achieve or control with this information? And are we really able to maintain these fields up-to-date? Objects often become deserts of fields and data, which has a negative impact on usability, reporting, etc.
For customers, partners, and suppliers we also collect various specific information. Here it is worth taking a look at the use of data record types and individual layouts, also in order to be able to additionally control the rights to these objects (e.g. who is allowed to enter a new supplier at all?)
Segmentation and hierarchy
If there is internal customer segmentation, then it should definitely be implemented. If there is none yet, then a good time has been found for it. Who are our key accounts? So which accounts do we look after in particular, and how?
Accounts are also often structured hierarchically (e.g. branches, holding), but not all branches are legal companies with which contracts may be concluded. This must be well mapped. In addition, accounts have partnership relationships with each other, which we would like to map in our CRM if necessary. But also here applies: How do we ensure that the data is updated and what do we control with this information?
In Salesforce, each record has an owner. This is a particularly important topic to consider, because at the latest when you want to implement a restricted access model, this value becomes very central. But what if, in addition to the account owner, there is also a deputy, an account team, or what if the account owner is dependent on other values in your implementation?
Account ownership, or record ownership, is one of the key issues in any Salesforce implementation and will be covered in a blog entry at a later date.
It’s always the same: you can’t invest enough time in analysis, design, and specification. Every hour is worth twice as much if the implementation is agile afterward. Changing an address model because the existing one is simply not correct becomes complex and expensive once integrations are live, templates are based on it and automation is running. To implement the rights model again, if all of the sudden certain information is to be made available in a limited way, is complex and costly.
Salesforce is extremely flexible, you can create a new field “just like that”, rearrange it, configure objects, etc. But to conclude from this that you should just start without thinking is wrong. This usually leads faster than you think to reduced overview, inconsistencies and finally to the frustration of the users with the implementation.
So when you start with Salesforce and get started on the Account object, take enough time to ask the right questions before you move on. That way you’ll be warming up for the later implementation of the other objects – and there are many of them – and achieve a powerful implementation.
André Ryf is Salesforce consultant, trainer and coach, and owner of squiis, your personal Salesforce Partner.
Internal Link: Salesforces-Engage