Skip to main content

Tracking real sales conversion rates for cold leads using Zoho Reports + Zoho CRM


The Zoho Reports team helped me out with a tricky report to show the lead to won potential conversion rate. To explain the report, let's consider this scenario:
1. The business had 1000 leads entered into the CRM through telemarketing
2. Salespeople then qualified those leads and converted 50 of them to opportunities
3. The sales team then closed 10 of those leads

Based on those stats, we'd expect the lead to won potential win rate to be 1% (10/1000). In the default Zoho Reports conversion stats, you can only see potential to closed potential conversion rates. This stat is misleadingly high (10/50 = 20%) because it's only considering converted leads and ignoring junk/lost leads.

If the sales team really closed 20% of cold leads, you would probably see them usurping Brian Tracy on the speaking circuit. In reality, they're decent (1% conversion) but not world beating. I don't know about you, but I prefer to deal with reality.

How to generate true conversion rate stats using Zoho Reports
Courtesy of Anand and the amazing Zoho Reports CS team.

1. Set up a new query table using this query:
SELECT
l."LEADID",
l."Lead Source",
l."Created Time",
l."CONVERTED",
s."Stage",
s."Forecast Type"
FROM  "Leads" l LEFT JOIN "Sales" s ON l."LEADID"  = s."LEADID"  
2.  Set up a new report based on that table
I've used aggregate formulae as well:
e.g Won Potentials = countif("Sale Conversion"."s.Forecast Type"='Won')

Comments

  1. Hi Jeremy,
    Is this still relevant?

    I've created the report using the same query but am unable to find the fields you have on the 'Data' side: "Converted Leads Count", "Won Potential' & "Lead to Won Potential %"

    Can you help?

    Regards,
    Julien

    ReplyDelete
  2. Hi Julien,
    those are aggregate formulae,

    e.g. Converted Leads Count = countif("Sale Conversion"."l.CONVERTED"=1)

    ReplyDelete

Post a Comment

Popular posts from this blog

Getting current time in a specified timezone using Deluge script

Recently I was working on a custom function for Zoho CRM which required me to get the current time in a specified timezone. I assumed that zoho.currenttime would give me the time based on the timezone chosen in the organisation settings but discovered that it always gives it to you in PST. The Zoho Partner team gave me this snippet to solve the problem: current_time_in_timezone = zoho.currenttime.toString("yyyy-MM-dd'T'HH:mm:ss", "Australia/Sydney").toTime("yyyy-MM-dd'T'HH:mm:ss"); If you need the current date, do: current_date_in_timezone = zoho.currenttime.toString("yyyy-MM-dd'T'HH:mm:ss", timezone).toDate(); To figure out what you can put in for the timezone part, refer to https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

searchRecords with multiple criteria in Zoho CRM API

NB: this blog post is no longer relevant as API v2 lets you use searchRecords with multiple criteria :) I discovered something really cool tucked away in the Zoho CRM forums today. For the history, check out this thread . In summary, the searchRecords API task in Zoho CRM is impossible to use if you have multiple criteria and in general it's pretty annoying to get the single criterion right. In the forum thread, Zoho Support advised that you can actually use getRecords with a view name. This feature is not documented on the getRecords page at all but I can confirm it works:D This is really, really cool. It's going to make my life as a Zoho dev much easier! Instead of having to do something really inefficient and ugly like: leadRecords = zoho.crm.searchRecords("Leads","(Created Time|<|" + yesterday_date +")",fromIndex,toIndex); for each ele in leadRecords { lead_source = ele.get("Lead Source"); createTime=(ele.g

Debugging Deluge script in Zoho Creator/Zoho CRM

Deluge is a powerful language that simplifies a ton of things, e.g. database lookups. But I have to say, it's very painful to debug. Interpreting longish scripts takes ages, error messages are obtuse if they exist at all and even the hints in the IDE don't always help (ever tried using containsIgnoreCase based on the auto-complete suggestion?). Here are my tips for debugging code when it's not working. 1. Split your code up into small custom functions. Nothing's more painful than waiting 30 seconds for a really long (say 1000 lines) HTML page to save and only then get feedback on a syntax error. I've got a few apps that are like this and it's not fun to work with at all. I haven't seen any improvements in the compile speed over the last few years, so my conclusion is that it's always best to write most of your logic code as small custom functions and then build that up in the HTML page so that you'll get quick feedback on syntax errors. 2. If