Implementing Salesforce

Why is it valuable to thoughtfully structure your CRM?

To define and support business processes – your CRM helps you define your processes and support them. Your CRM should be where you enforce the business process. 

As a hub for all your data

• Sales data – data like what products are prospects looking at, and what amount is the prospect potentially willing to spend.
• Marketing data – data like what did they ultimately react to get them into our system, and what communication have they received since being in the system
• Service data – data like when was the last time you talked to them and what did you talk about? How would they rate you?

When do you need to make a bigger investment in optimizing your instance?

It has less to do with size, and more to do with complexity – you could be a ten-person company with super complex processes or products. It’s less about the make-up of your company or stage of your company, and more about the complexity of your data and how much manual time you’re spending. 

Invest when you have too many manual workarounds – you have to find the balance where you’re saving total time on repeated processes by investing in design and automation up front.

What can Salesforce do out-of-the-box (relatively easily), and what can it do if you invest more in configuration?

Salesforce can do anything, it’s just a question of configuration – the genius of Salesforce is that it’s essentially a big open box that you build on, and it supports a lot of standard configuration as well as basically any type of custom configuration.

Sales functionality is strong out of the box – especially for the sales process from getting leads into the system to completing a sale. That’s where Salesforce is best in class. 

Service ticketing functionality is standard – ticket creation is very easy, even though it’s manual. Through phones and connecters, Salesforce technology can create those tickets. You can also easily assign ownership and you can calculate SLAs with a small amount of configuration.

Marketing is the least advanced natively – you’re almost always going to need third-party integrations for marketing functionality.

Notes on licensing and contract types – technically the service license is different from the sales platform license, but often they can be bundled together. It’s important to note that you will not get a lot of the service functionality without the Service Cloud license or marketing functionality without the Marketing Cloud license. So, when you negotiate your contract make sure you’re considering what you need from those license types as well. 

How should you think about optimizing integrations?

Choose where to house all of your contacts – there will be overlap between what’s in Salesforce and what’s in your marketing automation tool (e.g. Hubspot). The worst idea is to have some things in Salesforce and some things in Hubspot without real definition.

• One school of thought: everything in your marketing automation tool – have every record in your marketing platform and you only post strategically into Salesforce, which is expensive (because you usually pay for the contacts in Hubspot/Marketo), but maybe a little more organized.
• The second school of thought: everything in Salesforce – or have your whole database in Salesforce and you only pull what you want to market to into your marketing automation tool

Decide on one-way vs. two-way sync – most marketing automation or outreach systems have the option of one-way sync or two-way sync at the field level. You have to think about what field you need in both systems and which way it needs to sync. 

Think about whether you want to use the tool’s output within Salesforce or via a separate tool – for every integrated tool, do you want to pull everything from Salesforce into this tool because this tool is better used in its native platform, or do you pull the tool’s information into Salesforce so that you only have to log in one place? 

Think about collision handling – eventually, you’re going to get to a point where you have multiple tools and they could overlap in what they do and cause a collision. You don’t have to have to go to the extreme one-off scenarios, but if you’re getting the same data from two systems or there is data already in Salesforce and you’re trying to import it into HubSpot, you have to think about how you want the collisions to interact. 

Avoid over-configuring – make sure that you’re not building the platforms out to be too customized because they’re harder to maintain. You’ll also run into issues when you need to make changes, you might not understand where the data is coming from, or you might not be able to troubleshoot an issue because it’s too complex.

Who should be involved in your build-out?

Don’t build it in a silo – the worst thing you can do is build it in a silo because you’ll be building it multiple times. 

Assemble a small test user group – don’t include everybody (this isn’t a decision by committee). Assemble a group that’s responsible for giving feedback on stuff that’s built, demoing the processes, and weighing in on the overall process. Whatever they say goes. Assuming the project touches marketing, sales, and service, include an AE, an SDR, someone from the service team, and someone from the marketing team. 

Leaders should weigh in, but can be far from the day-to-day – if there’s a decision to be made on something like a process, they need to weigh in. The downfall is that they’re typically far away from the day-to-day process. That’s why I normally go straight to the source and build out a test user with a more senior-level associate. 

Who should be your Salesforce administrator?

You always need an admin – their title doesn’t need to be Salesforce admin, nor does it need to be their full-time job, but inevitably, you need one person responsible for Salesforce users. 

Rev ops often serves as your Salesforce admin – at smaller companies, the Salesforce admin responsibilities may not be a full job, so they become one piece of the sales or revenue ops job.

Avoid having different people be responsible for different parts of Salesforce – one of the biggest downfalls I’ve seen is that you have individual people responsible for their individual aspects of Salesforce. This doesn’t work because Salesforce works as a single system.

Never share an admin license – it’s never a good idea to share an admin license because you won’t know who made changes, when they made them, or what the purpose was. You also won’t remember why the changes were made when you’re looking back. Businesses share an admin license to save money, but it’s never a good idea. 

What standard and custom objects are you likely to need? How do you define each?

Start with standard objects: 

Lead – a lead is a business card. All I know is their name, their email, and their company. Use your lead statuses and stages to flag whether it’s ready to be worked, has been worked, etc. 

Campaign – this is a standard object that’s extremely important. The definition is different across companies but basically, it should be a grouping of leads in the way you want to target them. Consistency is key. It’s important for determining your marketing budget, and cost per acquisition.

Opportunity – when a lead meets defined criteria (there’s active potential to sell a specific product), use convert functionality to convert the lead to an opportunity, which also creates a contact and an account.

• Contact – the contact is the person’s information
• Account – the company information

Product – a standard object that can be applied to opportunities. Apply products to the opportunity, not the account, in case the customer considers multiple products multiple times.

Case – create cases off of accounts to track the service team’s communication with customers. Use tasks to track individual actions, like calls and emails, or other things.

Make objects more specific with record types:

Lead types – you usually only have one record type for leads, unless you have third party referral leads, with different lead types for different referrers.

Opportunity type – I recommend different types for a new business opportunity, an upsell opportunity, and a win-back opportunity. Use opportunity types for different types of Anything revenue you’re receiving, but definitely don’t do a product base because that’s what the product object is for.  

Case types – separate out inbound resolution cases and standard outreach cases. For example, some companies do quarterly business reviews, which could be a case record type.

Use stages and statuses to track objects

Leads have a combination of stages and statuses:

• Status – what you’re doing with the lead
• Stage – how they’ve engaged with you so far 

Have a clear definition of what an opportunity is – i.e. you’ve determined that you can do business with them and they’ve determined that they could do business with you and use your solution. This is a key demarcation point between leads and opportunities.

Opportunities need stages – opportunity stages are super important to build out your weighted pipeline. The number and breakdown of stages really depends on your sales and business process, in general, I recommend three to six.

• A “sales qualified” stage – there might be two different qualifications, one where the SDR says it’s qualified for the criteria and one where the Account Executive says it’s sales qualified. It’s not in the pipeline until sales has accepted it. 
• Validation – verifying there’s budget. 
• Product set – figuring out what product set would fit. 
• Negotiating – after the product set is selected, negotiating the price
• Closed – when the sale is made

Cases need statuses – case status is important but less robust. At the very least, you want a new, in-progress, and closed status. There’s a reason why in-progress cases aren’t complete that need to be filled out.

Create custom objects for special use cases:

Handoff objects from sales to service – if there’s a heavy post-sale implementation, you might have an implementation record type

Survey objects – within a survey object, you could create different record types for each survey you send.

CPQ object – on the sales side, if you end up using a configure price quote (CPQ) tool, the software will automatically create a custom object for you. 

How should you think about custom fields (what’s the balance between a good addition and too many)?

Max out your 250 custom fields, so long as you don’t require sales reps to create them all – I think back-end custom fields are the best part of Salesforce because you can create them and you can trigger stuff off of them. You can do calculations and create prioritization. My general rule of thumb is a 75/25 split. 75% of your custom fields should not need any data input and the other 25% of them should need data input from a human being. 

How should you think about reporting?

Don’t skip reporting (you’ll waste the data) – if you can’t figure out Salesforce reporting, the worst thing you can do is to build out your process and then not use any of the data. Because why are you bothering to do this? Worst-case scenario, export your data, put it in Excel and start using it. Figure out your actual reports and pretty dashboards later, but don’t not use your data. 

Don’t be afraid to create custom report types – if you can’t find what you’re looking for, try to build out the custom report type by assembling the data you need across objects and fields. Don’t worry if it might already exist but you can’t find it; there’s no harm in building your own report type.

What can you do to improve the data quality?

Put help text on all of your fields – a really easy thing to do is put help text. It’s a pain when you’re doing it, but it helps people see exactly what it is. Also include the description, that way when you look back you can figure out that you created this field because of X request.

Use validation rules (when it’s simple) – simple validation rules are good, e.g. you don’t want anyone to ever choose that the priority is high if the revenue is less than a dollar. Put the validation in so that people can’t enter obviously wrong data.

Consider whether pre-populated fields should be read-only or editable – you might automatically set the close date to be 90 days out upon creation, but then certainly the account executive would update this based on the knowledge that they have later in the process. But there are other fields that you only want to update via workflow, which should be read-only.

What are the most important pieces to get right?

Consider what data you want out before you build – consideration of what data you’re trying to get out is the most important. Figuring out what piece of data and what questions you’re trying to answer is so important. 

Map it out end-to-end and get buy-in – the next thing is the end-to-end process. How does the data get in and how does it get out? Mapping it out and getting a visual is very helpful. 

What are the common pitfalls?

Wasting time and money on integrations and customization – people waste money on integrations without maximizing out what Salesforce can do. Outsourcing too much with integration is a pitfall.

Don’t forget to use the massive amounts of online info – Salesforce is so big and has so much information, so you have to ask questions, read online, and watch videos to learn. Google constantly and make sure that you’re using the information that’s out there.