Ultimate Guide to a Salesforce Implementation in 2022

Salesforce is a powerful Customer Relationship Management (CRM) tool, enabling companies to connect with their clients through cloud-based software. Here, you can have a complete overview of your business performance in operations, finance, sales, marketing, and more.

Salesforce has various?products?that are specially designed to deliver each goal: Sales Cloud, Revenue Cloud, Service Cloud, Marketing Cloud and Pardot, and so much more. With the proper implementation of this CRM, you will increase sales efficiency, close more deals, and increase the accuracy of forecasts.

Let’s take a look at how to implement Salesforce correctly.

How do you implement Salesforce?

It is not enough to purchase the world’s best CRM license – that’s just the first step. The second, most important step is knowing how to adapt and customize it for your own business so you can get the most out of it.

For a complete implementation, you will need a project manager, a Salesforce consultant, and (maybe) Salesforce developers, but not all companies have the internal resources to do this – especially when they’re just getting started.

FHG was founded to address precisely this need. FHG?is a certified Salesforce Consultancy who can provide quality support to your business during this process.

Let us walk you through the various options of implementing Salesforce now.

Option 1: Implement yourself (not recommended)

No, no and no.?If you are entirely new to Salesforce we do not recommend doing this by yourself. While this option may seem tempting with the admin-friendly back-end interface that Salesforce offers out-of-the-box, you run the risk of implementing a solution that may work for today, but is not done in a scalable way. Then, when your business grows, you have to rebuild existing functionality, which can result in other components not working… you see where we’re going with this. This is known as?technical debt, and recovering or removing technical debt is a common request for “independent” implementers that finally seek out consultancies.

Here are 3 negative points of handling your Salesforce Implementation in-house:

• Slowed productivity: Depending on the skillset of the internal resources, handling a Salesforce implementation in-house will likely end up taking much longer than if an implementation partner were to do it. The research time alone on basic Salesforce components would take far too long without the guidance of a partner on where to look. The size of the team is also vital; letting a smaller team take care of the implementation could run up costs in the long term versus getting access to several Admins, Developers and Architects at a Salesforce Partner.
• Underestimating Projects: More often than not, the focus can diverge when setting out the roadmap in Salesforce Implementations. The team may be keen to make use of Salesforce’s latest developments and products, but can sometimes leave data migration or integration as an afterthought.?To hit a significant hurdle not correctly considered beforehand, can be costly nearing the end of the scheduled sprint. Integrations and data migrations often require an especially high level of experience, knowledge and practice.
• Lack of Experience: While the team may boast some Salesforce experience and have some Salesforce certifications to show, do they possess implementation experience in your market or industry?

Option 2: Use a partner – the most popular and recommended option

Leveraging the knowledge and experience of a partner addresses a lot of the pitfalls associated with self-implementation. By getting instant access to several years of implementation experience, not to mention the internal network within the partner itself, you gain the ability to move not just quickly, but efficiently.

4 Benefits of Engaging a Salesforce Implementation Partner:

• Agility: When you choose to go with a partner, you get access to an entire team ready to tackle your Salesforce implementation as early as possible. With split roles between project managers, declarative developers, and apex developers, experts in each of these domains can collaborate on and define the best solution; moving to actual implementation/development as quickly as possible.?
• Expertise: While every business has unique needs, you want the people who have “been there, done that”. Salesforce’s consultants, by virtue of their exposure to many industries and projects, will be able to automatically pinpoint the right solution to meet your needs – and explain why along the way. It is also their responsibility to stay on top of the latest and greatest that Salesforce releases, so you know you’re never missing out.
• Best Practices: Having a partner listen to your needs and implement them sounds great, but what if you’re “less-than-confident” in your existing processes? Or perhaps a bit curious to know how others before you, in the same or different industries, have managed similar issues? Being able to learn from other people’s successes (and mistakes!) is an invaluable tool to have at your disposal.
• Skill Transfer: Having a partner implement your Salesforce should never result in dependency on that partner. At FHG in particular, we prioritize documentation and system administrator training to make sure that our clients can manage and extend their system long after the project has been completed. Independence and control of their data are, ultimately, the services we provide our customers.

Salesforce Implementation Process

A Salesforce Implementation typically follows the following structure:

1. Define Stakeholders
2. Define High-level Goals
3. Gather Requirements
4. Prioritize Requirements
5. Build
6. Testing and Implementation of Feedback
7. Prepare for Go-Live (change management)
8. Go-Live

As you can see, most of the steps and hard work comes at the beginning, when defining the project scope.

Steps 1-4 are critical to making sure that your Salesforce implementation is in line with the business’ goals and addresses its immediate needs. They will also prove to be useful in the testing/feedback phase, where expectations and the system don’t always match up. By being as explicit as possible, you give yourself the best chance at success!

Steps 5-8, as defined here, are shown in what’s called the?waterfall methodology: everything built as a whole, then tested, then go live. This is more common for initial implementation. This allows you to see how everything works as a more final product when you get to the testing phase, but can also lead to expectations vs reality being further apart than with the second option.

That second option, the?agile methodology, is representative of iterative development. In essence, steps 5-8 (sometimes 3-8) take a more cyclical approach, where the larger project is broken down into smaller iterations known as sprints, each with its own Build, Testing, Change Management, and Go-Live phase. Agile is gaining traction as the preferred methodology for many customers as it allows flexibility in prioritizing developments and enhancements on different parts of the system in near-real-time!

?

1. Define Stakeholders

First things first: who is relevant to the project? You’ll want to identify the people and entities that have a vested interest in the project, and whose needs will need to be addressed as part of the implementation. You will also need to define some key roles and responsibilities for the project:

• Business/End Users: individuals and/or teams that will actively use the system. Of these, it is usually best practice to choose one person per group/team that represents their end users’ needs. Their primary role will be to identify what the requirements and issues are, and describe what success looks like. For example, you may need to include the Customer Service Manager as well as the Sales Manager, to get both perspectives and ensure no team’s needs are going unheard.
• Super Users: belonging to the Business/End User group, but not necessarily involved with the project at the beginning, these are eager users and willing to help out with the testing and final rollout of the implementation. They will be given special training (known as Super User training) so that they can support their colleagues as the organization adjusts to the new system.
• Project Manager: the individual responsible for the progress and outcomes of the project. This person’s domain is the project itself and is key for keeping the lines of communication clear regarding the progress or blockers of the project.
• Decision Maker: individual equipped with the authority to make decisions on the project – be it a timeline, budget, or even design decisions. This can be the same person/people responsible for the requirements, but not necessarily.

?

2. Define High-level Goals

Now that you’ve defined your stakeholders, you can engage them to determine what the goals of the project are.

Some sample questions include:

• What does success look like?
• What are some pain points that the team faces regularly?
• What parts of the day-to-day tasks feel inefficient?
• What features have they seen that they are particularly excited about?
• Which processes are currently going well that you would like to mimic in other processes or in the new system?

The goal of this phase is to really identify where the greatest impact can be made (by addressing the greatest pain points). This will help with prioritization later. This also helps set the project up for success by seeing how well the different stakeholders’ visions align. That vision should be more or less clear before moving forward.

?

3. Gather Requirements

Great! You’ve done so well so far, and you’ve got a team with an aligned vision (more or less) for what a successful Salesforce implementation looks like! Now the question is – what specific functions does the system need to provide to support that vision?

Before you dive into this activity, it’s important to learn about, and discuss with stakeholders, how a requirement is properly defined. There are?several?resources?available?online, some of which are complete?books?on the subject. The main ideas to take home after conducting your own research is:

• Requirements should be unambiguous, using precise language.
• Requirements should be short, excluding unnecessary information
• Requirements should be testable/verifiable, to be able to check them off the list at the end of the project.
• Requirements should use consistent terminology, with industry standards/naming conventions listed in a glossary
• Requirements shouldn’t include conjunctions like “and” / “or”, as these probably represent two separate requirements.

Requirements should be generated by everyone, but not necessarily with everyone in the room at the same time. It’s good practice to have people go off either individually or in teams and create a list of requirements. Then, requirements should be reviewed and vetted as a group to ensure they meet the standards set above.

?

4. Prioritize Requirements

Now that we’ve done the requirements gathering, it’s time to prioritize. You’ll rarely have enough resources or budget to accomplish everything within your expected time frame, and sometimes you need to manually limit how much you want to build within a certain phase to make the change management aspect more manageable.

Start by assigning a priority of either High/Medium/Low to your requirements and identify what is a “must-have”, a “should-have”, and a “nice-to-have”.

Must-haves are requirements that are non-negotiable一without these, you cannot go-live.

Should-haves are those requirements that would be of great benefit at go-live but can be worked around with some manual effort.

Finally, Nice-to-haves are those requirements that would be helpful, but serve more of a convenience than a core business function.

Once you’ve prioritized your requirements, you’ll want your technical team or Salesforce partner to start putting together an effort estimate on each requirement. You’ll also want to group the requirements into larger modules, for easier prioritization during the build phase. These are commonly referred to as Epics.

Estimating requirements is both a science and an art – it’s more important to call out what a given requirement isn’t asking for, by stating assumptions, than to specify how you will build the solution itself. Now, bear in mind that estimating requirements is one of the main tasks from your chosen Salesforce partner, and you should set this point on your expectations list. Afterwards, it’s up to you to prioritise based on what fits within the budget.

?

5. Build

At last – now the fun begins! It’s time to bring those requirements to life.

As an experienced partner, FHG affirms their team likes to begin identifying dependencies between requirements within Epics. For example, they build the Lead custom fields before they start tinkering with the Page Layout. This is what they maintain as a best practice.

We know that you might not be entirely involved in the building processes, as it is mainly the consultants’ and developers’ domain, but here are 3 topics to discuss with them:

1. Refreshing a sandbox org.
2. Documentation – what documentation will the partner provide?
3. Prepare for deployment from Day 1.

?

6. Testing and Implementation of Feedback

After some functionality has been built, or perhaps a proof of concept or draft solution has been implemented in the sandbox, it’s time to touch base with the business team and your implementation partner to make sure reality is meeting expectations. Some tips here would be:

• Request a visual demo.
• Record the demo.
• Take into consideration the underlying story: the entire flow and how all the components are connected to each other. Here is where you will actually see how Salesforce works and how it has been adapted/customized to your business.
• If the demo takes more than 1 hour, have a break to make sure you will retain the information.
• Take notes to track the conversation and ask your partner to send over a manual with instructions.

Once you’ve finished reviewing the functionality, you’re going to want to review the feedback captured together and jot down any additional points of feedback.

Compare the feedback to the initial scope defined in Prioritizing Requirements. If the feedback can be tied directly to an explicit requirement, it’s in scope and should be implemented as part of a shorter feedback-implementing build phase.

If it’s out of scope, a requirement addressing the feedback should be created and either moved to a future phase, or added to the current project.

If you add it to the current project, it is strongly recommended that the project timeline is re-evaluated depending on the effort required to meet the new requirement. Any requirements added at this stage inevitably introduce some level of risk, as they could impact other aspects of the system directly or indirectly.

After agreeing on which bits of feedback need to be addressed, have those (hopefully quick) fixes/enhancements made and review the adjusted functionality with your partner. You may choose to focus on the changes, rather than the whole process, in these 2nd or 3rd iterations.

?

7. Prepare for Go-Live

With the technical aspects signed off, it’s now time to take measures to ensure the transition process is a smooth and calculated one for all parties.

Well before sign-off, you’ll want to inform the affected end-users, especially of incoming changes with an expected date for transition. Be sure to send multiple reminders as the date approaches. Highlight which systems will be taken out of commission (sunset), and be clear about the plan moving forward for certain processes (i.e. Accounts Receivable will begin using Salesforce as of June 1st to handle delinquent payments).

Training is a critical aspect of technology enablement. Without it, users can get frustrated with a system even if it is designed with all the key requirements necessary. There are a few different trainings to consider for your rollout:

1. Admin Training: this is training that the development team should hand over documentation on the new feature or system to the person or team that will maintain it, or be the direct contact for users in case of any errors.
2. User Training: this training is geared towards all users, and is usually less hands-on due to the number of users that are going to be using the system. Training is delivered directly from the Business Analyst or Project Owner to the Users of the system in a lecture-style format
3. Train-the-Trainer: A popular “middle” ground option for companies is this method, where training is administered to so-called Super Users of the system. The recipients of these trainings will then go on to carry out training sessions of their own to their colleagues. You’ll want to include some hands-on components to this training where trainees accomplish some basic tasks in the new Salesforce system.

In each case, be sure to record your training for future reference.

?

8. Go-Live

This is it – the day you’ve been dreaming of since day 1! You’ll be deploying according to the pre-deployment, deployment, and post-deployment steps you’ve had outlined since the build phase.

Some key tips for a successful deployment:

• If possible, validate your package a few days, up to a week, before deployment. This allows you to catch any errors from missing components (or out-of-date items in sandbox that aren’t the case in Production).
• Check with your Implementation Partner that email deliverability in Setup has been turned off or set to System Email only from the beginning of deployment until you have completed all possible post-deployment checks.
• Consider your deployment window and the impact to users. If you’re turning off email deliverability, can they still use the system confidently? It is best practice to avoid users updating or creating records during deployment to prevent any unexpected behaviour.
• After completing your post-deployment steps, do a quick run-through of various key functionalities to ensure the system is working as expected.

Tips for a successful implementation

• Define requirements that are as clear, explicit, and unambiguous as possible: Salesforce implementations go wrong when reality doesn’t quite match up to expectations. Clear expectations avoid this.
• Get stakeholder buy-in early: The more stakeholders that believe in the solution you’re implementing, the more likely they are to contribute and offer constructive feedback for the betterment of the project.
• Establish clear time requirements from the business/end users: Often, there is a misconception that business stakeholders don’t have much to do with a technical implementation during certain phases. However, it is critical that they are involved throughout to provide input, feedback, and clarification at as many steps of the way as possible. The more time the implementation team spends siloed from the business and functional requirements, the further the solution will be from the initial vision.
• Test, test, test: Testing is one of the most important parts of any implementation. Nothing is more disappointing than seeing an error message pop up during a demo or a training session. Luckily, these are avoidable by spending the appropriate time testing the functionality according to the explicit and detailed requirements you defined at the beginning.

Is it time to invest in CRM?

Given the consequences that the coronavirus has brought to the global economy and how it has affected many businesses around the world, we firmly believe that it is the right time to make the change and protect your business today.

To us, understanding the value of Salesforce and the benefits it brings to your business is important for you to make the right decision regarding your customer platform.