Philipp Stelzer: Hello, and welcome to another edition of the RevOps Lab podcast. My name is Philipp, and today I'm doing a special episode with no guests and no Janis because he's currently traveling, and he's also busy planning the next big thing. So you'll hear more about that very soon.

Philipp Stelzer: But in the meantime, I just thought, hey, let's use this opportunity and talk a bit about our experience with different CRM setups and what are some of the most common issues that they all share. Because, yeah, every day I actually do spend time talking to different customers, prospects, and to understand their CRM setup, to see if we could actually help them and to understand their pain points. Those are people who work in healthcare, finance, telecommunications, tech, other SaaS companies, so quite a broad range, but the issues that you actually can see in their CRM setups are all pretty much the same.

Philipp Stelzer: And, yeah, maybe just as a short prerequisite and a reminder of what Weflow does and why I think, you know, there's some authority to talk about topics like this — Weflow is actually based on the Salesforce CRM, but that doesn't mean that if you're using HubSpot, this episode is irrelevant to you. I think the issues are exactly the same. It's just a different platform. So Weflow is based on top of Salesforce, and we basically do three connected things. Number one, we automate updates and activity tracking so that you have a high quality of data in your CRM. That means tracking emails, tracking meetings, trying to automate as much of updates to Salesforce as possible. Then secondly, with that high quality data, we start to surface deals and pipeline insights, so both the sales managers and the reps have better visibility into the pipeline and the prioritization. They can ask the right questions. They see what is missing. They actually move the deal forward, and also they understand whether the deal is actually moving forward. And then with this improved visibility, revenue teams can then run an effective forecasting process with Weflow from the sales rep to the CRO, so sort of like a bottom-up approach in terms of forecasting, so you achieve high forecasting accuracy and can then confidently talk to the CFO and CEO or board of directors.

Philipp Stelzer: Those are the three things that we do. And as part of that, obviously, we go through large parts of our customers' CRM setups. And yeah, so with that in mind, here's a collection of the most common mistakes we see in Salesforce setups, and also some things come from what guests have shared on this show and our years of experience in the industry. I think in total, it's seven cardinal sins, and then I have a bonus sin sort of like on top of that. So let's get started with that.

Philipp Stelzer: Alright. So number one, using external developers without someone in house to manage and document. So I think this is a big one. Salesforce is a huge ecosystem. So is HubSpot. And what you typically see is that there's a lot of consultants and developers who specialize in HubSpot and Salesforce — I think more so for Salesforce than for HubSpot — and this can make a lot of sense to work with an external developer. So this is not a case against working with external developers. But I think what is really important is that you really put a lot of effort internally in having someone who manages these external developers and also documents all the changes. So you need to have someone who sort of like acts as a product manager or a project manager, however you wanna call that role, and really has a good understanding of what the developer's doing, whether it makes sense what they are doing, and also document the business logic behind it, particularly if it's around developing more complicated custom objects, creating Lightning components and special Visualforce pages and things like this. So this really needs to be understood because if for some reason you stop working with those developers and there's no documentation, this is not going to be a good situation for your business continuity.

Philipp Stelzer: And just wanna stress the point that whoever manages external developers should also have a good understanding of Salesforce. So just to give you one anecdote here, there's one company that we talked to. They basically wanted to have a territory management system because they operate globally, so they wanted to split all the different geos into different territories and then do forecasting by territory, have reps assigned to different territories, and so on. And they worked with an external developer to do all that for them. But as it turns out, that functionality actually exists by default out of the box in Salesforce. You just need to activate it and set it up. So all the work that those external developers did was completely outside of the standard processes and the APIs that Salesforce already provides. And now they have this territory management system that no other third party solution can plug into, which is a bummer for them. So they now have to make that migration from the custom territory system to the standard territory system that already exists in Salesforce. So, yeah, that's a lot of lost money and time, and it could have been easily avoided. So just, you know, one very unfortunate example of how working with external developers can go wrong. And just again, when I say it's totally fine to work with external developers and to use third party solutions, that's not the case that I'm trying to make here. It's all about documenting and understanding of what's going on under the hood.

Philipp Stelzer: Okay. Secondly, over-customization. Now, Salesforce comes with a couple of standard fields, and actually all of them are, in my opinion, pretty useful. You can make a case about one or two here. There's a lot of discussion around the lead object, of course, but I think if you just look at opportunity, account, contact, then you can already go a very, very long way with what comes with Salesforce out of the box. And in my opinion, that actually makes sense, particularly if you are a younger company where the sales process is not perfectly designed and there's still bigger changes in how you actually do sales — just stick to the standard process that Salesforce gives you, and then over time start to customize this more. So what I'm typically seeing is a lot of custom objects and custom fields that are being added, and they're kind of like even duplicates of existing functionality, so it's not really adding value, it's just adding complexity. And then also asking reps to fill out way too many fields. So too many fields is one of the key things we're constantly seeing, and then the sad truth is those fields are not filled out. So you have those fields, but then if nobody's using them, do you really have those fields? Yeah, I don't think so. So don't spend too much time on over-customization, particularly when you're a young business. It only makes sense to really start investing heavily into customization in Salesforce or HubSpot or any CRM really if you have a very clear sales process that's been working for a few years. So don't over-customize. That's the key thing I want to really stress.

Philipp Stelzer: And, yeah, the third point is too many custom fields. I know this is sort of like an overlap with the point I was trying to make before, but I think it's worth its own point on the list here of the most deadly cardinal sins for CRM setups because, really, what most sales leaders care about is the stage conversion rate and then a small set of critical information that fits to the sales methodology that the organization is using. So MEDDIC. Right? MEDDIC is the most common methodology out there. You don't need that many fields for it on an opportunity object. It's just a few. And so just stick to that. Don't try to invent too many KPIs that nobody really wants to look at. Just focus on very few KPIs. Just focus on MEDDIC, for example, just focus on the stage conversion rates, look at that. It's already hard enough to do, and only if there's a really, really, really good reason to build more, then you do more. But don't fall into that trap that more KPIs is better — often it's not, particularly if you focus just on the sales process here. And another problem with that is, you know, the more fields, the more manual data entry. So in the end, everyone in the organization, particularly the sales reps, they will thank you for keeping things simple and straightforward. And then if you add custom fields, just make sure you give them descriptions and hints for future generations of CRM managers, because they will thank you if they understand what is going on with these fields.

Philipp Stelzer: Alright. The fourth point, insufficient data governance. So, yeah, CRMs are expensive. I think that's fair to say both for HubSpot and Salesforce — really any CRM out there at this point, I would say. So cost should not be the deciding factor in which CRM you're picking. But the key point here is CRMs are expensive, and they only make sense if you actually have good data governance. And good data governance comes sort of like from the things I talked about before — they come from a clear process and good standardization. Just a few key fields and metrics are usually the path to the biggest success. So you need to constantly invest time into keeping the data clean and healthy. And that sometimes means you develop automations that just help. For example, you have an automation that automatically closes an opportunity after, I don't know, four weeks or something like this, right? That makes sure that if there is no activity on opportunities, you automatically close them after four weeks. That keeps your pipeline relatively clean, and worst case, a new opportunity needs to be opened if that deal suddenly becomes relevant again. That's just really common sense to do that. A lot of companies don't, and then they end up with overloaded pipelines that are actually never going to close and paint an unrealistic picture of how reality looks like. So that's really something you should invest time into, particularly. Sometimes it's also a manual process, particularly I think for contacts, it can take quite some time. And then lastly, you should really make use of validation rules and field dependencies. So if you want an opportunity, for example, to move to a new stage, then use field dependencies and validation rules to make sure that — just to stick with the example from before — the MEDDIC fields actually have been filled out. Otherwise, the rep cannot close the deal. These are things that just keep your CRM healthy. One word of warning though: be careful with making fields required. Required fields often lead to issues in automations. Sometimes it's better just to have a validation rule and not necessarily making a field required.

Philipp Stelzer: Okay. I think those are four sins now. Let's go to five. Not tracking the right KPIs. So I already mentioned sales conversion rates — that really, in my opinion, is one of the most important KPIs. Pipeline coverage is an extremely important KPI. It's very easy to track. It makes sense to track it. If you don't, it will be very hard for you to understand where your current pipeline actually stands by just looking at one single number. And then the other two I wanna mention here are activities. So emails, meetings, calls, tasks. It's always mind-blowing to me how many companies are not tracking their emails, meetings, and calls. That's a really, really big cardinal sin in my opinion — maybe the biggest of them all — because activities are what moves a deal forward. If you don't have activities, the deal is not moving forward. So invest into infrastructure that makes it easy to track emails and meetings. That's a huge part of what Weflow does and is really the foundation. So this is how we start most of our conversations with customers — we look at their activity tracking, and for good reason, right? Because we know that if their activity tracking is on point, then their forecasting will also be on point. So this is really important. Don't underestimate this. And then lastly, I want to mention field history. So use field history for the amount, date, the close date, next steps. You can, I think, activate field history for up to fifty fields per object in Salesforce — maybe it's a bit less, could be just forty, but I think it's somewhere in that range. And something similar should also work for HubSpot. So definitely invest into that. It just takes you five minutes to activate, and you will have historic data for all of your most important fields. That is not to underestimate, and you should do it from day one.

Philipp Stelzer: Okay. Now getting to, I think, six. Using the free version of Einstein Activity Capture. So I mentioned activity tracking before, right? So keeping track of emails that are being logged and synced to your CRM. So actually in the enterprise license of Salesforce — and this is a Salesforce-specific one, of course, so sorry about that to all you HubSpot users, but it's an important one so I wanted to include it — in the enterprise license of Salesforce, you get free Einstein Activity Capture. And I think the question is, should you use it? And the short answer, in my opinion, is no, you shouldn't. And I want to give you some objective reasons. So obviously, you know, we also have activity capturing, but that's not really the point I'm trying to make. I think what's important to understand is Salesforce does not store tracked emails from Einstein Activity Capture in your Salesforce CRM. It's stored in an Amazon S3, AWS S3 bucket and is then mirrored via a Lightning component into your CRM. So that means Salesforce is in full control of how they allow you to interact with that activity data. It's not your data — it's Salesforce's data, essentially, at that point. And that's a big issue because you will run into limitations when it comes to reporting. You will not be able to, for example, log attachments like critical contracts, images, screenshots — a bunch of different things that are getting shared via email — all of these things you miss out on. And if you ever wanna stop using Einstein Activity Capture because maybe you wanna switch to a better, more integrated, solid solution, then, yeah, you lose out on all that historic data. You don't have that. There is nothing to report on, and that creates issues. So, you know, we're now moving into a world where large language models can be used for a lot of good things. And, for example, looking at your previous email records and the sentiment that's going on — that's very valuable. Do you wanna just give that to Salesforce? No. You don't. You wanna own that, and you wanna do something with it. So don't use the free version of Einstein Activity Capture. Look for better solutions. There's a lot of them out there. I'm not gonna say names — Weflow is obviously one of them, but there are alternatives. So, you know, spend some time doing some research. It's going to be worth your while. And maybe not immediately, but in a few years from now, people will thank you for making that decision.

Philipp Stelzer: Okay. Last one is no clear plan for how to use the lead object. So, again, maybe a bit more of a Salesforce-specific one because HubSpot just uses contacts for this. But in the case of Salesforce, I think it's totally fine to use the lead object if you are in a high-velocity environment. You work with solopreneurs, you work with SMBs, you work with one-time customers, right? Leads are great. Why not? Use leads to keep the rest of your CRM uncluttered. And in my opinion, that's kind of like the point of leads, right? They are designed in a way that they don't clutter the rest of your CRM. But that's also the bad part about it, because yes, you can turn a lead object into an account, contact, or opportunity — all of them at once — but you cannot associate a lead record with an account record. So there isn't really any historic data that you can capture into a lead object. So if you work in mid-market enterprise where you need historic data, a record of past communication with the people that you talk to, don't use leads — use contacts. That's a very straightforward decision to make right at the beginning of when you start using your CRM. So don't use leads if you do, for example, account-based marketing or account-based sales, your mid-market enterprise, where there's just a few people that you constantly talk to in an organization. So yeah, use contacts. It's just a better decision, and I think there's a lot of opinions out there that will back me up on this.

Philipp Stelzer: Alright. Yeah. Those are the seven deadly sins. Just a quick recap. Don't use external developers without having someone in house to manage and document these changes. Secondly, don't do over-customization. Third, stick to just a few fields — don't use too many custom fields. Fourth, have a good data governance system in place. Make sure you have time and resources to keep your data healthy and clean. Otherwise, using a CRM makes really no sense — that's a key part of using a CRM. Then fifth, track the right KPIs. It's not that many, neither for sales nor customer success. Don't go crazy. Just focus on a few and do those right. That's tough enough, so invest time into doing that. Sixth, don't use the free version of Einstein Activity Capture. There's a lot of objective reasons not to — just type into Google "should I use Einstein Activity Capture?" and you will find so many forum entries on this topic, both on Salesforce Trailblazers but also Reddit and a lot of different places. And then seventh, have a clear plan for how to use the lead object if you wanna use the lead object. Otherwise, just use contacts. It's the better decision.

Philipp Stelzer: Now, yeah, there's one bonus one I wanna mention, and that is if you are an older organization and maybe you're doing a big merger — maybe two companies merge, maybe there's a big purchasing decision, so your company buying a younger company, a startup or so — then think about whether it really makes sense to merge the CRM accounts or whether it would be better to just start from scratch. So often when a big M&A happens, companies start to do these sometimes year-long processes to merge the various CRMs together. So they sort of like give up on the ones that they kind of like want to get rid of, and then they keep the other one, the biggest one, the oldest one — they keep that. So from talking to many, many unhappy RevOps people who went through that process, just consider building from scratch. If your company makes a huge change by merging with another company that will heavily impact how they are selling, what they are selling, where they are selling — new markets, new products, and so on — then chances are your old CRM might actually not be set up in the right way to do that. And that's not the fault of the CRM. This is just how software development works. If you start with a clean slate, you will be faster. You will be more flexible. You will be able to use new technologies quicker because there's no historic baggage. There's not that bunch of old code that nobody understands anymore and that you need to now hire expensive people to spend a lot of time just to get things right and QA it. That's not good. And anyway, all the historic data you have in there is probably not worth that much anymore because if your sales motion is anyway changing because of this M&A, then what are you gonna do with it? So rather than spending huge amounts of money and time on various migration projects that chances are will fail anyway, just start with a clean slate. Just build a fresh CRM. Get rid of the old ones. I think everybody will thank you for it.

Philipp Stelzer: Okay. Maybe the last one is a hot take. I'm curious about your opinions. That's it from me. Thank you very much. I hope you enjoyed this solo episode. I know it's been sort of like a different take than what we typically do, but anyway, I hope it was useful and insightful to you. Thank you very much, and I wish you all a great rest of the day. Bye.