Most of these quick start Salesforce deployments elapse over only a few weeks, and are packed with discovery sessions, project management, “development” (aka simple configuration), training, etc. All these activities can make the implementation cost tens of thousands of dollars, and deliver questionable results.

These implementations are borderline absurd because people tend to buy Salesforce for aspirational reasons. “I want to get visibility into our pipeline”, “I want to automate contract creation”, “I want to generate better leads”, “I want to make sure leads don’t fall through the cracks”, etc.

Unfortunately all of these goals are complex, take business process engineering, and features need to be properly adopted. But, during discovery sessions the client often asks for their aspirational goals to be delivered within the project. The fundamental problem is that consultants are quick to include these features in the scope of the implementation.

I don’t fault the client for asking for these goals; this is why they bought Salesforce. The problem is that rather than advising the client on the reality of achieving these goals, consulting partners imbed these requirements in the scope of the implementation, driving the cost up. This is good for the partner, but is the wrong approach for the client.

Most prospective Salesforce customers have ad-hock systems built mostly on spreadsheets and email. Customers often fail to understand that they’re moving to a highly structured application built on a sophisticated relational database. Fully adopting everything Salesforce has to offer is like trying to drive a Formula 1 car when you don’t even have a license.

The bottom line is that it’s virtually impossible achieve aspirational goals within a few weeks. When you engage in a poorly designed quick start, the vast majority of your budget may go to features that will take years to adopt. This is wasteful, and despite spending the money, you may come out of the engagement feeling like little was accomplished.

If you’re implementing Salesforce my recommendation is to follow one of two paths:

1. Ignore the quick start idea and properly invest in the project. A good implementation should, provide ample training, accommodate time to adopt features, coach users and admins on effective use, and iterate as requirements change. This approach let’s you evolve the implementation over months.
2. Keep the initial implementation scope as small as possible. Try and stick to features you’ll actually use within the first month. Follow-up with an ongoing support agreement so you can pickup the phone and talk to someone. Then plan for additional small engagements to implement additional functionality, as you need it.

The problem with the “integrated” label, is that it can mean just about anything. As Salesforce grows, more and more business applications feel they need to say they’re “integrated” with Salesforce, otherwise they risk losing sales. In reality, many of these apps say this despite only half understanding the Salesforce API, meaning they could integrate their application if asked.

Simply put, no integration is equal
You should never accept a vendors statement like “our application fully integrates with Salesforce”, whiteout diving into the details of how that integration works.

So that you can avoid headaches down the road, here are some questions to ask:

Does the application read Salesforce data or does it read and write Salesforce data?
This is by far the most important question to ask. An application that simply reads Salesforce data is the simplest architecture – and is often recommended for initial integration projects. However, at some point, you’ll want some of that data back in Salesforce. For example, QuickBooks reading the data from a closed won opportunity helps make your organization efficient – this is a read only requirement. A truly integrated QuickBooks would mean a Salesforce account can be flagged as having a 90 day past due invoice. This bi-directional integration is when you get true value.

While a simple read / export of Salesforce data sounds simple, don’t under estimate how difficult this can be. For example, if you have an external system that needs to pull the contact details of all contacts associated to a customer account all of the following can make this complex:

1. Salesforce must accurately flag accounts as customers.
2. You need to decide if all these contacts really should be sent over (do you really want the details of the accounts shipping and receiving clerk to be integrated?), if not, this is another layer of complexity your integration needs to accommodate.
3. What is the time frame for integrating records – do you need real time or scheduled.
4. Does the integration care what products / assets the account has purchased?
5. This list only gets more complex …

The point is that an integrated application must accommodate your level of complexity when reading or writing Salesforce data.

Is the application on the AppExchange?
The easiest way to guess the quality of an integration is to ask if the application is, or will soon be on the Appexchange. Even a simple data connector listed on the Appexchange must pass an intense security and technical audit. While these integrations are not all equal, it’s a good start to understanding how well the application integrates.

Note: if the application is not on the Appexchange, you must have Salesforce enterprise edition because the integration must use the Salesforce API. Apps on the Appexchange can be installed into Pro, and through Salesforce.com’s new Aloha app program, applications can be installed into group edition. Most “integrated” salesforce applications don’t tell you this on their website!

Does the application write data to Salesforce standard objects?
Believe it or not, this can be one of the hardest things for an integrated application to do. The integration must manage simple things like required custom fields, record types, and validation rules. Remember, if you’ve created one required custom filed, it will cause a write command to fail. To avoid these problems, applications will often install their own custom objects to manage data.

Can the the application read Salesforce custom fields and objects?
Salesforce standard fields and objects are easy to integrate because their API names are the same across all Salesforce instances. However, for an integration to be truly effective, they need to know that custom fileds and objects exist through the use of Salesforce.com’s Meta Data API.

If the application creates contact, account or other records, does it do any de-duplication?
It’s almost too easy to insert records into Salesforce, meaning your integrated application can indiscriminately create contact, account or other records in Salesforce. If the application doesn’t do anything to address de-duplication of records, the lack of data governance will quickly pollute your Salesforce database. If it does de-duplicate, you sill need to understand how the data integrates. For example, does the integration allow you to designate fields that can never be overwritten. You don’t want your good email address overwritten by a disposable email used to fill out a web-form.

Does the application require custom Apex Code to function?
While custom Apex code and Visualforce pages are common to most integrations, you should understand what the code does, and if it interacts with other applications or Salesforce functionality. For example a de-duplication script should be local to the application, and not interfere with every upload you do.

I’m currently trying to de-bug why I can’t de-activate a user because the user is referenced in an opportunity workflow field update. Of course none of the documentation makes reference, or aludes to the idea that a user is referenced in a field update. This forces me to go through every rule to locate the dependancy … fun.

The problem with documentation.
Documentation is a chore, and we all know that no one likes to read documentation – it’s only referenced anyway. To make it even more complicated, one of the chief benefits of Salesforce is the speed that we can implement changes. All it takes is a simple modification of a workflow rule, and your documentation is out of date.

Inline documentation
We can take a lesson from newer development tools and practices where documentation is written inline with the application code. Salesforce provides us a name, and more importantly a description filed for all fields, workflow rules, templates, etc. It’s in the description filed that you need to document the following.

• The behaviour of the feature. This is the reason why the feature exists, and is the most important thing to document.
• The dependancies. If the rule only fires because of some other action, document that action.
• How the feature works. If you still have the time and patience, document how the feature works. But remember, often all the user needs to do is view the formula to see this information.

Even when we document, we often do it wrong!
We generally document backwards. We tend to document technical attributes of a feature, but not the reason the feature is there. For example, it’s typical to see “this workflow rule sends an email to the account owner”. However, this statement is irrelevant because all I need to do is look at the rule to figure this out. What I need know when I take over your Salesforce account, is why you’re emailing the account manager, not the fact that you are. Your documentation doesn’t tell me that the update is designed to tell the account manager that implementation services are required.

This kind of documentation let’s me quickly respond when someone asks “can we add the CSM team to the notification email, when implementation services are required”. Business people talk in use cases, your documentation should too.

In general, Lauren give’s Salesforce very poor marks for it’s marketing automation capabilities. However, I feel Salesforce should always be on your marketing automation short list – but never on its own. Here’s why …

Salesforce is not a marketing automation system (yet)

Looking at Salesforce in isolation misses one fundamental issue. Salesforce currently has no public intention of becoming a marketing automation system. Two of it’s most well known limitations should make this obvious.

1. Salesforce will not allow an account to send more than 1000 emails within a 24 hour period. Salesforce will explicitly tell you to use one of their many appexchange applications to support these requirements. This is one of the few limitations where you can’t buy an increase.
2. Secondly, any form of marketing automation has data heavy requirements. Salesforce’s data storage limits causes even small contact lists to exceed these limites, with even moderate marketing activity.

In my view, Salesforce is focusing on three core areas, it’s core SFA functionality in the Sales Cloud (chatter, content, DimDim, Jigsaw, etc.), platform functionality with the Custom Cloud (governer limits, VMforce, Heroku, etc.) , and customer service with the Service Cloud (Cases, Ideas, Portal, Twitter, etc.). Note, I’m putting native applications like Remedyforce in the custom cloud bucket.

How Salesforce supports supports marketing automation

I feel Laurin’s review errors by assessing Salesforce in isolation. Through it’s API, Marketing automation seamlessly fits into Salesforce’s application architecture. (keep in mind that some MA vendors have better integrations)

Sales Cloud – integration with the Sales Cloud allows the marketing user to:

• Get a complete end-to-end view: from new lead, to closed deal
• Solicit sophisticated feedback from Sales by implementing a sales accepted lead process
• Manage named accounts, and ensure leads are routed to quick and effectively
• Track the purchase activity of all contacts

Custom Cloud – salesforce is generally the database of record for contact information. Salesforce’s powerful developer tools allow the marketer to:

• Perform advanced data transactions to clean and update records. Including sophisticated custom de-duplication triggers
• Expose Salesforce data to any external system
• Support a custom post-sales support process
• Create custom coded email templates based on the Salesforce object model
• Website integration, including the ability to integrate with payment gateways

Service Cloud – Salesforce allows you to keep tabs on current customers, allowing marketers to

• Intelligently communicate with their current customer base
• Quickly learn if a customer has logged support tickets
• Determine who happy customers are

Conclusion

In my view, unless you’re a very small business, Salesforce fits into the marketing automation picture by being a central cog in a best of breed application architecture. Typically Salesforce integrated with a single marketing automation vendor. See my post on the 4 ways to extend salesforce to the marketing department.

For the past few weeks I’ve been sitting on an announcement that I can now make public. I’m excited to say that today will be my first day as an Eloqua employee.

Working out of Eloqua’s Toronto office, my mandate is to help drive Eloqua’s use of Salesforce.com, ensuring Salesforce is the CRM and development platform we all know it can be. If you know me, or have seen one of my posts, you may know that much of my experience is using Salesforce to drive marketing, and marketing automation requirements. This makes the opportunity at Eloqua truly exciting.

While this is an exciting opportunity, the decision to accept it was far from easy. My time at Architech Solutions was engaging, and allowed me to grow into a well rounded Salesforce solution consultant. In the last two years I’ve had the pleasure of working with 15 clients. From initial pitch, to final project completion, I’ve had the privilege of working on:

• Two soon to be appexchange apps
• Sophisticated marketing automation requirements
• Calculating customer value, LTV, donner lifetime value, lead score, opportunity health, etc.
• Lead and opportunity management visualforce pages
• A six figure ERP style custom application that relies heavily on visualforce pages to drive workflow
• A custom product catalogue that supports a matrix based pricing grid
• Complex systems integration
• Multi-year rollout and integration plans
• Early lifecycle implementations
• Administrator and end-user training

I’m grateful for the opportunities that I’ve been provided at Architech. I’m now looking forward to bringing my Salesforce experience and perspective to Eloqua.

In the past I’ve returned with grand ideas of what I thought would help our business, so I understand the enthusiasm. But I’ve come to learn that if this enthusiasm isn’t managed, we’ll quickly get overwhelmed, causing us to lose track of where to start. Ultimately, this allows the status quo to remain.

The problem with case studies
We need to remember that these success stories are from other companies. Just because they’re doing something doesn’t mean you can implement it tomorrow (or possibly ever). We need to understand that these organizations have a unique mix of culture, people, skill, budget, technology, etc.

Case studies help establish your vision
The reason I love case studies is because they help us establish our vision for the software. But my advice is to use them to guide your vision because only you can figure out what you need to get started. Again, just because another company used a tool on Appexchagne doesn’t mean you’ll have the time, technical skill, or budget to achieve the same results.

Putting ideas into action
Before you get started I suggest you do some form of gap analysis. Here’s what I’ve typically done with clients.

1. Think about what you’re doing today
This means reviewing the systems you use, the responsibilities of these systems, your current business process, how these business processes align with your systems, etc. But, don’t let this become a drawn out assessment by keeping it simple. You just want to understand your starting point. The liberal use of a whiteboard can help with this.

2. Determine what you want to do
You don’t need to be a Visio wiz to do this. Simply make statements of how you want Salesforce to work. I must stress that these need to be specific and actionable tasks. Don’t say, I want Salesforce to manage my post sale activities. Break these activities down into the tasks that need to be done, i.e. send an invoice, assign a service rep to the account, etc.

3. Apply these requirements to Salesforce
Once you have a clear backlog, you’ll be able to figure out how Salesforce will assist you in the completion of these tasks. For example there might be an Appexchange app that does exactly what you need, you may be able to use a simple pick-list field to track key information, a web-to-lead form with a welcome email may satisfy your marketing needs, etc.

4. Prioritize
When you have a clear set of tasks with an understanding of how you’re going to do it, you essentially have an implementation backlog. Now you need to prioritize it! Unless you have a large project team, I suggest you force rank these requirements. This will allow you to start from the top of the list and work your way down.

5. Get to work!
Those validation rules don’t write themselves …

Native salesforce email
This is the simplest and cheapest way to begin your email efforts, but it has many limitations. Salesforce limits you to 1000 emails a day, meaning your list needs to be very small. It also does not provide link tracking, meaning you can’t track simple metrics like click through rate, or who clicked on what.

The most meaningful use case for native salesforce email is to support simple triggered and transactional emails, or emails that need to pull complex data from your object model. These emails will let you send thank you emails for signing up on a web form, automated follow-ups from sales, reminder emails for renewals, etc. These triggered emails can also be programed using Visualforce, meaning Apex controllers can pull data from across your data model to populate an email. No matter what marketing automation program we recommend, we often need to use these emails for a clients complex email requirements.

Integrated email service provider
The most common way of extending Salesforce is through the use of a 3rd party email service provider (ESP). There are a growing number of these tools, and most support simple integrations which pull the contact table, or integrate through the campaign member record. Note: when using these 3rd party tools, make sure your Salesforce data usage doesn’t explode.

I almost always recommend ExactTarget for this kind of mass email. ExactTarget has a much deeper integration with Salesforce than any other ESP. Specifically, ExactTarget integrates with Salesforce reports, and allows filtering by the campaign member status field. It also supports the exclusion of contacts contained in a report. These tools allow you to make very detailed segments.

‘Drip marketing’
If you want to go one step beyond the process of defining a list and sending out an email, you’ll need to look into tools that support more advanced marketing automation, commonly known as drip marketing. Standard uses cases are a new lead welcome program, a defined lead nurturing campaign, triggering an email based on the link a contact clicks on, etc. If your volume is higher than 1000 emails a day, or require email link tracking, you’ll need to look into a more advanced version of ExactTarget, or a marketing automation system like Eloqua, Genus, Marketto, Pardot, and others.

Integrated marketing automation
Last on the list is a fully integrated marketing automation system. These powerful applications support many different marketing tools that go far beyond email. Tools like Eloqua, Marketto, and others offer marketers: deep and customizable integration with Salesforce, landing pages, email, web analytics integration, lead scoring, complex marketing automation programs, social media, campaign ROI tracking, etc. These tools require significant buy-in from the marketing team as they can be pricey and complex to implement.

If your Salesforce requirements are particularly data heavy, the limits on data storage will quickly become a major problem. Salesforce.com has implemented a seemingly arbitrary data storage minimum of about 2Kb / record, meaning it only takes 500,000 – 700,000 records to max out the default 1GB (or 20MB / user) most organizations are allotted. With storage space costing about $800 – $1,500 / year / GB, an application that adds 1,000,000 records / year will add $2,000 – $3,000 every year to your bill. Do this 3 years in a row, and your bill can be $6,000 – $9,000 / year higher.

The most obvious example of this problem is an integrated mass email program. If you have a list of 100,000 contacts, and email them once a month, it can add 1.2 million records each year to your Salesforce environment. This will likely make your email marketing program more expensive than you originally thought!

Why is data so expensive?

$1,500 for 1GB sounds crazy when you can go to the store and buy an 8GB flash drive for $10. In my view the cost of data storage is actually about record volume and how they impact Salesforce transaction speeds. When you run a trigger, Apex class, Work Flow rule, RSF, create or edit records, these tasks create transactions that need to be processed by the salesforce.com data center. These operations can get very computationally intensive when your Salesforce environment has millions of records. If there are too many transactions across all Salesforce customers, the system will get slower … for every Salesforce customer.

Multi-tenancy means we all need to get along

Salesforce.com is proud of their transaction speed, and they publish in on their website. Currently it takes about 0.28 seconds to process a transaction. But this speed is maintained through various limits.

In order to maintain a stable environment for salesforce.com’s 80,000+ customers, these limits are necessary to ensure transaction speed can be maintained and kept reasonable. Just imagine if it took 30 seconds to save a record because another customer was processing a job that created and modified 100,000,000 records.

To ensure we all get along in the cloud, Salesforce.com creates these limits.

If it’s about transactions: why the price per GB?

It’s true that charging for more transactions, or record storage would make more sense. It’s my belief that it’s priced per GB because Salesforce.com’s target demographic is the business user. Try explaining to a non-technical business user what a transaction is, let alone charging for them.

Salesforce.com is routinely increasing these limits to become a more attractive enterprise development platform, but for now, my recommendation is to store what’s necessary and pay for it, cleanse unnecessary records, use the API as much as possible to query very large external data sources, etc.

Close rate, sales booked, and leads generated are functions of your sales efforts, the activity of marketers, R&D, etc. These metrics are also heavily influenced by external sources. Sales might fall because of the economy, leads are not generated because of a poor website, and so on. To get success metrics that focus specifically on the operation of Salesforce we must find indicators that that show how Salesforce is performing. You must then detail how these metrics influence bottom line results.

Here’s a quick list of success metrics, with a brief idea on how they impact bottom line results:

Login rate
Adoption rate is the king of all salesforce measurements, meaning the login rate should be the most closely monitored of all metrics. It should be clear that if people aren’t using the system, it will not impact revenue. While login rates will vary depending on the organization, you should strive for:

• Daily login for all sales people
• A steadily increasing by all profiles
• An increase when any new functionality is introduced

Usage
Moving one step beyond login rates will paint a more complete picture of user adoption. Where ever possible, you should be measuring: (this list is just an example, these measures can get very specific)

• Record creation and modification
• Report creation – if users are creating these themselves, you know your doing something right
• Opportunity modification – when users are making detailed changes to the opportunity, it suggests the opportunity logic is being used to manage sales
• Tool usage – if new tools are introduced, determine ways to measure if / how these tools are being used

The ability to measure KPI’s
While this may not sound like a success metric, the ability to measure KPI’s can be the most important result of Salesforce usage. If your organization is unable to determine metrics like close rate, lead source, forecasts, etc., you have something to strive for. The ability to measure these items are binary, you can or can’t do it. List the KPI’s your organization wants to measure, and ensure the Salesforce is used and configured to achieve these these measurements. When you can measure, you can manage things like:

• Which deals close at a higher rate
• Which deals are more profitable
• Which leads convert at a higher rate
• Who your most profitable customers are

When armed with this information, your company can begin to optimize it’s efforts. Direct ROI is achieved through this optimization. For example:

• Your company can allocate more sales resources to your most profitable customers
• Stop spending money on unprofitable lead sources
• Determine which sales people are the most effective

User feedback
This one is simple, if users don’t like the system, it generally won’t yield ROI. Users should see Salesforce as a tool that helps them do their job, not a painful place to enter orders. If Salesforce is to become a critical business tool, find some time to talk to users and collect feedback. You should also segment users based on their login rates, and find out why users aren’t logging in, and why power users love the system.

Salesforce data quality
This metric is related to the ability to track KPI’s, because without good data, KPI’s can’t be trusted. At the very least, data should be stored so KPI’s can be generated without the need for ad-hawk reporting. Determine what information is critical to your origination, and measure if records are collecting this information. Records can be scored by their completeness, and users can be identified by their tendency to create good and poor quality records.

Efficiency
Salesforce success should not only be measured on it’s influence on sales. Salesforce also has the ability to automate person hours out of existence. If the reasons for implementing Salesforce is to improve process and workflow, you will need to create benchmarks for the time it took to complete an activity before and after Salesforce. This of course needs to include the added expense and administrative time Salesforce now requires. These hours saved can be reported on as monetary improvements to the business.

Depending on your objective, you can measurably improve things like:

• Time to quote
• Time to bill
• Time to deliver the product or service
• Time to create end of month reports

This challenge is largely do to the way salesforce.com brands their products. Salesforce.com has decided to make all the products they offer seem like unique, packaged applications. This approach has extended to the nonprofit edition of Salesforce, which has created this confusion.

Salesforce Enterprise Edition, and the not-for-profit edition are the same thing
I want to be very clear, the nonprofit edition is an enterprise edition license of Salesforce. Every feature – including the Force.com developer tools – that enterprise edition comes with, are included with the NFP edition. The only thing that makes the NFP edition unique, is a group of tools which have been pre-installed through ‘managed packages’. These packages are known as the nonprofit starter pack.

What are these tools?
A managed package is a set of functionality that is installed into a Salesforce account. This functionality has attempted to make the standard Salesforce environment more alligned with the standard requirements of a NFP. Here’s a very quick overview of each feature.

Contacts and organizations:

• Renames the “account” object to “organizations”
• Allows individual contacts to be created without the need to associate them to an account (which is required in the standard Salesforce edition)
• Rolls-up donations to the contact – the standard Salesforce edition only rolls up transactions to the account
• Allows multiple phone numbers and email addresses – However, I’m a fan of this tool

Recurring donations:

• This is a light weight tool which automatically crease ‘donations’ that occur on a regular interval

Relationships:

• Allows contacts to be associated with other contacts
• Adds fields for social media addresses

Affiliations:

• Allows contacts to be associated to multiple organizations
• Tracks when a contact is associated to a new organization - for example when they change jobs

Householding:

• Allows contacts to be related to each other through a household record

There is now a 2.0 release of the nonprofit starter pack, which should be available shortly. You can get the detailed on each of the NFP starter pack features here. The Salesforce foundation has a good overview of all the features here.

It’s called a “starter pack” for a reason
While these features may sound great, in practice each of the above features are limited. The light weight nature of these tools are good to get started with, but even simple requirements may not be supported. So don’t get completely hung up on the idea that these tools are a silver bullet for your use of Salesforce.

When you out grow these features
The challenge with working with the nonprofit starter pack is that the behavour can’t be modified (technically this is due to the type of package). This often causes us to uninstall the feature set, and build to the clients specific requirements.

The good news is that the nonprofit edition is enterprise edition, meaning we can make just about anything work – and easily re-create the nonprofit starter pack features. The point that I’m making is rather than bending to the above features, you should divorce yourself from them, and look at your true requirements.