Salesforce & SQL: Get More from Your CRM Data Using the Tools You Love

Editor's Notes

• #2: So to start, I wanted to give a brief overview of what the current world of reporting on and analyzing Salesforce CRM data looks like. And after talking to a lot of companies that use Salesforce about how they analyze their Salesforce data, time and time again, 3 main methods of doing this reporting and analytics come up NEXT SLIDE
• #3: The method that we hear the most often is that companies are doing all of their Salesforce reporting inside of Salesforce’s built in reporting UI Now if companies aren’t using Salesforce’s built-in reporting functionality, what they typically tell us is that companies are exporting their data from Salesforce into spreadsheets, and doing all of their reporting and analytics in spreadsheets. The method that we hear 3rd most often, and obviously the one we tend to favor, is companies that are finding a way to send their data from Salesforce to a centralized data warehouse, and doing all of their reporting and analytics on top of this data warehouse We obviously have heard other edge cases, and we would love to get a better sense of how all of you are currently analyzing your Salesforce data. Since we hear them the most often, I wanted to briefly dive into the first two methods and get a better idea of what the benefits and limitations are of these approaches.
• #4: So let’s start with using Salesforce’s built-in reporting tools As many of you probably already know, on top of the standard CRM functionality, Salesforce also provides out of the box reporting functionality. And for really early stage companies, this built in reporting functionality may be perfectly sufficient. Things like displaying opportunities by quarter or showing the current sales pipeline are extremely simple in salesforce’s reporting UI. But more often than not, what we see happen is that companies quickly start to mature and they start asking more and more complex questions of their data, and Salesforce’s built-in reporting functionality starts to show its limitations. And Benn and I will give specific examples of some of these limitations later in the webinar. And salesforce openly admits that it is very much a CRM tool first, and a reporting tool second. The main value proposition of salesforce isn’t to help you answer complex business questions or discover trends, its to act as a robust CRM tool. So again, what happens is that more often than not, consumers of the data quickly mature and start asking more and more complex questions about their business that Salesforce’s built in reporting functionality just isn’t built to handle.
• #5: So if we can’t answer the questions we want inside of salesforce, the obvious solution is to bring that data outside of salesforce. This goes hand-in-hand with the method that we see companies utilize 2nd most often which is exporting their data from salesforce into spreadsheets, and performing their reporting and analytics out of spreadsheets. But while excel certainly improves on the analysis capabilities of Salesforce, it does come with it’s own set of limitations: SCALABILITY ORGANIZATION AUTOMATION As far as scalability goes, I’m sure many of you have experienced after accumulating a large amount of data or trying to perform a large amount of VLOOKUP functions, analytics performance in excel really starts to crumble. Operations that would be super efficient and would scale easily in data warehouse environment, can bring your computer it’s knees when done in the excel environment. And this is really apparent when we talk to customers who were accustomed to using the method, and suddenly hit a point where their data volume and analytics complexity just scales beyond what is appropriate for a non-database environment.
• #6: But aside from the scalability issue, there is also an organization issue. What we see happen more often than not is that with more and more people performing data exports and more and more analysts doing work in silo on these documents, it becomes a lot easier to become unorganized and lose that single source of truth within the company. And this is because it’s very hard to maintain a “master” version of the data, especially when multiple people are working on the same project. Tech like Google Drive has tried to improve on this
• #7: and last but certainly not least, running analysis out of excel can be a massive time sink. We’ve talked to prospects that have told us the majority of their job is to strictly export data from Salesforce into excel and prepare it for analysis. And to top this off, they said this process sometimes takes up to a whole day to perform. I don’t know about you guys but this seems like an abolsute nightmare to me. What we’ve noticed is that this extremely repeatable task is often left un-automated and handled by a human for seemingly no reason other than the technology to automate this process isn’t implemented
• #8: So to summarize, it makes sense to categorize the major limitations we’ve seen so far into two categories, Reporting Capabilities and Siloed Data. As I described earlier, Salesforce’s main value proposition is not to be a robust reporting and analytics tool, it’s to be a robust CRM tool. And this becomes more and more evident as your company starts asking more complex questions of your data. and as I explained earlier, a common method we see people take to make up for this is to export all of their salesforce data to excel and do their reporting and analytics out of excel, but as we saw earlier, excel also comes with it’s own set of scalability, organization, and automation issues. And something we haven’t touched on much yet that’s arguably the most limiting factor of them all, when your data lives exclusively in Salesforce, you lose the ability to tie this data to the rest of your company’s data sources. As companies mature, they start to ask more complex questions aimed at better understanding things like customer acquisition & behavior. And answering these questions becomes dependant on being able to tie multiple disparate data sources together. And when your data infrastructure doesn’t allow you to do this, doesn’t allow you to tie these disparate data sources together, you fail to obtain that bigger insight you’re looking for.
• #9: So what is the right way to do this? What is the best way to set yourself up so you’re prepared to run more complex analytics on your salesforce data? As many of you probably could have guessed, the obvious first step is to consolidate your salesforce data into a data warehouse, so that you can begin to harness the power of SQL on that data in an analysis-friendly environment.
• #10: But it’s important to remember that putting your Salesforce data into a data warehouse not only opens up a new world of analytics capabilities, it also allows you to solve that “siloed data” problem by centralizing all of your other data sources into the same data warehouse. Not only does this allow you to begin to tie all of your data sources together to power more complex analytics, it also allows you to have a single source of truth for all the data your business relies on. So the obvious next question is “How do I set this data pipeline up for my business?” And the answer is that plenty of companies have done this by building a custom data pipeline internally. But the problem is that more often than not, the amount of effort and resources involved are hugely underestimated. For example, Braintree devoted a team of four engineers for 6 months to build their data pipeline, and even after launch, a 2 person engineering team is required to maintain and extend the project.
• #11: Having experienced this firsthand, I can second how much effort goes into building a data pipeline like this. Prior to Mode, I worked at a large web software startup. We went to great lengths to make our Salesforce data available to analysts. It took roughly six months for us to build a stable pipeline from SFDC to our central data warehouse; once it was built, we had to dedicate a full-time engineer to it to maintain it and slowly upgrade it. Even that underestimates the cost. We had to dedicate time to monitoring it. Because we had troubles with it initially, analysts distrusted it and had to double-check data unnecessarily. And because so much of the business depended on it, if something went down, we had to have fire drills to fix it, which pulled people off other projects and slowed down development elsewhere. It was a hugely valuable pipeline for us - and a cost we gladly paid - but it was a huge cost. And this was one integration. Soon after we built the salesforce integration (and saw the tremendous value in it), we started to want to pull data from other places, like email marketing tools, etc. But because the cost was so high, we struggled to find resources for it. Not because it wouldn’t have been valuable, but just because we were capped on how many people we could dedicate to it. ----- But why is building a data pipeline so difficult? At the heart of it, there are really 7 core challenges engineering teams typically face when building a data pipeline: connections -- Your company is most likely adding new data sources all the time. With every new data source, comes a new integration you need to develop. On top of that, every API is unique and has its own challenges to develop for, including poor documentation, outdated protocols, and extremely complex data structures. Accuracy -- You need to be sure the data you’re seeing through your pipeline is 100% accurate. Minor slipups in data processing or schema evolution can easily lead to bad data. Latency -- Data is only valuable if it’s provided in low enough latency for you to analyze it, learn from it, and act on it before it’s too late. Unfortunately, extracting data from databases and APIs in real-time proves to be difficult, and optimizing this latency often leads to increased engineering efforts Scale -- As your company grows, your data grows with you. When building a data pipeline, it should be designed to scale easily with your ever-growing catalog of data. Without this focus on scalability, you could easily lock yourself into an architecture that you quickly outgrow and have to rebuild the system from the ground up Flexibility -- When you integrate with systems you don’t control, you really need to expect the unexpected. Data structures and outputs from APIs are constantly changing, and your pipeline needs to be built to handle this. For example, Salesforce has rate limits on their API. It’s not acceptable for your data extraction job to take your entire sales team offline for the day. So you have to be prepared to accommodate these inflexible systems. Monitoring -- When data starts flowing from such a large number of data sources, failures are inevitable. The problem is that teams often have to dedicate considerate engineering effort just to build monitoring tools for their data pipeline. Maintenance -- this is the final kicker. The data pipeline project doesn’t typically have a real end. All of the factors I just mentioned are often only solved through an ongoing, dedicated maintenance team for the data pipeline.
• #12: The issues that Benn just mentioned were the exact issues we were trying to solve when we built Pipeline.
• #13: To reiterate, pipeline takes data from any number of data sources and enables that data to continuously flow directly into a single Amazon Redshift data warehouse. Right now, we’re extremely focused on expanding our base of integrations, so if you need an integration you don’t see here today, let us know! If you want to learn more about this, stick around at the end for a demo.
• #14: So now that we’ve gone over exactly “how” you can get your salesforce data into a SQL-ready and analytics-friendly environment, Benn is going to start this section by showing you how you can really start to harness the power of SQL to improve your Salesforce reporting.
• #15: And the way that Benn will show you how to start doing that is by layering Mode directly on top of your redshift data warehouse. We here at RJ love using Mode internally for our analytics, mostly due to the ability to pretty rapidly move from SQL query to visualization, and to expand that analysis outwards to the company for collaboration and sharing. And with that, I’ll pass it over to Benn to showcase some examples of how using Mode on top of a data warehouse that contains your Salesforce data can really expand your analytics capabilities.
• #16: Before sharing any examples using Mode, I’m going to start with something you’re probably already familiar with - Salesforce reporting. I want to walk through how to use SFDC to answer a couple basic questions. The first, let’s see how much new business we close each month. This is clearly important, and should be pretty simple. Second, let’s add one wrinkle. Our sales team doesn’t just want to know how much business closed, but they also want to know how long it took to close those deals. We want to know if our sales cycle is getting longer or shorter. Not only does this have obvious implications for financial projections and sales resource allocation, but it can also help us better understand our sales team’s performance.
• #17: The first of these questions is pretty simple in SFDC. I’m sure many of you could quickly create this report, as I have on some sample data here. You can see the Salesforce filters below the chart - just show me all the opportunities where stage is closed won, and the the type is new business. No problem. So, can I recreate this in Mode using RJMetrics data? In other words, this is pretty easy - does it stay easy?
• #18: For those comfortable in SQL, it’s just as easy. Here’s the query that returns the exact same result. Show me opportunities where stage name is closed, type is new business, and group them by the month they closed. Pretty simple too. And this also shows how translating from SFDC to SQL can be pretty easy. The SFDC filters often show you exactly what your query looks like. It’s actually been surprisingly easy for us to move from SFDC to Mode reports.
• #19: In Mode, you can how run that query and put a chart on top of it. I did that here, and this shows a report in Mode that mirrors the SFDC report before. Because this is sitting on top of live SFDC data piped in by RJM, you can click the refresh button in the upper right to get the latest numbers. (And you can provide access to people regardless of if they have a SFDC license.)
• #20: Ok, so great. But that was only the first half of the question. I also want to cohort by deal length. I want to show, of those deals in the previous chart, how many changed in 1 month, 2 months, etc. Here, suddenly salesforce gets complicated. The SFDC reporting tool doesn’t let us do this, to my knowledge, at all. There may be some SFDC wizards out there, but I haven’t figured out how this can be done. You can see when opportunities were created and closed, but I can’t do any math there. At this point, we’d have to export to excel. That’s no good, for a number of reasons that david already outlined. Data is no longer live, it requires manual updates, and at a certain scale, it becomes very hard to use. Nothing in the bar on the left is in any discernible order. BOO.
• #21: However, using RJM and Mode, you can accomplish this with one additional line of SQL. That second line that says DATEDIFF, that calculates the time between when and opportunity was created and closed. By adding that line, I can now cohort my opportunities by age. That’s all it takes.
• #22: And if I want to add this to my chart, I can quickly do this. It is another report in Mode, this time showing deals cohorted by length. From this, we can quickly see that a lot of deals closed quickly in September and October. And as before, this is all live against the database. If you want to update it, just click refresh. no export to excel, no copy and paste, no repetitive work. Create it once and you’re done.
• #23: This is actually just one of many examples of the benefits of using SQL over Salesforce data in SFDC or in Excel. First, using raw data, you can calculate metrics that aren’t easy to calculate in SFDC. Things like the time between one stage to a next (how long does it take to get from In contact to contract negotiation for example). Rather than estimating close probabilities, you can calculate actual historical close rates, and use that make more accurate sales forecasts. And you can look at things like how many touches from a sales person are required to move a deal from one stage to the next? Does that vary by rep, industry, or stage? All of these questions are quickly answerable in SQL, and hard, if not impossible otherwise. A second benefit is that working in SQL lets you work around messy data. For nearly everyone I talk to, at some point, their sfdc data gets messy. Accounts are created twice, new salespeople mislabel an account as new business, and other data entry problems emerge. If you’re working with sfdc, you don’t really have a way to work around these issues. You want new business, you get everything that’s flagged as new business. In SQL, you can work around these problems. You can change your query so it doesn’t just look for new business, but it looks for the first opportunity associated with an account, regardless of the business type. Or you can only look at distinct account names so you can weed about duplicate accounts. A side benefit of this is you can also use it to surface and clean up messy data. Finding duplicate accounts is suddenly easy. For a few more real world examples of the benefits of using SFDC data, I’ll turn it back over to David.
• #24: Thanks, Benn. And just to add to what you’re saying, here are two more examples of analysis we’re doing on our existing SF data that would be really challenging to do in Salesforce. The chart you’re currently seeing is a chart we use internally to track top of funnel sales activities for our account development representatives. For us, the number of calls held in a day is a pretty critical leading indicator for deeper funnel sales performance the following week, so it’s really important for our sales team leads to make sure we’re always improving on this front. This chart allows us to quickly observe how our daily performance differs week over week, and allows us to identify shortcomings as they happen and to act on them before it really becomes too late. And again, this is a great example of a relatively simple, but very insightful chart that just wouldnt have been possible to build in Salesforces reporting UI.
• #25: Here’s another one. This is still using 100% Salesforce data, but now we’ve layering daily goal data over top it. This additional layer of information makes this chart really valuable to our sales leaders.
• #26: Using raw salesforce data, particularly with RJM, has one other huge benefit that I didn’t mention yet - you can combine it with other data that lives outside of salesforce. I want to show you an example of this, and talk about something we do for ourselves here at Mode. When our sales team reaches out to new clients, or to existing clients looking for renewals, they want to make sure they’re talking to our champions. They want to make sure that the person they call is the one who likes Mode the most. With Mode and RJM, we can give them the tools to do this.
• #27: We do it by combining product and Salesforce data. This query, which is a bit more complicated than the previous ones, shows how we accomplish this. The first third of this query uses activities logged in SFDC to see how many times we’ve reached out to contacts at the company Octan. The second third uses product login data to calculate how many times each user at Octan has logged in to Mode. The final third joins these together, producing a list of logins and sales contacts by user at Octan.
• #28: We can see the result here. This table, again in a live updateble Mode report, shows a table with a user’s name, how often they’ve logged in, when they last logged in, and how many times our sales team has contacted them. We can see for this account, the sales team is doing a good job. The top two users have been contacted a few times. The most contacted user, however, is the 10th or so most active person. This isn’t necessarily wrong, but it shows that in this account, we might have an opportunity to talk to other champions like James. We can also see that Matthew used to be a champion, but hasn’t logged in a month. That might be worth investigating too. So, this report is helpful and all, but we want to make sure our sales team looks at it every time they’re reaching out to a prospect. In Mode, it’s easy to make this a flexible, dyanmic tool that can work for any account.
• #29: By adding parameters to reports, the sales team can enter an account name in this form and update the query. This will refresh the results for that specific account, without requring the sales team to write any SQL. This allows analysts to quickly turn their queries and reports into dynamic tools that can be reused by the rest of the business.
• #30: But, for this report, we can actually go a step further and make it even more accessible for our sales team. This is the URL for that report.
• #31: By adding a couple parameters to the end of the report URL, we can now auto run this report, with a specific parameter, anytime someone clicks on this link. Click this link, the report will automatically refresh for the chosen account name.
• #32: We used these by creating a custom field in SFDC for accounts. The field automatically generates that report URL and adds the account name in the correct place. Now, whenver our sales team looks at an account in SFDC, all they have to do is click a link to see the most active people in that account, and how much they’ve been contacted. What was a simple look up to see how we’re doing at one account is now a fully integrated tool accessible to our entire sales team.
• #33: Again, this is just one possible use for combining data. There are lots of other data sources you could combine with SFDC, and lots of other questions you could answer. For example, maybe you want the same thing, but want to see who’s been the most active in the last week. If you have a new champion at an account, make sure to reach out to them while they’re still in the honeymoon phase with your product. Second, you may want to look at other indicators to find champions. Maybe, for example, you’d like to see who’s had a great experience with support. If you integrate support center data, you can see who’s had tickets closed quickly, or who’s rated your support team highly. Third, maybe you’re looking for people to avoid. As in the example, logins aren’t enough - you also want to know if someone hasn’t logged in recently. Or maybe you want to see who’s had a lousy experience with support. Who’s submitted a lot of tickets? They may not be the person to call. Finally, I’ll turn it over to David once more, who can show a couple examples of how RJM uses these combinations.
• #34: So this is actually a great example of the kinds of things you can do once you start to consolidate all of your data sources. This is actually something we recently wrote a blog post about on Mode’s blog and this is essential a comprehensive acquisition and onboarding funnel for our Pipeline product. Basically, we wanted the ability to track a single prospect from the first time they visit our website, to the moment that they become a paying customer. And we wanted to be able to see at which steps in between these two points were the steps that were acting as bottlenecks in the process. The problem is that the data for each of these individual steps lives in a variety of different data sources, including redshift via snowplow, pardot, and various MySQL and postgres databases. Luckily, Pipeline allows us to consolidate all of these data sources into our redshift data warehouse, and write a single query that can produce that beautiful chart you see in front of you. Now we can get really quick insight into exactly where users are falling off in this process and watch how this funnel changes over time.
• #35: Another recent example of an analysis that is really important to us internally that would really only be possible with a data pipeline tool, is being able to look at our Self-Service Score over time. As many of you probably already know, the self-service score is a really great measure of how effective your help center is in getting users to service themselves instead of filing support tickets. It’s calculated as the ratio of unique people visiting your help center content and attemtping to service themselves to the unique number of people filing support tickets. The problem here being that the data to determine the number of people visiting our help center is collected and dumped into our redshift via snowplow, and the data to determine the number of people filing support tickets lives in Zendesk. Again, pipeline allowed us to quickly consolidate these two data sources into the same data warehouse and now we’re able to have a report that monitors this KPI over time. And the examples we just went over are really only scratching the surface of the kinds of analytics capabilities that open up once you start to consolidate your Salesforce, Help Center, Web Analytics, or production data into a single data warehouse. And luckily we’re entering a time where technology like Pipeline and Mode make this process easier than ever to setup.