Skip navigation
All Places > Champion Program > Blog > 2018 > September
2018

This post details some of the tactics I presented at the Marketing Nation Summit this year, the slides can be found here: Cut me some Slack! Leveraging The Slack API With Marketo Webhooks And Bots

 

Slack is a powerful tool for communication and collaboration. I think it's safe to say that the most of us have at least used Slack at one workplace if not on a daily basis. With the many useful integrations built by other tools we use, we have access to all useful information in one place and it's great at replacing tedious email threads.

 

A couple years back, I discovered the Incoming Webhooks integration from my previous colleague Henri Syvänen at Avaus and it gave an amazing opportunity for sending relevant lead alerts to Slack channels where teams could monitor the most interesting touchpoints Marketo was processing.

 

Starting with a fresh Marketo instance last year, we quickly got to setting up relevant alerts for marketing & sales to keep people in the loop of what Marketo helps us with how we can track high-intent conversions in the funnel:

 

marketo-alerts-across-funnel.png

Overview of Slack alerts across lead lifecycle stages

 

Although very insightful with alerts split up in different Slack channels, it was easy to miss/forget interesting leads in MQL alerts. I was setting up a few API integrations with other tools we use and got quite interested in how Slack apps work and the possibility of creating smarter alerts that were interactive to push data back to Marketo from Slack - the way an "integration" should work.

 

How the Slack API works

I'm not going to get into the Incoming Webhooks setup too much except for the fact that Slack gives you a "hooks.slack.com..." URL to POST to using your Marketo Webhook and Slack handles the rest, basically as a static message in Marketo.

 

incoming-webhooks-post.png

Incoming Webhooks post with a whole chunk of formatting in text field and "ok" response from Slack

 

Now, using the Slack API to post a message allows you to specify which channel to post to in the payload along with the opportunity of adding interactive components like buttons, menus and (quite recently) custom actions. This is how it flow of data looks like:

 

 

slack-marketo-flow-of-data.png

Payload, Slack post and Response using API

 

 

What's interesting about this setup is that when Slack receives the data it responds with the whole message and some other parameters like the timestamp/id (ts) of the message, that can be mapped to a Marketo field in the webhook's settings. The ts value would allow Marketo to interact with the original message, for example adding a thread comment with more data:

 

 

thread-comment-slack.png

 

Creating your own Slack app

What you'll need for this setup is to create your own Slack app and the great thing is that you can keep it in your internal workspace. Once your app is created, what you'll need is to set up is a bot user + permissions to post using a Bearer token in the header of your posts.

 

I have covered a detailed guide on this part here: Configuring a Slack app for use with Marketo

 

Posting using the Slack API

With all app settings ready, the app will be able to post to Slack through its bot user. This is basically the same as a normal Slack user posting, the bot needs to be invited to the channel it posts in and the channel ID needs to be specified in the payload as attachments.

 

The two part post from above is created using two webhooks and a wait step where the ts value is used to refer to the first webhook's posted message:

 

 

two-part-webhook.png

Using Marketo for formatting data

 

For those interested, I have put together a detailed guide on structuring webhook posts: Structuring Marketo webhooks to post via Slack API

 

It's quite easy to get into a disaster use case of either having (1) too much text in alerts with default values or (2) creating 20 different webhooks. Marketo knows what data is available and can be told what to actually post before calling a webhook.

 

One method that works quite well is creating a webhook template that is tokenized and defines all relevant data on the program / campaign level:

 

 

slack-payload-template-1.png

 

This webhook defines the Slack Channel ID and the title/pretext of the message using My Tokens and uses a custom field called Slack_Contact Details for preparing data before posting to Slack by running through a whole list of Change Data Value flow steps with choices:

 

 

Slack-post-flow-steps.png

 

What this can translate to in Slack is either using one webhook for multiple types of posts or simply removing fields when they're empty:

 

comparison-two-different-posts.png

 

Interactive components and passing data back to Marketo

When first testing this, I was tempted to use one button next to MQL alerts, but it seemed a bit risky if people get tempted to press it. Instead I opted for putting in a bit more work and adding a menu with three different choices to start: Disqualifying, Adding as contact (claiming) and Creating a deal/opportunity.

 

Adding interactive components to Slack requires a URL for Slack to post to. Contrary to "hopeful beliefs", you can't really configure so much from Slack's end and it's up to you to decide what to do with the data. This underlying process of sending data back to Marketo is configured with a tool called Integromat that I personally prefer over Zapier. Both tools work great if you're not very technical and posting to your own server.

 

How this type of setup looks like:

Slack-Qualification.gif

 

 

Underlying workflow for passing data back to Marketo

 

Integromat's webhook URL is added in the Slack app's settings and once a request is made, the JSON is parsed to grab the important values:

 

  • The ts value for updating the originating message
  • The action value from the drop-down menu for sending to Marketo
  • The lead's attributes for knowing who to update
  • The ID of the Slack user who took action to know who claimed/disqualified the lead

 

api-workflow-slack-marketo.png

The integromat scenario for receiving data from Slack

 

 

Integromat authenticates through the Marketo REST API and receives an authentication token. The lead's information is retrieved from Marketo using the token and Integromat syncs the data (points above) on the lead. After this is done, the originating message is updated with three different values based on what the action was that mentioned (1) What the action was, (2) Who took an action (3) Who the lead was.

 

For a more detailed guide on this part, I wrote up a post here: Sending data back to Marketo from Slack

 

 

marketo-triggered-workflow.png

 

Once Marketo receives the data, this triggers flow steps to update the revenue cycle stage along with details on the lead owner before running more actions to sync the lead to CRM and as a final step... Comment on the original slack message's thread mentioning the user and attaching a link to CRM to the Contact or Opportunity depending on what was chosen - in best case scenarios this takes 15 seconds to run through the whole flow.

 

I hope this was insightful and helpful for anyone interested in building something similar!

 

Best,
Erik

Hey, #MKTGnation!

 

Summer's (kind of?) over, the PSLs are flowing, and the gang got back together to answer the top questions we hear every day on the job. I may or may not have ranted just a little.

 

Some of my personal favorites include:

  • Why is Marketo broken? (ie: the one that makes my eye twitch)
  • How mature is my Marketo instance?
  • Why does it take so long to change a template? (spoiler: we have different definitions of "templates")
  • Do I actually know how to troubleshoot? (Okay, this one isn't a real question but we cover why it's crucial to understand troubleshooting in our jobs)

 

 

What are the most common questions YOU receive about Marketo (or your job)? Are there common ones you've been able to stop from popping up time and time again? Any pet peeve questions?

 

Sydney Mulligan Enrico Deleon Juli James

3rd and final part of this series!

 

Building nurture programs can be a daunting task. But with the right guide, you can turn an afternoon into an email experience your prospects will never forget! Before we begin, we need to define a few terms:

 

  • An Engagement Program is a specific kind of program that allows a marketer to send content to a specific audience based on an ongoing basis.
  • A stream is a category of content that lives within an Engagement Program. Marketo users can set up rules to tell an Engagement Program which stream members of their audience should be in.
  • Casts occur when Engagement Programs send content to a qualified audience within a nurture stream.
  • In an Engagement Program, each stream has a cadence. The cadence is the predetermined schedule for each cast.


If you only have one Engagement Program, this will be relatively simple. But don’t fear, if you plan on having multiple engagement programs, we’ll also walk you through the process of setting up a Traffic Controller so you can manage all of your nurture subscriptions in one place. Let’s start by building our first nurture program.
First, we need to define a few components of our Engagement Program:

  • Who are we emailing?
  • When/how often are we emailing them?
  • What are we emailing them about?
  • Bonus: What is the journey we want to walk them through?


Now we can start building! In this example, we’ll answer these questions with the following sample information.

  • Who are we emailing? People in our Lead Lifecycle
  • When/how often are we emailing them? Once a week, on Wednesdays at 9am
  • What are we emailing them about? Our brand, based on their place in the Lead Lifecycle
  • What is the journey we want to walk them through? The buyer journey: from TOFU to BOFU

 

To start, create an Engagement Program. For a detailed setup process, see Marketo’s Engagement Program implementation guide.

 

Within this program, create a new Email Send Default Program for each email that will live in the nurture program. Each Email Send program should have the following assets:Screen Shot 2018-09-07 at 3.15.19 PM.png

 

Sometimes, it will be necessary to prevent certain people from receiving emails within a stream. For example, if John Doe has already downloaded the Education Whitepaper, he doesn’t need to get the Education Email pointing to that whitepaper. Here’s how to keep John from receiving that email.

 

Find the Default Email Program Channel in the Admin section. Edit this channel by adding a “Nurture Excluded” program membership status:

Screen Shot 2018-09-07 at 3.15.37 PM.png

If a lead is already a member of a nested program, Marketo will skip that program and go to the next one in the stream. We will use this fact to exclude John Doe from the Education Whitepaper send.

In each nested program, add an _Excluded Smart Campaign.

Screen Shot 2018-09-07 at 3.16.39 PM.png

The Smart List of the _Exclude campaign identifies anyone who should be excluded:

Screen Shot 2018-09-07 at 3.17.18 PM.png

 

By making viewers of this assets members of the nested program, they will be excluded from this email:

Screen Shot 2018-09-07 at 3.17.45 PM.png

 

And that’s it!

 

 

Setting up multiple engagement programs? Consider building a Nurture Traffic Controller to help leads get the right content.

Create an operational Program - this will be your Nurture Traffic Controller. In this program, build a Smart List with which you will define your Nurture Target Audience. This generic list should include any leads who qualify for any Engagement Program. Think marketable leads.

 

Additionally, create a new Smart List for each Engagement Program target audience. For example, an Engagement Program targeting software companies might have a target Smart List for leads with Software as their industry.

 

A new Smart Campaign will add new qualified names to the correct nurture program:

Screen Shot 2018-09-07 at 3.18.14 PM.png

 

To build the Flow, reference the the Smart Lists for each nurture target audience to tell Marketo which Engagement Program to use.

Screen Shot 2018-09-07 at 3.18.33 PM.png

 

Schedule this to run regularly before each nurture cast.

 

Sometimes, our nurture strategies rely on having sparsely-populated data. Think about our industry example. If Jane Doe is added to the system without an industry, she would go into a generic Engagement Program. But two months later, when her industry is identified as Software, we want to add her to the Software Engagement Program.

 

First, define transition rules: what criteria determine whether someone is qualified for a new stream? Luckily, we already defined this earlier, when we built our Engagement Program target audience smart lists! These can be used to migrate leads into the correct nurture programs.

 

Screen Shot 2018-09-07 at 3.18.51 PM.png

Screen Shot 2018-09-07 at 3.18.55 PM.png

 

What is going on in that first flow step?

 

The Smart List referenced in Choice 1 determines whether someone is in a different Engagement Program already. If they are, we need to pause them! Here’s how to know:

Screen Shot 2018-09-07 at 3.19.28 PM.png

 

Schedule the Smart Campaign to run on the same schedule as the first campaign.

 

Now your traffic controller is complete, and you can rest assured knowing your leads are getting relevant content.