- As product owner of the Salesforce platform, a good portion of your job should be pushing for more resources. There are so many things that get in the way of doing this. You don’t want to be seen as greedy or land-grabbing, you don’t want to be perceived as complaining about work-load or being unable to do the job with what you have. Push through all that and try to get the resources you need. Every situation is different, but ideally you want one certified Salesforce Administrator per every hundred seats.
- The goal of every Salesforce instance is to produce good business data. For years, I operated under the assumption that if we designed the system properly, end users would create good data. System + End User = Good Data ended up being a frustratingly elusive proposition. An much more successful equation is: System + End User + Super User = Good Data. This is a big paradigm shift. There has to be at least one person in each group of end users who is not only officially responsible for the quality of their team’s data but actually wants to be in that position.
- Get good at doing software evaluation. My experience with build vs. buy decisions and the Salesforce app ecosystem is that the majority of application makers understand what problems organizations want Salesforce to solve for them and are good at saying that they’ve solved them. Some of them have but often not completely and not in ways that can easily be customized for your organization’s particular needs. I have had several experiences of buying applications and having them fail in the implementation process for non-technical reasons. If your company has a good software evaluation process, see if you can plug into it. If not, find one or develop one yourself, it will pay for itself many times over.
- One of the biggest victories you can have will be teaching your stakeholders the difference between configuration and customization. Convince them that it’s better to configure the system and alter their processes to meet the system halfway than it is to stick to an existing process and do a lot of customization. Salesforce customization is so technologically easy that it can become a little like a drug. The promise of instant customization is awesome but a workflow here and a formula there and a validation rule there can quickly create a system that’s so full of interrelated automation that it becomes unwieldy. The less customization there is, the faster a Salesforce group can make changes to satisfy end-users. That’s worth fighting for.
- Last tip — try as hard as you can to get people talking about business processes in Salesforce as opposed to Salesforce objects. Talking about how your company handles a process like Inside Sales Prospect Assignment is infinitely more productive than talking about “Leads.” Create a process map to shift the conversation from objects to processes. Don’t be afraid to get detailed. You may be surprised at how many of your colleagues say that they’d never known that Salesforce was used for so much!
You’ll find few fans of Salesforce reporting bigger than me but it does have its limitations. Sooner or later, every Salesforce user or admin is going to want to grab some Salesforce data, export it, get it into Excel, and mess around with it. This happens every day, every hour, all the time. Using Excel or another tool to get more out of your Salesforce data is great — it shouldn’t matter what tool you use, it’s your data, make the most of it!
The only problem is, once the data is in Excel, it’s easier for it to get confused. Why do the numbers in your spreadsheet not match mine? Is this an Opportunities report or an Account report? Wait, did I pull this based on Close Date or Open Date? If you’re spending time on answering questions like that, you’re missing out on time that could be spent making important discoveries from your data and decisions based on them.
Here is one simple technique I use to make sure that every report I pull for a client remains free from distracting debate.
Build a report guide
One one tab of your spreadsheet — I prefer the farthest to the left — build a guide to the component reports and data that come together in your spreadsheet.
- Base Files – list every report you used in the spreadsheet with a report name and link to the report in Salesforce. If you’re building for regular refreshes, leave a note in the name or description of the report that it should not be edited.
- One Row Equals – this is the most common mistake that causes confusion, especially if you ever want to count the number of rows in a report. What does one row equal? In an Opportunity report, one row equals one Opportunity. In an Opportunities with Products report, one row equals one Opportunity Line-Item or product. If you try to count the number of rows in the second report to the total number of Opportunities in a segment, you will come up with a very wrong and confusing figure. Eliminate that mistake before it happens.
- Fields Used – for each Salesforce Object used in your source reports, list out the fields you’ve selected. This is particularly important for value fields, to ensure there’s no confusion over whether you’re looking at a per client value, a per Opportunity value, or a per product value.