Salesforce Drip Marketing

Our clients have frequently asked for help with drip marketing systems for their systems. There are quite a few options for solving this problem, but I'll detail my favorite below.

(We later wrote this application and are making it available for sale and you can read about the specifics here.)

At the high end there are some third-party applications available on the Salesforce App Exchange that have drip marketing systems built in, but they are surprisingly expensive. So for the purpose of this blog, I'll restrict my ideas to those you could build yourself (or get our help building).

To frame my comments below, let me explain some terms I'll be using: "Touch Track" and "Touch Point". A "Touch Track" is a way of noting the various points along the way that a lead or contact will be "touched" ("Touch Point") as a particular drip marketing campaign is carried out. For example, you might have a touch track with 2 touch points, the first being an email 3 days after the prospect is added to the track, then scheduling a sales rep to make a call attempt 4 days later. You'll see systems like this called Salesforce Automated Touch Campaign or Salesforce Drip Marketing - and probably a few other variations.

A Workflow Based Salesforce Touch Campaign

So lets review some ways you can do Drip Marketing (aka Touch Campaign) in the native environment. At the simple end of the complexity scale you can use time based workflow rules (in Enterprise Edition) to kick off emails or schedule tasks. This is fairly simple and can be quite capable for the company that doesn't have very sophisticated requirements. In a nutshell, have a "Touch Track" field on the lead or contact record, then kick off a time based workflow depending on the track selected. You could have multiple tracks depending on the steps that you want executed against the particular record. There will be a time based workflow rule setup for each track. If you're just doing this against both leads and contacts, you'd have another set of these workflow rules for the second object. The steps are contained in the particular workflow.

A Better Salesforce Drip Marketing System

A more sophisticated method would be to setup a custom object to contain the steps. A good place to locate this custom object would be as child to the campaign. Then using APEX, a scheduled batch process could be written that executes daily, analyzes the steps under the campaign and how far down the touch track each campaign member is on the day of execution, then takes the action required by the step.

So lets say we call this object the "Autostep" object, our data model for this system would look like this:

The manager of the system could then simply create a campaign for a touch track. Later, leads and contacts would be added as campaign members. The steps of the touch track would each be individual records in the Autostep object. This object could have a number of fields, depending on the level of sophistication desired, but here are a few I think would be essential:

Useful Autostep Fields

Various fields would be needed on the Autostep object. Some I note below would be essential, others maybe not so much - the real requirement would be determined by the functionality that you required. Here are some that I think would be useful:
- A lookup to the parent campaign
- Days until Action: Defines the day on which this step would be executed. I'm thinking this would just be a number field and would indicate the number of days after campaign membership creation (the day the lead or contact was added to the campaign) that the autostep would "fire" against the associated lead or contact.
- AutoStep Record Type: Options for Email, Task, Event or other desired actions like "Post Card". This is a user interface consideration. The record type lets us have different page layouts for fields that may differ based on information needed for the type of action taken. For example, Work Days (noted below), wouldn't be displayed on an Email Step type, but you would want the Work Days field displayed for Tasks, and record types provides the means to choose the appropriate page layout.
- Work Days: this would only apply to a task assigned to an internal Salesforce user and it is the number of days that you want to provide to the worker to accomplish the task. So let's say a task is due on the 10th and you want to provide the worker 5 days to work on the task. The system would make the task 5 days before it is due.
- User: we need some method for identifying the responsible user. The task may define an actual user or tell the system to use the lead/contact owner, or account owner, or a certain role, etc - again, this depends on the level of sophistication that you want.
- Subject: a word or phrase that would be entered into the subject of the event or task
- Comments: text that would be entered into the comments or description field
- Template ID: the record ID of the email template that the system will send

Executing the Touch Campaign

To target an individual in the salesforce drip campaign, simply include that person's lead or contact record as a member of the relevant campaign. The campaign, as a reminder, is the "container" of all the various autosteps - it becomes, in essence, the salesforce touch campaign. The kickoff date will be the created date of the campaign member record (or other relevant field if requirements dictate).

An APEX scheduled batch process can then be written that executes every night, evaluates all the campaigns where autostep records exist, look at the "Days Until Action" field, identify the campaign member records that qualify for an action, and take that appropriate action.

Advantages of this Method

- The same system can handle both leads and contacts (by virtue of the campaign member's association with either a lead or a contact record).
- This system takes advantage of the existing system of campaigns, the advantage being that these names can be provided via the campaign to other major systems such as third party email providers.
- Since this is a custom system already, when a need arises, the system can be further customized to include new functions. If the workflow method described above is used, it only has the capabilities available to the workflow rule - it can't be customized.
- Unlike the workflow rules, the steps can be easily modified by adding and removing autostep records.  To modify a time based workflow rule you have to deactivate it and delete all future scheduled activities - meaning a simple change can completely disrupt ongoing processes.
- Salesforce Web 2 Lead can add a lead to a campaign automatically, so a touch campaign against a new lead can be initiated upon their form submission.

Note: when using the native Salesforce system for Drip Marketing Campaigns, is sending your emails for you and they have a limit of 1000 to the number of emails you can send each day. You'll want to keep that in mind as your campaigns grow in size. But as with all custom development, we can almost always find a way around problems like that. If you do find yourself running up against email limits, the system could simply add the send requirement to another custom object handled by its own scheduled batch which has the responsibility of sending 1000 emails a day. When over the limit, the remaining emails could be sent the next or following days.

If you would like to discuss this idea further, or get some help developing this functionality, please contact us. It's our business to help companies using get the most out of their investment. You can find us via Touch Mobile Application Development

You see the advertisements every day now when logging into or out of - it goes something like this: "Building your mobile app to work with is easy as pie!"

So you start thinking: "okay, cool, my team sure could use a mobile app while out on the road to access their data, and the standard mobile app doesn't do what we need - so if it's so easy, lets do it."

Then you start trying to figure out how to do it and you realize, this isn't actually "easy as pie." It's actually quite involved. But, it is doable - and our development team has done it - so let me tell you what we've learned.

There are several ways to provide access through a mobile device to data. Mobile Device Options

1) Use the native browser on the device to login in to
2) Using a Salesforce Sites page - format the output of the website to fit in a mobile browser screen size
3) Build a native application on a mobile device that can access data
4) Use HTML5 and the Touch platform to deliver visualforce pages to a mobile device.

It is option #4 that Salesforce is advertising. And while it is WAY easier to build applications on the Touch platform than it is to build a native application on IOS or Andriod (option #3), it isn't necessarily "easy as pie".

The Touch Platform - Web Pages in an App

Here is the key thing to know about  HTML5 and the touch platform: you are simply viewing a visualforce page in the mobile browser on the page without the skin of the mobile browser. Even more simply: its a web page. A mobile web page. But it LOOKS LIKE an application on the device.

In, visualforce makes it possible for us to write custom pages that provide custom functionality to your users. These visualforce pages can be built with display on a computer through a normal internet browser in mind, or they can be built with the intent of displaying them on a mobile device.

The Pro - Quick and Inexpensive Development

The cool thing about using the touch platform is that we can fairly quickly write these visualforce pages and your users can take advantage of them on their mobile devices. Many companies have realized the incredible upside to building custom applications on They can provide their user's with the means to quickly handle business processes against their data stored in At Snapptraffic Consulting we've written thousands of these applications and have seen first hand how the right functionality can greatly increase an employee's effectiveness. Salesforce Touch makes it possible to provide the same kind of custom functionality through the mobile device when away from a computer. Visualforce pages can be written relatively quickly. Native mobile applications (option #3 mentioned above) are much more time consuming. So writing visualforce pages that can be deployed through Salesforce Touch is a great way to increase productivity for your mobile employees without the expense of producing a native mobile application

The Con - An Internet Connection is Required

The downside, to use the application you've written, you must be connected to the internet. If you want the application to have the functionality to download data for offline use, then the touch platform isn't for you - a native mobile app developed for the device that accesses and downloads data (again, option #3) is what you'll need.

Ready to Build Your Own Salesforce Touch Mobile Application?

If you're thinking about building a mobile application to access your data and want some help making it happen, give us a call. We'd be happy to listen to your idea, give you a feel for the costs and timeline involved, and help make your mobile app a reality. You can reach us  through