Get Started

Triggering follow-up actions, nurturing tactics from Drift leads

Drift is a Boston-based startup redefining the way businesses by from businesses. Amongst a growing line of products, their core offering is a platform in the Conversation Marketing space. Often over-simplified to “live chat and chatbots”, Drift offers a platform that enables you to expedite the sales process by fast-tracking the most qualified of site visitors to the right teams and allowing them to interact with marketing, sales, and support on their own terms.

Out-of-the-box, Drift interacts with most major marketing automation and CRM systems (Hubspot, Marketo, Pardot, Eloqua, and to name the mayor players). While each integration is slightly different, Drift is able to push leads/contacts into each one and in some, can push different events/actions. For example, in SFDC, Drift can push native activity records each time a conversations occurs or a meeting is booked.

But what if you want Drift to trigger more advanced follow-up actions or nurturing campaigns? What if you want Drift to be able to subscribe visitors to your blog, enter person-specific drip campaigns, etc.?

In that case you’re going to need more than just lead information pushed into your system. You’re going to need to know exactly what actions took place during the conversation and which “playbooks” (Drifts term for the specific bot flow) the user interacted with.

In this article, we’re going to cover two ways to achieve this extra level of information:

  • Setting custom attributes within Drift
  • Getting the playbook ID for each interaction

Setting custom attributes within Drift

If you’re looking for a more “native” way to accomplish this task, you might be able to get it done directly within Drift. Hidden inside Drift’s Question Skill the playbook builder is a nice functionality called Apply contact attribute.

This allows you to set a certain value on any contact field you want based on someone either getting this far in the playbook or answering a certain way. In order to take advantage of this functionality, we recommend creating a field in Drift that will let you store a visitors intent. In our case, we created a field called DriftAction and every time someone gets to a specific points in our playbooks, we overwrite the previous value (if any) with the new action. Here’s some example values we might store in DriftAction:

  • SubscribeToNewsletter
  • RequestedProposal
  • SendROICalculator
  • QualifiedBuyerDripCampaign

Now that we’ve populated a field in Drift with the users intent, we can map that field to our marketing automation system to trigger other actions.

Bonus tip: We recommend making sure each automated workflow or campaign ends by resetting the contact property in your marketing automation system so that it’s ready to go when a user may come back and take another action. In Hubspot, a workflow to automatically enroll contact into your newsletter from Drift might look like this:

  1. Trigger: On contact property updated: DriftAction
  2. Logic: If contact property, DriftAction = SubscribeToNewsletter
  3. Action: Add contact to list: Newsletter
  4. Action: Set contact property: DriftAction = NULL

Getting the playbook ID for each interaction

Another way to go about achieving the same as above but in a slightly more scalable way is to programaticly pass Drift playbook IDs into Drift when a conversation begins.

The script below should be added just below the place you put Drift’s install code:

How it works: We set a variable to know if we’ve set the playbookID to FALSE and then just to be sure, we set the the contact attribute recentPlaybookID to NULL (in case it’s already been set in the past). Then when the first message is either sent or received from Drift, we grab the ID and set it. Finally, just to make sure we keep things clean, we tell the script that the job has been done and we don’t need to do it anymore during this conversation (that way we don’t spam Drift’s APIs).

On the marketing automation side, you’d take these playbook IDs and know which playbook correlates with which action. While this solution is a bit more scalable, it requires you to know which ID does what thing and it is also a little more strict in the fact that one playbook could result in a variety of different actions whereas passing a playbook ID to your MAP is a bit binary.