2 Replies Latest reply on Nov 3, 2015 2:47 PM by ed93c14fdffd8134a452cf4347e928152ff61e72

    Tracking Touches for SDR Team

      We'd like to implement an automated way to track how many touches (emails, calls, messages) a lead gets from an SDR (sales development rep - outbound rep). We're thinking it would be best to create a field that has a counter (either a dropdown or text field) that will track the number of touches. This field will then get automatically updated when activities are logged following a standardized naming convention. So things like CALL, LM, EMAIL will trigger that number to update.

       

      Has anyone done this through Marketo before? Or is there an easy way to do it with Salesforce?  Would love to get some insights on how other organizations are tracking touches for outbound sales reps.

        • Re: Tracking Touches for SDR Team
          Mark Farnell

          counting activities on the contact or lead record in SFDC isn't (to my knowledge) easy without using APEX/triggers.  We're experimenting with using a score field in Marketo that is triggered to increment  by 1 for every activity that contains "call" in the subject that is created while a lead is in MQL, with it resetting to 0 when the lead leaves MQL.  Might use it to count activities in "current status", so it would reset to 0 every time the status changed.  I'm also thinking about creating a second counter for email.  using a score field seemed the best way to go as it can be incremented.  The score field is created as a number field SFDC side first, then changed to a score field in MKTO when the field syncs over.  It would be useful if other fields from the activity were visible as a constraint on the activity is logged/updated trigger, but they don't seem to be in my instance.  Then you could use a picklist instead of relying on a naming convention.  Finally, longer term plan is to do this SFDC side anyway, since we want to accurately track the time an activity was performed (eg response time to web requests) against SLAs, but for now we're starting with the MKTO route as its easier to get something working before finding resource to help with the APEX.

          2 of 2 people found this helpful