Removing Friction Between Feedback And The Customer

We want to know what our customers think of our product because we count on it! To make receiving that feedback as easy as possible, we built a command right into Woobot.

The moment our customers craft a loving note of advice, our service bot, FeedbackBot, springs into action.

She delivers 3 critical functions for you right out of the gate:

  1. Users can execute a simple /woobot-feedback to share their thoughts with our team.
  2. FeedbackBot then alerts our team within Slack that a user has dropped us some feedback, along with key data points such as the date/time, the message itself, and the user’s email.
  3. FeedbackBot then creates a Case in our Salesforce Org, and this is where things interesting. Now our customer operations team, which monitors the Feedback Queue, can assign follow-up tasks as needed!

Getting Here Wasn’t Easy

In a traditional setup, each action works in a chain and passes information on to the next. As systems evolve, changes to the middle of the chain threaten functionality down the line.

What we quickly learned in developing FeedbackBot is that we wanted her to extend the workflow actions that occur without interrupting or threatening the existing actions.

We wanted her to be fast and nimble. This meant we needed an architecture that guaranteed each action received it’s own source data.

By adapting a hub-and-spoke architecture, we keep the entire process strong by having each function source data directly without any dependencies on other functions.

A Better Solution

Our solution uses AWS Simple Notification Service (SNS). The /woobot-feedback command is handled by an AWS endpoint that passes the entire Slack payload to SNS and quickly responds to the Slack user with a thank you message.

Each workflow action is handled by an AWS Lambda Function that is triggered by SNS. Since they subscribe to the SNS topic independently, they all receive the payload simultaneously and in parallel. If function A drops the ball and crashes, it has no affect on function B or C.

Roll Your Own FeedBackBot!

We’d like to give you exactly what we use to gather customer feedback directly from Slack. Here are our own personal blueprints on how to build a FeedbackBot of your very own.

We have broken this down into four parts:

  1. Responding to a  Slack Command
  2. Publishing to SNS from a Slack Dialog Submission
  3. Subscribing to SNS for Slack Notifications
  4. Subscribing to SNS for Salesforce Cases

Publishing To SNS From Slack Dialog

Create Your API Gateway And Lambda Function

Follow this tutorial in order to:

  1. Create an AWS Account.
  2. Create an API Gateway.
  3. Create a Lambda Function.

Create Your SNS Topic

Follow this tutorial in order to:

  1. Create an SNS Topic.
  2. Call the SNS topic “Feedback-Alert”.

Construct Your Slack App And Command

Follow this tutorial in order to:

  1. Create a Slack App.
  2. Add a Command.

Create Lambda Function To Respond to Slack Command

When a user sends the command /woobot-feedback your app will receive a payload at the URL defined by the Slash Commands section of your Slack app. Our Lambda function calls Slack’s dialog.open API endpoint. This opens a dialog to that user in specific response to the command issued. Once the user submits the dialog, Slack will send a payload to the URL indicated in the Interactive Components section of your Slack app.

For this function, use the slack_command_handler.py as provided in our github repo feedbackbot-dialog.

Create Lambda Function To Publish To SNS

Although the AWS API Gateway supports directly publishing to SNS, we want to add a step that verifies that the messages are coming from our application. Only verified messages will be posted to SNS. For this, we will use a Lambda function.

Create the function with no trigger, we will set it through the API Gateway in a later step.

Set the Runtime to Python 2.7, which is incidentally Woobot’s favorite language, and then name your function appropriately.

Create 2 environment variables, one for the verification token and one for the SNS Topic ARN.

Now deploy the code slack_dialog_handler.py from our github repo feedbackbot-dialog

Map Your API Gateway Endpoint To Your Lambda Function

The last step for this function is to map the API Gateway endpoint. Choose the endpoint that you created earlier for the slack command tutorial, and for the POST method choose the option for a Lambda Proxy Integration. The proxy option greatly simplifies the parsing of incoming and outgoing data. Select your region, and set the Lambda Function to the newly created feedbackbot-slack2sns.

 

Congratulations! This is big milestone. Your customers’ feedback is being published to SNS.

Relax and stretch a minute.

Now For The Fun Part

Now that we are publishing user feedback requests to our SNS topic, we can drop in as many subscription services as we like. Let’s start with 2:

  1. Notify our Slack team that a user has feedback.
  2. Create a Salesforce Case for each feedback message.

Subscribing To SNS For Slack Notifications

It’s time to get this bot involved in your Slack teams. Strap in!

Create Incoming Webhook

We need a notification URL to your Slack team. Create this using the Slack Custom Integrations: Incoming WebHooks. Here is a direct link to the new incoming-webhook page.

Feel to use any name or emoji that fits your team. Make note of the webhook URL, we will need it in the next step.

Create Lambda Function

Next, we deploy a Lambda Function that triggers from the SNS.

Set the Runtime environment to Python 2.7.

Save the Slack incoming webhook URL as an environment parameter named FEEDBACK_SLACK_URL. You will also need a few additional variables that define which channel the feedback should appear, the name of the bot and the emoji. You can use these values as an example.

Leave the handler name defaulted to lambda_handler.lambda_handler and create a new role. This function does not need any special permissions beyond the standard default.

Now deploy the code sns2slack.py from our github repo feedbackbot-dialog.

Subscribing To SNS For Salesforce Cases

There are at least 2 ways of securely connecting your Lambda function to your Salesforce org:

  1. Username/password/security token.
  2. OAuth2.

For prototype simplicity, we will cover the username/password approach, but we highly recommend using OAuth2 when connecting to a production environment.

Time To Forge The Lambda Function

Let’s deploy a Lambda Function that triggers from the SNS. For this function, we need to store the Salesforce credentials in environment variables.

Next, we deploy a Lambda Function that triggers from the SNS.

Set the Runtime environment to Python 2.7 as above and name the function Feedbackbot-sns2sfdc.

Connecting Using Username/Password

Store the username, password, and security token in 3 environment variables on the Lambda Function. Name the variables SFDC_USERNAME, SFDC_PASSWORD, and SFDC_SECURITY_TOKEN.

Now deploy the code sns2salesforce.py from our github repo feedbackbot-dialog.

For this function, we use the simple_salesforce python library. Since the function includes multiple files, we recommend installing the function using the included deploy.sh shell script which automates the creation and upload of a zipfile. Note that you will need to update the deploy.sh script with the Lambda Function’s ARN.

Now You Hold The Power

Now that you’ve created your own bot for customer feedback, you’ll be able to drop your development cycles into overdrive. We’ve given you a model that can extend those workflow actions quickly and without breaking anything.

Take what we’ve given you and make some magic of your own. Your customers’ feedback should be at the core of your product development process.