Framework for Designing Salesforce Solutions for Enterprise Go-To-Market Teams

Stepping into a new org for the first time can almost be like embarking on a trip through the dark sea during storm season. This is especially true in an enterprise environment that has hundreds or thousands of users used by multiple stakeholder groups that all have their own tech stack integrated into Salesforce.

I’ve worked within multiple enterprise environments and there are several principles that I have developed based on the patterns that I’ve encountered throughout my career. These principles combine parts of agile development and change management to ensure a smooth and efficient rollout of your solution.

My objective is to make this journey for you less daunting so that your skillset can shine through – no matter how complex an org may be. Regardless of the problem you are trying to tackle, this is my four-step process which I use when designing and developing a solution for enterprise go-to-market teams.

Step 1: Identify What You’re Getting Yourself Into (aka. Discovery)

Before spending any amount of time doing configuration work, the first step is to understand what sort of existing processes are being used daily by the end-users. When you begin dealing with instances that have multiple stakeholder groups outside of sales and marketing, such as finance and customer support, trying to uncover every small process is a surefire way to not produce any meaningful impact (especially if your org has hundreds or even thousands of end-users).

Here’s how I begin my discovery and ensure I don’t spend too much time going down a never ending rabbit hole…

Data Discovery

Controversial opinion: the majority of what we do as ops professionals is for some sort of reporting requirement.

I can’t tell you how many times I’ve heard someone say, “we have a problem consistently tracking lead pain points” with a field named something like “Self Identified Problems” – along with five other variations of the same field.

In all of my experience, I don’t think I’ve ever come across a Salesforce instance where there was no technical debt. This is why the quickest way to find the source of truth when beginning your discovery process is to gain access into any current reports or dashboards the teams are using on a regular basis. The simple filters and columns on a report can tell you a lot of information in a very short amount of time.

Integration Discovery

For this piece, we are going to assume the objective of the CRM is to act as a single source of truth.

Once you have the data points that are most important to the organization, you now want to know how data is being passed between the systems. There are four things I do during this process:

1. List out all the tools used for day-to-day operations that are integrated into your CRM.
2. Identify what objects are being used by each tool. The easiest way to accomplish this is to search the name of the tool and add “Salesforce integration permissions required” at the end of your search query.
3. Map any key fields and how the data is passed between each system.
4. Audit any automations in these systems that are tied to these fields.

For this step, I like using a tool like Miro and reference Salesforce diagrams to map out the objects an integration is tied to and how those objects are tied together within Salesforce.

Personal preference: I always start with combining the Sales Cloud and tasks and events diagrams into a single diagram.

Process Discovery

This is arguably the most difficult part to do, in my opinion – so sit back and take notes.

There are two key steps in how I conduct process discovery:

1. How things are supposed to be done.
2. How things are actually done.

There is almost always a discrepancy between the two.

To identify how things are supposed to be done, I like to sit through some sort of new employee onboarding process and take detailed notes outlining the steps to accomplish day-to-day tasks.

Learning how things are actually done is probably my favorite part of this whole process. The way I get the truth out of users is by prefacing that I don’t care if they don’t follow the ideal process – it’s more important for me to learn how they are currently doing their jobs. 

Tip: For future projects, I like to compare the ideal process with the actual process and find the middle ground between both to create an updated version that makes everyone happier.

Step 2: Begin Building a Minimum-Viable Product (MVP)

Now that you’ve uncovered the specific data points that are most important to the organization and how they’re being leveraged across systems, internal stakeholders, and business units, we can finally get to configuration.

Because the building of a minimum-viable product (MVP) can look wildly different for everyone, I won’t spend too much time talking about all of this. The objective with our MVP is relatively simple:

1. Test the viability of the solution.
2. Reduce the time to deployment.
3. Lay the foundation for future iterations.

There are a couple things that I do when building out an MVP…

Initial Configuration

When doing any configuration, I like to start with attempting to build it with as little human intervention required. This means mapping key actions in the systems to data created or updated and attempting to use that as part of your automated process. 

In the event that your process does require any manual process, the most important thing in my mind is ensuring that it is a positive user experience and that the result is more than just ‘updating a field for the sake of a report’. If the process requires someone to update a field/s, I want to make sure that there’s value for all parties involved.

Inclusive Testing

Once you’ve built your initial configuration, this is where I like to recruit my ‘end-user champion’. In my experience, the initial problem that we are addressing with our solution will come from a Senior Leader, so you will likely have some sort of executive buy-in and if you don’t, go back to the discovery process and show them the data to get the buy-in. 

I’ve often seen that ops professionals will run through their workflows to ensure that data is being processed as expected and there are no errors in a silo. Personally, I like to teach an end-user how to do some basic testing and get them involved in the process – often referred to as user-acceptance testing (UAT). Instead of just launching a new process and saying, “this is the new way going forward”, you’re inviting the people who use the system day-to-day into the development process which helps when you do finally launch your solution to the greater team.

Step 3: Create End-to-End Documentation

This is probably most people’s least favorite part of being involved in the ops world – but personally, it’s one of my favorite things to do! However, it didn’t start that way. 

If you don’t like creating documentation, here’s a couple selfish reasons why you should:

1. If you feel ‘misunderstood’ or ‘undervalued,’ documentation is an opportunity to show just how much work goes into creating a solution.
2. It’s a great piece of collateral to bring to any internal performance reviews with your manager.
3. It makes onboarding or training new ops team members a much easier process.

When writing my documentation, there are two audiences that I am writing for: non-technical and technical stakeholders. Every piece of documentation I create starts from the business objective and becomes increasingly more technical.

As an example, if I was writing documentation about a UTM parameter process, here’s how my documentation might be structured:

1. Purpose: Why should we care about UTM Parameters?
2. Objective: What’s the goal with this process?
3. Deliverables: What did we build?
4. General Information: What are UTM parameters?
5. Marketing Team Process: How is the greater marketing team going to be involved?
6. Technical Documentation: What fields, flows, integrations etc. did we build and how do they work?
7. Summary

Step 4: Launch to the Greater Team

This is where we truly get to test our soft skills which is what will take you to the next level in your career. 

To do the initial launch, I like to prepare a brief presentation and demo of the process. In the presentation, here’s how I will typically structure the content:

1. Purpose
2. General Information
3. High-level review of the Deliverables
4. Demo the Process
5. Set Expectations
6. Key Dates (such as when this process will become part of the standard process for the team)

Here are a couple tips that I’ve used in the past when presenting and launching a new process:

• When demoing the process, I like to let the person who I’ve worked with during the testing part, run this portion of the presentation.
• Be as prepared as you can for any objections. Especially if this new process requires the team to add an additional step in their current workflow, there will be some resistance. The best thing you can do is to frame how this new solution or process will benefit them in the long run.
• When something goes from Sandbox into Production – I will personally set the official go-live date 1-2 weeks ahead of that.

Summary

This process is something that has worked for me time and time again. Depending on the solution you are building, you can pick and choose the steps that make the most sense for your situation. 

If you enjoy this content, feel free to connect with me on LinkedIn or check out my website.