How We Reversed a Failed Salesforce Implementation

Share this article...

I’m an “accidental Salesforce admin.” I fell into my role by chance at the same time our company was looking to transition away from the system.

After struggling to gain user adoption and spending hundreds of thousands of dollars on a failed implementation, the leadership team were hoping to solve the problem by eliminating Salesforce entirely and building an internal system from scratch.

That solution didn’t make sense to me. Even though I was new to Salesforce, I stared at the Salesforce tower under construction in the heart of San Francisco every day from our office windows…so my gut told me that a homegrown CRM couldn’t possibly compete.

After attending the presentation where two members of our technology leadership team proposed their idea of replacing Salesforce with our own in-house CRM, I went to our senior leadership team and asked them to give me a few weeks to prove to them that replacing Salesforce was the wrong decision. And, just like that, I was off to the races!

Here’s what I learned on my journey to ‘save’ Salesforce, and hopefully you can do the same if you ever need to turn a failed implementation back around!

1. New to Salesforce? Take a Salesforce Admin Crash Course

Salesforce was a new world to me and a challenge I found exciting. I spent the next few weeks spending every free minute and staying late at night to learn everything I could about the platform from an admin’s perspective.

Here are some of the resources I leveraged to accelerate my learning:

  • Read blogs: My go-to recommendations are Salesforce Ben and Admin Hero. Both are rich in content, easily searchable by topic and helpful.
  • Watched Youtube videos: Similar to Google, a quick search will lead to many short and sweet video tutorials. For visual learners, this is especially helpful (and more entertaining than reading technical documentation).
  • Trolled the Salesforce Trailblazer Community and Stack Exchange for help: Most of the answers I needed were provided by the legend Steve Mo – who yes, I still owe a beer to.
  • Google: My new best friend. 99% of the time, someone else had already run into the issue I was struggling with and my exact question was in the top search results. Tada!
  • Trailhead: With hundreds of trails to be hiked, and badges to be earned, chances are high that what you need to learn already has a trail to step you through not only learning it but doing it in your developer org first so you don’t mess up anything in production! I would still recommend testing any change in your company’s Sandbox first. Actually I would INSIST on that!
  • Read Salesforce documentation: And when all else fails, go to the official Salesforce documentation to find what you are looking for. Salesforce documentation is specifically helpful to learn the more technical side of field creation and any exceptions to be aware of.

2. Take an Inventory of your Existing Data Model

Luckily, I had joined the company early on and transitioned roles across several departments from Sales to Product and Operations.  Therefore, I had a pretty good understanding of our business model and how data flowed from one end of the business to the other.

On the other hand, I had no idea whether our existing Salesforce data model reflected that. I needed to run an audit of our existing implementation, specifically around our objects and fields to get a better idea of what I was dealing with.

To do so properly, the first step I took was to communicate to everyone that Salesforce “development” was being placed on hold temporarily to allow me to do a proper audit without things changing every day. While some were frustrated, the short-term inconvenience was ultimately well-worth the longer-term benefits they derived from it.

My biggest realization was that unfortunately, taking this inventory isn’t an easy task using basic Salesforce setup functionality.  Have you seen the UI of the cobweb also known as schema builder? (I love you, Salesforce…but some work is needed there).

Luckily though, many tools exist to help. I quickly learned that the saying “patience is a virtue” should not be taken lightly. This process took a lot of time and tools – which was a big part of the inspiration behind Spekit – our dynamic documentation and training solution.

At the time, my only option was to do an excel export of all of our fields and objects metadata. To do so, I used Field Dumper to export each object to a different tab in a spreadsheet. We had numerous installed packages and custom objects so that spreadsheet quickly was nicknamed “The Beast” due to the volume of tabs, rows and columns of metadata.

The next thing I did was use Field Trip to get data around the usage of our fields. The tool is pretty neat and allowed me to quickly identify dozens of fields that weren’t being used and could potentially be deleted. Using a little bit of excel manipulation (vlookup and match formulas were my go-to’s), I added this field usage information as additional columns in The Beast.

In a similar way, I then used a combination of Eclipse and the Schema Lister to identify where, if any, fields were used in the system including email templates, workflow rules and layouts and added that information to The Beast as well.

Next, using profile-level information and my knowledge of the business, I went through and added my hypothetical guesses around what “teams” used each object or field just to use as a starting point in my team conversations.

With what I felt was as good of a picture as I could get from our Salesforce metadata about our Salesforce implementation, I was ready to talk to my next biggest resource: our human capital.

3. Identify Internal Champions

To many, the natural next step would be to speak with every team manager in the company to understand their current processes and pain points. While I knew that would be helpful, I knew that the richest information I’d obtain would be from the actual team members on the floor that used Salesforce (or spreadsheets instead) all day long.

I spoke with every manager and asked them to identify key team members and give me feedback. I booked two hours with each team member, which may seem like overkill but in many cases barely scratched the surface – and yes, for some it did feel like a therapy session. To prepare, I created a general set of questions for consistency and added some team-specific ones as well.

A big thing to note here is that while I was looking to understand their current use of Salesforce, I was also hoping to identify other parts of their day-to-day work that could benefit from the use of the platform. Therefore, I asked them to walk me through a typical day and show me the various tools they were using to do their job. Wow was I impressed with the creative ways that they used spreadsheets.

While I took copious notes, I also had The Beast open at all times to guide me. This allowed me to verify, and make any adjustments necessary to my existing discovery data. In retrospect, I’d recommend recording the discovery session using Zoom or a different screen capture tool to be able to reference and rewatch the workflows as needed.

Lastly, I made sure to ask them a special question: if I could only deliver on ONE thing for them in Salesforce, what would that be?  Many of their answers were pretty simple and some were even already possible – clearly demonstrating the training gap that existed. Yet this last step was really important and here’s why:

This new Salesforce implementation was going to be a challenge and require buy-in from end-users across the board to truly be successful. My hope was that delivering on some of these small wins early on would demonstrate to these key end-users that my objective was truly to make their lives easier not harder…which in return would help me gain their “champion” support – and it did.

With that information in mind, I then set-up time with the team managers to walk them through my understanding of the gaps and high-level plan to also incorporate their feedback before heading to the whiteboards. I also talked to our head of product and our in-house development team to learn more about the internal tools they had on their roadmap to help with team productivity to avoid duplicating efforts in Salesforce.

4. Start Small, but Think Big

With The Beast and my pages of notes “complete,” I was ready for the fun part: designing the solution.

During my short stint as a Product Manager, I had experienced first-hand the danger of “over-speccing” and running into a deep hole with requirements versus starting out with a Minimum Viable Product (MVP) and iterating on it. If you’re not familiar with this method, here’s a picture that demonstrates what proper MVP development process looks like (adding value iteratively vs building up towards a big release).

I knew that to do it right I needed to architect the solution in a scalable manner with our new data model in mind to avoid technical debt down the road.

To help me break down the solution and visualize our data model, I drew out our entire business model including key business processes (diamonds), key data inputs/outputs (rectangles), existing automation tools (blue arrows) and planned tools (green arrows). This business model was not meant to be a data model schema of our objects, but a high-level representation of how data flowed from one end of the business to the next to help me think through our data model.

With this in mind, I then started designing our “ideal” Salesforce data model. Note that I consulted our non-Salesforce technical architect as needed to make sure I was on the right track, given that I had no formal training in system architecture.

Once I felt like I had a pretty good solution in mind, I showed it to a few team managers and our recently hired Salesforce developer. After receiving their blessing, I used out-of-the-box Salesforce functionality and other hacks including a free app for lead assignment and URL hacks, combined with lots of data cleanup (which deserves a post of its own) to build out our V1 of our Salesforce revamp. This one was  I was ready to release V1 of our Salesforce revamp for our BizDev team, just three weeks after starting this process and right as we were about to hire a full-time Salesforce architect contractor

5. Clean Up your Data

We’ve all heard the saying “Garbage in, garbage out” when it comes to data. Reporting and analytics are only as good as the data itself, so it’s critical to clean up your data before publishing any reports. It’s important to understand what bad data is before you start to clean it up. Bad data includes many things.

According to Q. Ethan McCallum, from the Bad Data Handbook, “Some people consider it a purely hand-on, technical phenomenon: missing values, malformed records and cranky file formats.” McCallum continues to state that bad data “includes data that eats up your time, causes you to stay late at the office, drive you to tear out your hair in frustration.

It’s data that you can’t access, data that you had and then lost, data that’s not the same as it was yesterday…” In short, bad data is any data that slows progress, causes misguided decision-making, and much more.

Bad data costs organizations real money. According to Gartner, poor data quality costs organizations an average of $15 million annually. And the impact of bad data goes well beyond the purely financial impact. It weakens their competitive advantage and plants the seeds of distrust amongst their customers.  So what is bad data, and how can you clean it?

  • Duplicate Data: This is the most common type of bad data. Search any company’s CRM for the contact John Smith and most likely you’ll find dozens. Some good, and some duplicates. It takes effort to determine which ones are the good ones, and which need to be cleansed, combined, or removed altogether. Search the Salesforce AppExchange for “duplicates” and you’ll find dozens of options to evaluate to help you tackle your duplicate data issue.
  • Outdated Data: People change jobs and companies frequently. Chances are very good that someone listed as a contact for a specific organization in your CRM’s data either has a new job title or works for a completely different organization than they did when the data was put into your CRM.
  • Incomplete Records (missing data): Sales representatives get better results when they talk to prospects but if your data is missing a telephone number, real conversations can’t happen.

6. Rolling out and driving adoption

Lastly, the fun part. I’d invested a lot of time and energy into turning this implementation around but the hardest part was in front of me: I needed to convince my colleagues to start using it. I was determined to not let all of those long nights of building workflow rules and process builders go to waste.

Getting your users to actually log in and use the system every day is known as  “adoption.” It’s not an easy task, but it’s doable. This study breaks down the three factors that most highly influence rate of adoption: 

  • Perceived Usefulness: How is this going to benefit me? Help me do my job better? Help me make more money, get that promotion? WHY should I log in? They note that this is significantly influenced by an individual’s past experience so it was important for me to recognize that, given the lack of success we’d had with Salesforce previously, this was going to be a big objection for me to overcome.
  • Managerial Support: Do I feel supported using the system by my managers, by our support and training? Is it EASY for me to use the platform?
  • Peer influence: If my colleague Joe is using it and it’s helping him, maybe I should give it a try. This is why having a group of “power users” or “champions” is so important to adoption. So that it’s not just IT or the Salesforce team pushing adoption, but instead you have an army of folks on the floor helping drive adoption by osmosis every day.

Here’s how I approached it:

  1. Timing: We were approaching the end of the quarter so I knew that adding that additional stress to our teams wouldn’t be the best way to kick it off. They were focused on one thing, hitting their quota, and adding any change would add friction to getting them there and that would lead to resentment towards the platform. So I worked with the team managers to set a “launch” date right as the new quarter was starting.
    1. Pro-tip: Timing is big when it comes to change. Avoid Monday mornings because no one likes to come in first thing after a relaxing weekend and log into their org and immediately face friction because something has changed.
  2. Communication: Luckily I had consulted a number of my colleagues on the floor to help me design it but many weren’t aware that this was happening and I certainly didn’t want to catch them by surprise.
    1. Management Support:  I spoke to all of the team leads and asked them to start talking about it in their standups with their teams so that they knew to anticipate it. I also made sure our CEO brought it up at our quarter-end all-hands.
    2. The Message: Going back to the perceived usefulness part of the article, before people care about the WHAT and HOW, they need to be bought into the WHY. Therefore, I coached our leaders to focus on talking about why this time things were going to be different. Why Salesforce was going to help them be more efficient, manage their pipeline more effectively and eventually close more deals. I also made sure to reinforce this same message in all of our email communications and more.

7. Documentation and training

Once I had people excited for this project and bought into the why, it was time to train them properly on all of the new changes I’d made. This was a labor-intensive task but absolutely crucial to ensure people would not only use Salesforce but understand why they were using it the way that they were. 

  • I created dozens of “how-to” videos using CloudApp that I linked to field definitions and processes in a spreadsheet. 
  • I held a “kick-off” training session where I started again with the WHY (I always do with any new process we roll out) and then demo’s how do to the process – I split off the kick-off sessions by team so that it was really focused on their lens (using their terminology so that it felt familiar).
  • I set up regular office hours, training and check-ins with individual teams and champions to review any changes and ensure any questions were answered
  • I made myself available around the clock to answer any Salesforce support questions – which yes, was very distracting as I was constantly context-switching and my backlog was growing by the minute as people got excited about Salesforce and started asking for new things

The problem? While this worked while kicking things off, anyone who’s managed Salesforce before knows this simply becomes impossible to manage as a small Salesforce/Enablement team. We were making changes to Salesforce on a daily or weekly basis. Which meant constantly updating documentation, more support tickets from confused employees, more training sessions to host for small, frequent changes like adding a new picklist value or a new field.

I knew there had to be a better way. 

These challenges were the inspiration for building my company, Spekit. We thought, what if there was an automated way to document these fields, objects and picklist values and other processes from Salesforce in a centralized place that would scale as we made updates to our org? What if we could notify users when changes were made and automatically update the training they see?

And, what if that training automagically showed up in Salesforce, directly beside those defined terms and processes so that users never had to leave their workflows to find an answer.

That world wouldn’t have field dumpers and spreadsheets. It wouldn’t need regular training sessions for small process updates and new field definitions. It wouldn’t have 20 Salesforce support questions a day.

So, we built it and also pre-populated Spekit with all of the out-of-the-box “How do I” FAQ questions and processes that end-users face in Salesforce Lightning for you, so that you can focus on documenting the key questions that are key to your org!

No matter where your team lives (yup, we work outside of Salesforce too), this simple, automated training follows them to provide guidance and in-app learning anywhere they work – including being able to search for knowledge and training in Slack!

It’s the easy, automated solution to what can be an incredibly complex and time-consuming set of problems. 

What more could your team accomplish with an extra 1.8 hours in your day?

One thought on “How We Reversed a Failed Salesforce Implementation

  1. Avatar

    Fantastic post!! I’m struggling in a new position with an Org that needs serious help. You provided me with some great tips that I know will be very helpful!

Leave a Reply