In our previous article, we talked about how an Agile RevOps approach could help ops teams drive continuous improvements in both their analytics and data quality (instead of massive ‘data foundation’ rebuilds).

In this article, we’ll share the story of a Truly customer who compressed 6 months of RevOps work into 3 weeks, without any major process changes or involvement from the sales team.

Analysis Objectives

The customer was hoping to better understand at what stage of the funnel their Sales Engineers were first joining calls.  The goal was to understand if the reps were following the documented process and what happened to win rates when they didn’t.  This would then power enablement to drive desired behavior changes by proving the process’s value with data.

Analytics Configuration

The customer used Truly Sales Process Optimizer to configure a ruleset that would:

  • Go back in time to deals starting at a specific date
  • Find the first Meeting Task in the deal history which had a Sales Engineer On It
  • Stamp the deal stage of this Task on the Opportunity

With these stamps, it would be easy to run a report that would show both which stages reps joined and then break them down by win/loss status in reporting.

 

Attempt #1: Incorrect User Profile IDs

Problem: when running the analysis, the customer used User Profile IDs to identify whether users assigned to tasks were in fact ‘Sales Engineers’. The first analysis run showed that some data was labeled in 15 digit Salesforce IDs while others were 18 digits, making the JOIN logic incorrect.

Action:

  • The issue was identified in the Truly SPO debugger in Salesforce which showed where the rule was failing
  • The customer’s process rule was updated with 3 clicks to use a ‘contains’ comparator instead of ‘equal to’
  • Re-run analysis with 1 click

 

Attempt #2: Missing Data

Problem: the customer found that not all of the Sales Engineers had set up their activity tracking correctly, which meant that the count of ‘first meeting joined’ stages was too low.

Action:

  • Fixed the configuration of the tool they used to track web meetings
  • Fix their onboarding process to ensure the integration to zoom was set up correctly
  • Created a report that would proactively monitor integration health
  • Re-run analysis with 1 click

 

Attempt #3: Wrong Date Field Choice

Problem: the customer found that the stages being selected by the software weren’t lining up with what was being seen in the Activity history.  It turns out that they were using the ‘Date Last Modified’ field for their analysis because they couldn’t use ‘Date Created’, since a separate ops projects did a bulk ETL that created historical tasks at a much later date.  It turns out that either users or some of their prior software had made bulk changes to some tasks that updated the ‘Last Modified’ time.  They found that of all the date fields available, the ‘Date Completed’ field was the most accurate.

Action:

  • Swap out the field used in the analytics configuration
  • Re-run analysis with 1 click

 

Attempt #4: Bad Opportunity Stage Data?

In the third analysis run, the customer finally got data volumes that made sense and aligned with what they saw on the opportunities that they QA’ed the results against.

Problem: the results were fascinating.  Either…

  1. The sales engineers followed the process <10% of the time, which was that they were supposed to come in at Stage 4 of the process AND whenever they did follow the process, they lost 100% of deals. OR
  2. Their reps weren’t updating Opportunity stages in a timely way so that most of the Tasks that were created were being mislabeled as an earlier stage than they first thought.

It turned out that #2 was the case.  Apparently a validation rule had been built into Opportunities that required some information that could not be obtained until later in the deal cycle, and because this field could not be filled, AE simply didn’t move the deals forward.

Action:

  • Remove the validation rule from opportunities
  • Automate sales stage progression — using Truly Activity Tracking signals, they managed to automate a number of sales stages so that as different personas joined calls and different topics were discussed, deals would automatically move to the right stages.
  • Rewrite historical data — with an automation for progressing sales stages, the customer now had an algorithm that could be applied to deal data retroactively.  So they simply created a new no-code sales process in Salesforce >> ran it against their historical deals and updated a shadow ‘true pipeline stage’ >> compared it to the original field.  Once they were happy with the results, they updated the process to update the historical deal stages on their Tasks so that all of their reporting would ‘automatically’ be caught up.

 

Customer Conclusion:

We asked the customer what their takeaway was after running this experiment.  Here’s what they had to say…

Notice that the hero of this story wasn’t Truly… it was actually the Agile RevOps process!  Truly was just the catalyst for making an iterative process possible by removing the frictions that sales analytics normally entail.  Instead of doing a complex,  multi-step ETL process (pulling reports >> exporting to CSV >> Running complex lookups/data transformations >> reupload back to SFDC through data loader) the entire analytics process was run in a single place with just a few clicks!

Interested in learning more?  You can either talk to our sales team or signup for our FREE Data Operations for RevOps course.