You’ll Regret Overcomplicating Your Salesforce Build — Here’s Why

When it comes to powering your business, Salesforce can do it all — but that doesn’t mean you should tackle

3 min. read

When it comes to powering your business, Salesforce can do it all — but that doesn’t mean you should tackle a company-wide implementation all at once. Overcomplicating your build can cause unnecessary stress and impede your company’s path to the results the platform is designed to bring.

Here are 4 reasons you should keep things simple — at least at first.

{{cta('08493866-0a0d-44f0-8fff-708c09d499a2')}}

4 Reasons Not to Overcomplicate Your Salesforce Build:

#1: It’s easier to drive a Corolla than fly a spaceship.

While it’s true that Salesforce is designed to drive company-wide business results, it’s important to remember that one of the key ways it does so is by making the lives of your employees easier and more efficient. As we’ve mentioned before, Salesforce is in large part a productivity tool. If it doesn’t lead individual users to success, it won’t lead your organization to success, either.

And as much as Will Smith and Jeff Goldblum made it look otherwise in Independence Day, flying a spaceship isn’t easy. If you give your users too much to work with and remember all at once, you might end up making their lives more difficult than they already were. And if that’s the case, they’ll be more likely to give up on the platform all together. Which leads me to my next point…

#2: Overcomplication makes failure harder to overcome.

When you go live with an overcomplicated Salesforce build, one that will be used by multiple teams and that features complex functionalities, you’re boxing yourself into a success/failure binary. Things will either work out how you want them to — meaning full-scale adoption — or they won’t, and you’ll have spent lots of time and money on a system that nobody wants to use. Not good.

It’s much better to roll out a pilot build to a smaller team, with the express goal of gathering feedback and iterating until users are happy. That way, success is something you build toward, not something you cross your fingers for.

#3: Taking it one team at a time isn’t so overwhelming.

You can think of a business as a machine, with each team being a different part. Unlike a machine, however, you can’t turn off a business to make repairs or upgrades. Whatever changes you’re trying to make must happen while the engine is still running, so to speak.

That’s why we recommend implementing Salesforce to one team at a time — because a CRM deployment is highly contextual. When you’re updating the processes and technologies that power a particular aspect of your business, you’re also updating how it fits in with other parts of the company. For example, if you rework your sales process using Salesforce, a big part of the implementation will involve charting how leads flow in from the marketing team. This would be a lot more complicated if you were also updating your marketing process at the same time.

Again, the engine is still running. Don’t try to replace too many parts at once.

#4: You won’t need to invest as much to see real results.

You probably already had this one in the back of your mind, but the last reason not to overcomplicate your build has to do with cost. With Salesforce, you pay the license fees up front. So if you decide to go all in on a complex and comprehensive implementation, you’ll be paying a lot — and then waiting a long time for results. For some this might be okay, but most leaders would likely start to get more than a bit anxious during that time.

If you start smaller, on the other hand, you’ll likely be able to see a return on your investment much sooner.

With all of these points, of course, it’s important to remember that you can always add additional functionalities down the line, once your team has a solid grasp of your current system. I’m not advocating that you place artificial limits on how your company will use Salesforce — I’m just saying it makes sense not to dive too deep your first time in the pool.

Avatar

AUTHOR

Danielle Sutton