SOLVED

Transition Rules Not Working in Revenue Cycle Model

Go to solution
Highlighted
Anonymous
Not applicable

Transition Rules Not Working in Revenue Cycle Model

We recently noticed an issue with our Revenue Cycle Model not moving people through the different stages correctly based off of the transition rules. This issue only occurs when a lead progresses very quickly through the different stages. 

Screen Shot 2018-02-27 at 12.07.09 PM.png

For example, last week we had a lead that hit all of the necessary qualification steps to transition from a Known Lead to an SQL in an hour or so. We are using lead scoring to transition leads from Known to Engaged (Engaged = a Lead Score of 25 - 50) and Engaged to MQL (MQL= a lead score of 50 and above). The lead hit the necessary lead score of 50 to become an MQL which generated an alert to my sales rep, but when I looked in the Revenue Cycle Model, the lead never transitioned out of the Known Lead Stage, even though I can see that the lead hit the lead score of well above 50. Any ideas of why the lead did not change Revenue stage even though it hit the transition rule requirement?

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Level 6 - Champion Alumni

Re: Transition Rules Not Working in Revenue Cycle Model

Hey Courtney,

I understand the RCM to transition to the latest stage that it qualifies for. So my assumption here is that the score went straight from 0 to +50. In this scenario, even though the "Engaged" stage criteria was met, the MQL criteria was met as well and RCM bypassed the Engaged and moves it to the furthest true progression.

Again, if you wanted to have the record go through the "Engaged" stage, you would have to break your scoring into 2 parts. +25 to get them into engaged, and then +25 again to MQL.

At the end of the day, you want to track the number of people moving from one stage to another..,... so I would just add another transition action that goes from Known, directly to Engaged. This will account for the 0 -> +50 scenario without needing to have the scoring run in 2 parts. This still doesn't mean that the record will show as having gone through your "Engaged" stage but you can still report on the number that go through that transition.

Here is an example where our records go straight from Raw Contact to MQL, bypassing Warm Contact. The transition rule at the top accounts for these scenarios.

Screen Shot 2018-02-27 at 4.13.03 PM.png

In summary, you really should have a transition action for for any possible scenario or path that a record can take. For you, that is from Known to MQL.

View solution in original post

8 REPLIES 8
Highlighted
Level 6 - Champion Alumni

Re: Transition Rules Not Working in Revenue Cycle Model

Hey Courtney,

I understand the RCM to transition to the latest stage that it qualifies for. So my assumption here is that the score went straight from 0 to +50. In this scenario, even though the "Engaged" stage criteria was met, the MQL criteria was met as well and RCM bypassed the Engaged and moves it to the furthest true progression.

Again, if you wanted to have the record go through the "Engaged" stage, you would have to break your scoring into 2 parts. +25 to get them into engaged, and then +25 again to MQL.

At the end of the day, you want to track the number of people moving from one stage to another..,... so I would just add another transition action that goes from Known, directly to Engaged. This will account for the 0 -> +50 scenario without needing to have the scoring run in 2 parts. This still doesn't mean that the record will show as having gone through your "Engaged" stage but you can still report on the number that go through that transition.

Here is an example where our records go straight from Raw Contact to MQL, bypassing Warm Contact. The transition rule at the top accounts for these scenarios.

Screen Shot 2018-02-27 at 4.13.03 PM.png

In summary, you really should have a transition action for for any possible scenario or path that a record can take. For you, that is from Known to MQL.

View solution in original post

Highlighted
Champion Moderator

Re: Transition Rules Not Working in Revenue Cycle Model

you weren't lying when you say "EVERY POSSIBLE..." -- impressive spaghetti chart.

Highlighted
Level 6 - Champion Alumni

Re: Transition Rules Not Working in Revenue Cycle Model

I do love spaghetti JD Nelson​!!! haha

Highlighted
Level 10 - Champion Alumni

Re: Transition Rules Not Working in Revenue Cycle Model

Do you guys actually use transition rules - especially for a revenue model like Keith's?  We always recommend ditching the transition rules and instead use smart campaigns to properly define lead stage progression, detours, fast-tracks, etc.  Way more flexible and easier to customize - and a lot more control.

Highlighted

Re: Transition Rules Not Working in Revenue Cycle Model

+1 on Dan here. And also easier to debug, sicne you have access to the Smart campaign "results" tab.

-Greg

Highlighted
Anonymous
Not applicable

Re: Transition Rules Not Working in Revenue Cycle Model

Thanks everyone for your help! Yes, we are currently using the transition rules to move people from one stage in the model to the next, but we haven't found them to work that well. So we will definitely try transitioning to smart campaigns instead.

Highlighted
Anonymous
Not applicable

Re: Transition Rules Not Working in Revenue Cycle Model

Thanks Keith, that is vey helpful. The one part that still confuses me though is that the revenue stage never changed away from Known, even though the score hit 50+ so not only did it not move to Engaged, but it never made the move to MQL either.

Highlighted
Level 2

Re: Transition Rules Not Working in Revenue Cycle Model

Hi Courtney, the only way your lead can move out of Known is if it meets the specific qualifications to move to Engaged. People in the model will only follow the arrows along the path to the next stage...not necessarily the next stage they qualify for. You need to define a detour to another stage (Known => MQL if score >50). Like Keith, we had to add a good number of detours to match the way people actually move through our database.