Update deal stage via workflow triggered by email

[Andrew_S]

Hi all,

I’m currently working on a new Deals pipeline where I would like the Deal stage to update if/when an email reply is received from the customer.

This functionality is built into Tickets by default, and works well:

I have tried a few different workflows from scratch, and even cloned the built-in ones for Tickets to try and work off of, but no luck getting it to work exactly the same. One of the main hangups I’m having is with re-enrollment. Properties like “Number of email replies”, “Last email date”, or “Activity type: Email reply from contact” tell me they can’t be used for re-enrolling.

Based on my understanding and testing, this will prevent the increase in total replies or activity of new reply triggering the Deal enrollment after the first go around, thereby not working.

What I want to happen is:

-If a Contact replies to a Deal email thread

-Then that Deal goes to a “sales review” stage

And preferably the same for us:

-If we respond to the Contact’s email

-Then Deal moves to “offer sent”

This particular pipeline involves some back-and-forth customizing and adjusting quotes. I really like how the email automation works in Tickets and was hoping to get the same process working for Deals.

Any ideas or suggestions on how to accomplish this?

[trevordjones]

Hi @Andrew_S ,

I’d like to change your thinking on using a Deal Stage to track this process, but I’ll save that for the end and explain how I would do what your are asking first.

First, build a dropdown property on the Deal record. Call it something like “Negotiation Status” or what I used “Offer Status.” It should have options for both “Offer Sent” and “Sales Review.”

Then, build two CONTACT Workflows with Event Triggers

The first will use the “email replied” trigger:

The second will use email sent as the event trigger instead of email replied.

This type of contact workflow will allow you to re-enroll the contact every time an email reply is received.

The branching logic checks to see that an offer was sent before it proceeds to but the deal into review. In this way, you don’t accidentially change the status on deals where the contact isn’t in active negotiation.

On the workflow that sets the first “Offer Sent” value, you’ll want a second filter group that allows the process to start, perhaps using the deal stage you are in when the first offer is sent.

I am using a dropdown select property “Offer Status” instead of a deal stage in case the workflow happens to update another deal associated with that contact that isn’t in negotiation. We wouldn’t want to change the deal stage of a closed won deal, for example.

I would stop here. More on that in a bit.

If you really want to change the deal stage, you can now build a simple deal based worflow based upon filter criteria.

I didn’t modify my deal stages to create this example, but I’m sure you get the idea.

Again you’ll need two. For your first offer sent stage, you may have another deal stage filter group, like:

Trigger:

Deal Stage is “Negotiation Starting” AND Offer Status is “Offer Sent.” OR Deal Stage is “Sales Review” and Offer Status is “Offer Sent.”

Action:

Set propery Deal Stage to Offer Sent

Which brings me to my final point: I would personally recommend using a property like this Offer Status property to track what you are tracking and not flipping the deal stage back and forth. Deal stages are meant to be a progression and shouldn’t flip-flop like this. What you are describing is a “Negotiation,” and that should be the name of your deal stage. You’ll only care aout the “Offer Status” field when deals are in the negotiation stage, and you can build your reports accordingly.

With that said, what I descibed above should work for you.