Congratulations! You have embarked on an exciting journey to transform the way you do business. You have great expectations for improving your sales process, customer experience, and enterprise profitability. This guide about Salesforce Einstein implementation will help you to achieve your expectations for Einstein analytics.
Prior to starting the implementation, we recommend that you get your house in order through a series of steps:
- Understand Advanced Analytics, AI & Einstein
- Set Expectations for AI
- Define Clear Business Goals
- Prepare Salesforce Environment
- Do a Readiness Assessment
Get the detailed rundown of these steps at Guide 1 in this three-part series: I’m Learning or Seriously Considering Purchasing.
Here are the next steps for implementation. We’ll discuss each of these in more detail below:
- Create the core team
- Gather business and technical requirements
- Design the data architecture
- Identify data transformations and processes
- Define segmentation and personas
- Set up integrations
- Build, train and deploy models for each business outcome
- Create reports for insights vs. actions
- Establish ongoing maintenance program
Salesforce Einstein Implementation Core Team Members
C-level leaders that report to the CEO as part of their responsibility
Representation from the PMO office that oversees projects across the organization, much like an air traffic controller
Line of Business
The P&L owner of at least one line of business that will use the Einstein models and recommendations
Data & Insights
Your core BI team that is responsible for reports and analyses
The Salesforce administrator and at least one other person with deep knowledge of the data warehouse or source systems
The person who can review the models and recommendations for technical validation and ensure they are implemented correctly
Requirements are essential to define the scope of the project. These are provided by line of business owners and the executive team. They are a wish list for the ideal state.
Also the reporting, IT and analytics teams can provide requirements based on existing processes and deliverables. And they should also envision a re-imagined state that’s made possible by new analytic capabilities, data availability, and reporting options.
Involve all stakeholders, make this fun!
The requirements should address these major topics:
- Database Structure
- Data Access & Quality
- Visualization & Distribution
- Execution & Actionability
Now, prioritize! Once you pull together the requirements, put them into three buckets:
- Must have
- Nice to have
- Out of scope to explore later
Don’t miss this prioritization – it’s an important step to keep the project moving forward and avoid the dreaded scope creep.
The data model (also called data warehouse or data mart) is a framework of how the data structure is set up to support reporting, predictions, and the delivery of recommendations used in Einstein.
It needs to accommodate:
- Data from different original sources
- Transformations and storage of transformed data
- Different levels of granularity needed for the end uses described in requirements.
The architecture should also include how the data is migrated into/out of the warehouse with details of frequency, volume, and fields involved.
Data models can be built inside Salesforce. Or they can be built externally using data platforms like Heroku, or completely outside the Salesforce Platform with results fed into update Salesforce. Each of these has their pros and cons. So take time to arrive at the right solution for you.
Transformation is the modification of source data to add value for analytics. It is perhaps the most important aspect of this exercise, but it’s often overlooked. Some types of transformations are:
Each of these transformations requires well thought out processes. The processes should allow you to scale and support multiple use cases, for example across products, geographies or customer segments.
Transformation is the modification of source data to add value for analytics. It is perhaps the most important aspect of this exercise, but it’s often overlooked.
Following transformations, segments and personas give a handle on how analytics should be built and delivered.
This is also when the use cases must be paired with the segments so that you can create actionable “plays” for sales and marketing to drive outcomes.
After you collect, transform and segment the data, the next step is to connect everything in scope. Configure the key integrations between data warehouse to Salesforce, to Einstein, and to other clouds (i.e., Marketing Cloud, Service Cloud).
You can set up an intermediate staging area between warehouse and other integrations to handle transformations, cleansing and append. The refresh sessions must factor in the frequency, volume and granularity of data.
Here comes the fun part! It’s time (finally!) to deliver on the dream of “right customer, right time, right offer.”
Based on the requirements, you have created the data, transformations and segments. Using Einstein Discovery, you can build models for each of the scenarios such as cross-sell, retention and product penetration.
Then map out which user will get the output of each model, and weave this into their call scripts, customer interactions, and day to day operations.
For example, if a customer is deemed likely to attrition, initiate conversation about suggestions on how they can get more out of their existing relationship like taking advantage of subscription pricing, moving balances to higher interest deposit accounts, etc.
Without this mapping and clarity of process, the models and recommendations will not be used to their full potential. And worse, they can be interpreted incorrectly. The consequence is, your return on investment in Einstein may be delayed or not materialize.
This can be avoided by tying the Einstein recommendations to specific Salesforce users and their daily tasks.
Map out which user will get the output of each model, and weave this into their call scripts, customer interactions, and day to day operations.
A common mistake made with Salesforce Einstein implementation is with reporting. Often, users create one set of reports to try to serve many masters. But, there are in fact two distinct types of reports that should be generated by Einstein:
- Exploratory reports
- Action-oriented reports
The first kind of report is exploratory. It generates insights so leaders and decision-makers can better understand the customers, product and markets. These reports cover broad trends, and tend to be stable over time. They provide both leading and lagging indicators that drive the business.
The second kind of report is action-oriented. It is geared for the front lines or anyone directly involved in the customer experience – including the websites and mobile apps. These reports have to be time-sensitive and granular. They provide one action recommendation at a time, to be followed by another recommendation based on the customer response. Think of this like a survey with question path changes based on the previous response.
Providing both these types of reports will go a long way to making Einstein serve – and satisfy – many masters!
While still in the development phase, it is critical to also plan for future maintenance. Get commitment from the entire organization. This involves maintenance of each of the above steps, such as requirements, design, architecture, reporting, and feedback on the actions.
- Re-visit the requirements to see if any assumptions, business models, or market environment changed since starting the project
- Look at data sources that may have become obsolete or otherwise changed
- Review the data quality practices and identify areas of improvement
- Evaluate the segments and see if these are still valid; these are especially fast changing
- Conduct tests to determine if change in performance is statistically significant (like decrease in attrition, increase in average account balances)
- Calibrate or modify the models at least once a year; build the foundation and capability to deploy several models simultaneously (like touch frequency + next best offer)
There are a few options for who can implement Einstein. You can:
- Do it internally
- Use a Salesforce systems integrator
- Engage an Einstein specialist
Let’s look at the differences to help you decide which is a better fit for you.
A successful Salesforce Einstein implementation requires a team. Choose representatives (as many people as you need) from functional areas where you need:
- Initial requirements
- Sign-off on key stages
- Ownership to implement
- Report lessons learned to their areas
The important thing here: These teams and representatives should meet quarterly for the next one to two years to refine and improve initial deployment.
What are the risks? The team might not have the experience, bandwidth or chemistry to make all this happen.
The good news is even if you decide to seek an outside partner, this internal team will allow you to quickly absorb the integration, reduce friction to change, increase adoption and achieve ROI.
So, assemble this team whether you do the implementation internally, or hire external help.
Einstein is a Salesforce product and therefore it requires deep knowledge of the inner workings of your Salesforce Org. The objects, fields, data, relationships, workflows, triggers, license provisioning, permissions, and so on must be configured properly. There can be no lingering or outstanding issues of the core implementation itself.
Advantages of Systems Integrators
A traditional systems integrator (SI) brings such technical knowledge and experience. This skill set is objective in nature: it’s pretty much black and white as to steps that must be taken. An SI can install Einstein in your instance, provision the authoring and distribution license, map the fields, and set up reports so you’re “up and running.”
Choosing to work with an SI is ideal if they know your business really well and have deep industry knowledge. An SI can be a great asset if you are new to Salesforce and the infrastructure still needs to be sorted out.
Disadvantages of Systems Integrators
On the other hand, SIs often lack expertise in many aspects of data driven processes. Unlike the base implementation of Salesforce, which is a technical endeavor, implementing advanced analytics like Einstein requires full understanding of the data life cycle from creation, transformation and modeling, to execution. SIs may not have capabilities to solve your data issues, or recommend best practices based on experience in a multitude of industries, use cases, tools, platforms, and modeling environments.
It’s important to know the role that a systems integrator can, and likely cannot, play. Where the SI’s knowledge leaves off, you will need expertise in data, analytics, and your industry.
If you value a consultant who leads with strategy not technology, an Einstein analytics specialist can be the right fit.
Although a specialist like Valgen is a partner within the Salesforce consulting program, when it comes to Einstein they differ significantly from nearly all other SIs in three key aspects:
1. Roots in analytics
First, typically the core DNA of their practice is rooted in real-world advanced analytics with decades of experience. Einstein is a recent arrival. The practices of predictive analytics and AI for business intelligence have been around for a long time! If this analytics experience is important to you, a specialist may be a great fit.
2. Strategic Salesforce Einstein implementation
The second major difference is that analytics specialists see Einstein as a strategic, not a technical implementation. Strategy is the root of all the steps:
- From the ground up with discovery and design
- While documenting your current practices and future needs
- When capturing the desired vision/future state and designing how to bridge this gap
That’s why this implementation is equally subjective and objective, part science and part artistry. So if you value a consultant who leads with strategy not technology, an Einstein specialist can be the right fit.
On the flip side – specialists may lack the army of consultants and certifications, and the perceived comfort blanket that these bring. They also may not have hundreds of projects in online reviews, because they don’t take on migration, CPQ, custom development, and a plethora of projects that a general Salesforce consultant takes on.
But because Einstein specialists are focused on Salesforce analytics – and often just a handful of industries – they more than offset the size advantage. The strategic quality of the work offsets quantity of technical projects.
3. Data quality and advanced analytics
The third and perhaps most important differentiator is that specialists work with advanced analytics as an entire ecosystem. This includes data architecture, data quality, and data transformations that are key to getting the best predictions and reports.
In contrast to a general SI that tends to gloss over the poor data quality in your organization, the analytics specialist will pour over the details to identify flaws and weak points. They will recommend – and likely insist on – corrections. Because, they know that poor data quality can derail your ability to create accurate and reliable predictions. You would miss out on generating revenue and profits that are consistent and scalable. Clean data will prevent that outcome.
If you already deployed Einstein and you’re not happy with the results, see Guide 3 – the next Guide in this series to help you to be successful with your Salesforce Einstein implementation.
Contact us at:
* These fields are required.