Getting your SaaS unstuck: The 3 stages of Salesforce frustration

Getting your SaaS unstuck: The 3 stages of Salesforce frustration

Tags
Business SystemsSalesforce
Published
October 30, 2023
Related Tools

Salesforce is a tremendously powerful platform that creates a lot of value for a lot of organizations. However, it’s also true that many companies end up struggling with Salesforce in various ways.

And once your org gets stuck in a tough place with your Salesforce implementation, it can be surprisingly challenging to figure out how to fix things. At Quorum1 we help a lot of orgs clear piles of technical debt and implement sustainable change management practices, so this is something we deal with constantly.

The great news is that most Salesforce struggles can be resolved with a little persistence and a solid plan. In our work we’ve come across three common stages to organizational Salesforce frustration, and we think that understanding these stages can make it way easier to get unstuck. Let’s dig in!

Stage 1: Underutilized

image

At this stage, you’ve gotten your Salesforce org up and running, but adoption is low. Very few of your critical business processes are handled in Salesforce, so most of your staff simply ignores it. There are no practical plans to try and increase utilization and the automation potential of the platform is mostly unrealized. Any complaints about Salesforce are likely around it costing too much money and not delivering enough value to justify the expense.

The Plan:

  1. Dream up the Automation of a Single Critical Process: Unless users are compelled to use a new system, they won’t. You must have something in Salesforce that they need in order to do their job. Ideally you should pick something where shared visibility and team collaboration around a particular workflow is a significant value add.
  2. Make the Case with Metrics: Choose something quantifiable like customer service response time or order processing time and show how your proposed automation will improve it. Bonus points if it is attached to a dollar amount.
  3. Execute: Make your changes and make sure your users know about them. Treat your users as a partner and be transparent. User trust is critical to your success.
  4. Repeat: Build on your successful first project by doing another one! Your users have a taste for automation. You and your team are the ones that can deliver it.

Stage 2: Running Hot

image

At this stage, you have critical business processes running in Salesforce and a strong base of active users logging in every day. A love/hate relationship has established itself. The platform has become a critical part of the business, but when problems crop up they cause big headaches.

The customizations and automations to your Salesforce Org have been done either by a small in-house team, or through a Salesforce consulting partner, or a combination of both. Some business processes are wonky, have manual work-arounds or are completely broken.

The time it takes your team or consulting partner to make a requested change seems to be growing longer and longer. It feels like every time a change is made there is a stabilization period afterwards where your admins and/or developers have to work through the problems.

The Plan:

The most effective thing you can do in this case is to design and implement a robust Salesforce change management process. However, getting to that end state can be a daunting amount of work. So here are some smaller steps that will begin to move things in the right direction.

  1. Use Sandboxes for Everything: Stop making configuration and automation changes directly in the Salesforce Production Org. Removing direct development access in Production gives you the space to create a repeatable process for reviewing and testing changes before they reach your users.
  2. Define a Test Process: Create and document the official process for testing changes before they are applied to the Production Salesforce Org. Identify critical business functions that must be tested in a Sandbox Org prior to those changes going into the Production Org. Record who did the testing and what they tested. Create accountability.
  3. Define a Production Deployment Process: This can be as simple as using standard Change Sets, or it can involve more advanced source-control-driven tooling. The key here is to have only one possible way to get changes into production. Without these enforced deployment steps, your testing and review processes are bypassed.

These practices seem simple, but it will take a lot of discipline to implement these things if your team is not accustomed to working this way. If you have the conviction, you will see a reduction in the number of mistakes that actually reach your users.

Bonus Next Steps

Once you have the above manual processes in place, you can really up your engineering game by using some industry standard tools.

  • Track your Salesforce Metadata Changes: Use a source control repository like Github. This will record who changed what and when. It is the fundamental first piece of any professional change management workflow.
  • Deploy to Production from Source Control: This will ensure that every change is actually tracked, and that your Source Control system is a reliable picture of what has been put into your Salesforce Production Org.
  • Automate Testing: You need to make a lot of changes to make your Salesforce Org maintainable. Don’t waste time with manual testing.

Stage 3: In the Weeds

image

At this stage, Salesforce is one of many business systems used in your org. The Salesforce team also collaborates with other engineering/IT teams. Those other teams had no say in the decision to use Salesforce and they don’t trust it. To them Salesforce isn’t a reliable engineering platform.

There are political struggles between the various teams about what business problems should be solved by which system. There is no cohesive vision for how Salesforce ought to be used. From time to time, some people propose abandoning Salesforce altogether or rebuilding large swaths of its functionality using other tools and platforms.

The Plan

The big goals here are to make sure that your Salesforce development team is on equal footing with the rest of the technical teams in your org (both technically and politically) and to build trust by streamlining cross-team workflows / integrations.

  1. Get your House in Order: Go back to Stage 2 and fix any problems there first. Your change management practices need to at least meet those of the other technical teams in your org. If your team has ground to make up, ask the other development teams for help. Including them in that process is a great way to build trust.
  2. Pick your Starting Point: Build a list of every critical integration flowing into and out of Salesforce. Include both technical integrations and non-technical “integrations” (cross-team workflows that cross the Salesforce boundary). Pick one to start with. You want to pick a problematic integration which also offers an opportunity to improve an important cross-team relationship.
  3. Get Alignment: Start by extending an invitation to the other team(s) to collaborate around the improvement of this cross-team workflow. Be extra humble and make sure to get their buy-in on approaching this collaboratively.
  4. Co-build a Better Solution: Now it’s time to execute and deliver! This is going to be hard and you may need to get some consulting help in place if you don’t have the right people on your team already. But there’s no shortcut to successfully delivering on improving a cross-team integration. You’ll need a strong mark in the win column in order to move forward.
  5. Solidify the Ongoing Collaboration: As your initial integration improvement project is wrapping up, open up the discussion around what “maintenance mode” looks like. Ideally you want to use this as an opportunity to create regular (perhaps monthly) check-ins and occasional (quarterly or bi-annual) roadmap co-planning sessions.
  6. Document, Socialize, Repeat: Summarize the process you went through during the initial integration improvement project. Turn this into a standard operating procedure and socialize it with other teams. Then go down your list and repeat it all over again with your next problematic integration.

To be sure, this path involves a lot of work. But the reality is that at this organizational stage, the path forward requires trust-building and coalition-building. And the only way to do that is through good organization, great execution, and consistent communication.

It’s also worth noting that, at this stage, it sometimes becomes obvious that the root cause of disfunction is an under-resourced team. If that’s your situation then the path forward is ultimately the same, but you’ll have one extra restriction and one extra goal. The extra restriction is that you’ll need to pick an initial project which is readily achievable at your current resourcing levels. The extra goal is that your initial project must clearly demonstrate to your management stakeholders that your team is knocking it out of the park and needs more budget to bring things to the next level.

We hope this framework helps you plan your approach and get your Salesforce org unstuck. Above all else, it’s important to stay positive and remember that many other orgs have succeeded on this path. There really are Salesforce orgs out there which are healthy and vibrant and have strong buy-in from their teams. Success is achievable! You can do this!

Looking for help?

At Quorum1, we love getting into the weeds and helping people find success with their Salesforce processes. If you want some help or even just a pep talk, please reach out. We can schedule a call to review your situation and help you come up with an action plan.

Click the link below to learn more.