Sales Cloud Implementation Best Practices
So, you want to level up your organization’s sales game and you decided Salesforce® Sales Cloud™ is the way to get there. Congratulations! Sales Cloud is typically everyone’s first look at Salesforce. It contains the core objects that are going to help you sell more efficiently and achieve the CRM goals your organization set.
There are some pitfalls to look out for, though, when you first implement Sales Cloud. At Ad Victoriam Solutions (AdVic), we’ve implemented Sales Cloud countless times across several industries, and we’ve seen the things that trip up new Sales Cloud users and have documented some best practices and things to look out for.
Clean Up the Items Your Users Won’t Use
There can be some shock the first time you log in to a new Sales Cloud org. There are dashboard components on the home page that may not bring the most powerful data to your users. There are components that direct you to actions that may not fit your company’s needs. The navigation bar contains all sorts of items like “Notes” and “Files” that your average user may never click. It can be overwhelming for seasoned CRM users and novices alike.
Fear not! Salesforce is highly customizable, and AdVic recommends that all new orgs undertake a cleanup before any build or customization takes place. It’s important to review Lightning pages and remove components that will sidetrack or confuse users, update the navigation bar with the right tabs to direct your users to what they need to do quickly, and simplify page layouts to contain the most important and valuable data for each record.
Clearly Define Your Role Hierarchy Before Building It
Every organization, from the smallest startups to the largest enterprises, have org charts and roles to help define who fits where in the hierarchy of the company. In Sales Cloud, the Role Hierarchy is a powerful tool that lets you define unique sharing rules for record access. Sometimes, these roles will closely match your org chart. Other times, your org chart may be more complicated than is needed, which can make defining easy sharing rules difficult and frustrating for your Salesforce Admin.
Take some time to review the roles in your organization and identify where there are overlaps. A few good examples are:
· Do your C-Levels need to have different information shared with them, or should they all have the same visibility? Could you condense them into one Role within Sales Cloud to simplify how your hierarchy rolls up?
· How are your sales divisions located? Should managers only see within their designated geographic or product area, or should they all see the relevant sales data across all teams? This could represent an opportunity to flatten out some roles and save you some headaches later.
Review your Existing Data Structure
Sales Cloud has some amazing ways you can organize and visualize your data using Reports and Dashboards. This sort of insight can unlock your organization to sell at the highest level possible. The key to that lock, though, is your data and the way it’s structured.
Figuring out how your legacy data can fit into Sales Cloud can be a monumental task. No two CRMs are exactly alike, and you can save your users (and your Salesforce Admin!) a lot of headaches by reviewing and cleaning up your data ahead of time. Below are a few examples and questions to ask as you’re preparing your data for Sales Cloud:
Do you have different sales processes for different products/verticals? Is the data you capture for these deals significantly different from one another? You’ll need to designate these deals somehow and then create a specific Record Type for them. This can split out significant processes for a cleaner CRM experience for your users but needs to be considered before any data is migrated into Salesforce.
Consider how your Accounts are organized. Do you use an account hierarchy for multiple locations of the same company? Sales Cloud natively allows you to connect Account records and create an Account Hierarchy, but you’ll need to identify and connect these accounts before data migration.
