Write down ALL of your Salesforce Processes

I know I sound like a crazy person, but you need to write out ALL of your Salesforce processes. By write out, a simple list containing the names of the processes your users do in Salesforce will work.

You’ll probably have stuff like: Log Calls, Send Contracts, etc.

Is your list really long? Probably. 

Is it going to be easy to finish everything? Probably not. 

Should you finish everything before going live? No.

The value of doing this exercise comes in two parts:

1. Now you know exactly what you have to accomplish to fully migrate to Lightning
2. You will know exactly which processes are still done in Classic. This means anytime someone has a question about if a feature is in Lightning or Classic, they can go to this document and find out.

Having buy-in from business users and management is key to a successful rollout. I recommend selecting people who are already good with Salesforce and excited about new features.

Your champions will also be key in providing you feedback as you build things out. You’ll want to show them what you’ve built and iterate on it until it’s just right.

Pull something from your list of Salesforce processes. It doesn’t matter where you start, but make sure it’s something simple. The most important thing is that you’re able to get your hands dirty.

The goal here isn’t to make it perfect. Start building this right in production and spend no more than ~3 hours on each item. If it’s taking longer than that, see if you can break the process up into smaller parts. Update your list of Salesforce processes if you end up breaking things up.

Once you have something ready to show, schedule a demo. Be ready for a lot of questions during the first few of these. People can go a little cross eyed when they first see Lightning. 

After the demo, analyze the feedback you received. You should try and understand if what you’ve built will work for those who saw it. While it doesn’t need to be perfect, it needs to provide a good user experience. Continue making tweaks and doing demos until you receive positive feedback.

Remember that long list of Salesforce processes we made at the beginning? Time to cross something off the list right!? Wrong.

Instead you should add documentation for the process. I’d recommend adding the following for every process you complete:

• Summary
• Step-by-step directions
• Screenshot or video

If the process is complex, I’d also add a FAQ and information on where to log bugs or ask additional questions about the process.

The goal of your documentation is to make it as self-service as possible. When launch day comes, everyone should have everything they need by going to this document.

I recommend organizing your documentation by team, with a section for shared processes. This will enable someone to come to the doc, find their team, find the process they had a question about and resolve their question by themselves.

I recommend going live when you have all major processes for one team migrated to Lightning. Don’t move a team to Lightning if they will constantly be switching back and forth. Some switching is okay, but too much and people will get discouraged.

The biggest takeaways you will see from getting your first team into Lightning are:

1. The quality of your documentation
2. Making an ally or an enemy

You’ll know pretty quickly how good your documentation is. When you launch, you’re bound to get a lot of questions. You should direct them to the documentation every time. Don’t waste your time answering the same question over and over. If you don’t have it documented, add it to the docs in a way that everyone can find the answer.

You will make many allies if people are starting to use Lightning and having a great experience with their new processes. This positive momentum is crucial for Lightning to roll out in other teams.

If the new processes are painful, you will need to listen to where the pain is coming from and address it ASAP. Iterating on painful processes needs to be your first priority after going live. If there is too much pain for too long, you will make enemies. People will switch back to Classic and it will be more difficult to get this team to adopt Lightning.

Once you have built (or re-built) everything needed for a team to go live, you have completed goals 2, 3 and 4 for that team. You should move on to goal #5 for this team, but continue on goals 2, 3 and 4 for other teams.

Goal #2 Configure Lightning Experience ✅

Goal #3 Document all Salesforce processes ✅

Goal #4 Create training and support materials  ✅

Monitoring the usage of Lightning is key to a successful implementation. I recommend using the Lightning Usage app to monitor adoption. This app comes with all Salesforce orgs and is accessible via the App Launcher. If you don’t see it, check your profile settings.

My favorite features of this app are:

• Daily active user stats
• Information on when people switch to classic and where they switch from
• Load times of most commonly viewed pages

By monitoring these dashboards, you can work to understand what is preventing people from adopting Lightning. I recommend to document the concerns and your responses to them so you can share this with other teams. 

Goal #5 Lightning Experience is adopted ✅

That wasn’t too bad, huh? 

Well, I guess it does seem like a lot. 

And, will probably take a while. 

But you got this! Follow this plan and your implementation will be successful!

Remember, start by learning Lightning. Don’t dive in before doing your homework.

Once you have a good grasp of it, write out all of your Salesforce processes and group them by team and then into a section of shared processes.

Build, demo and iterate on each one until you have created a good user experience.

Add documentation for each process so that anyone who is confused can get clarity on what the new process is. This will be key so that you’re not overwhelmed by a ton of questions on launch day.

Go live when you have built and documented all processes needed by a single team. During go live, focus your energy on any processes that are now painful for that team.

After going live, use the Lightning Usage app to monitor adoption.

Good luck!