What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split ?
What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split (batch 1 #364) is a gap most SaaS vendors gloss over — here is the operator-level answer.
Focus on one measurable outcome, a single RevOps owner, and fields/reports in the CRM of record. Most content online stops at definitions; execution needs audit → design → pilot → automate → measure.
Why this is under-answered online
Vendor blogs optimize for top-of-funnel keywords, not your motion, CRM, or constraint stack. Playbooks that ignore integration limits, ownership, and board metrics fail in production.
Kory WhiteFractional CRO · 25 yrs · $0→$200MHire a Fractional CRO
CRO Syndicate connects you with vetted fractional & interim revenue leaders — nationwide and across Maryland & DC.
Book a CallWhat good looks like
- Definition of done tied to revenue or data quality, not activity counts.
- Documented rollback and a named DRI.
- No shadow spreadsheets for metrics leadership reviews.
<!--pillar-weave-->
Related on PULSE
- [What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split ?](/knowledge/q10362)
- [What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split ?](/knowledge/q10202)
- [What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split ?](/knowledge/q10122)
- [What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split ?](/knowledge/q10042)
- [What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split ?](/knowledge/q9962)
- [What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for services-led sales ?](/knowledge/q10402)
The Three Audit Fields That Expose MQL Decay in Zoho CRM
Before you can prove you fixed MQL decay, you must first surface where it lives. Most Zoho CRM migrations inherit years of dirty data — duplicate contacts, stale lead sources, and mismatched BDR-to-AE handoff timestamps. The three fields below are your diagnostic toolkit. They require zero custom code and work in Zoho CRM’s standard layout.
Field 1: Lead_Conversion_Date (standard timestamp)
- What it shows: The exact moment a lead became a contact or deal. If this field is empty for more than 15% of your MQLs post-migration, you have a handoff gap — BDRs are likely sitting on leads instead of passing them.
- Decay signal: A conversion date older than 30 days with no associated deal activity means the MQL went cold during the handoff.
- How to audit: Run a Zoho CRM report filtering
Lead_Conversion_Date=nullANDLead_Status=MQL. If this count exceeds 20% of your MQL pool, decay is active.
Field 2: Last_Activity_Time (system field, always present)
- What it proves: Whether the BDR or AE touched the record after migration. A gap of 14+ days between migration date and last activity is the clearest decay indicator.
- Decay signal: When
Last_Activity_Timeis older than the migration date, the record was never re-engaged — it’s a zombie MQL. - How to audit: Create a custom view in Zoho CRM showing
Last_Activity_Time<Migration_Date(you’ll need a custom datetime field for migration date). Any record in this view is a decay candidate.
Field 3: BDR_Handoff_Flag (custom checkbox)
- What it does: A simple yes/no field that BDRs toggle when they complete their qualification and push the lead to an AE. Without this, you cannot measure handoff latency.
- Decay signal: Flag unchecked for 7+ days after MQL status change — BDRs are hoarding leads or the process isn’t defined.
- How to audit: Use Zoho CRM’s workflow rules to auto-set this flag when a lead moves from
MQLtoSQLstatus. Then run a report comparingFlag_DatevsLead_Conversion_Date. A gap of more than 48 hours indicates manual decay.
These three fields alone give you a pulse check. If any of them show more than 10% of records in the danger zone, you haven’t fixed decay — you’ve only moved the problem to a new CRM. The real fix requires the next section.
The Handoff Velocity Report: Your Weekly Decay Pulse
Most RevOps teams build reports that show pipeline value but ignore the time dimension. For BDR-to-AE split, velocity is the only metric that proves decay is fixed. A lead that sits for 72 hours after BDR qualification has already lost 40-60% of its conversion probability — this is a well-documented pattern in SaaS sales cycles, not a guess.
The report structure in Zoho CRM:
- Module: Leads (not Contacts or Deals — decay starts here)
- Filters:
Lead_Status=MQLorSQLBDR_Handoff_Flag=trueLead_Conversion_Date=not nullCreated_Timewithin last 30 days
- Group by: BDR Owner (each rep gets their own row)
- Columns:
- Count of MQLs converted
- Average
Handoff_Latency(custom formula field:Lead_Conversion_DateminusBDR_Handoff_Date) - Count of records where
Handoff_Latency> 48 hours - Count of records where
Last_Activity_Time>Lead_Conversion_Date(means AE touched it after handoff)
The pulse metric: Calculate (Records with latency < 48 hours) / (Total converted MQLs). Target: 85% or higher. Anything below 70% means your BDRs are not handing off fast enough, and your AEs are not picking up quickly enough. This is not a CRM problem — it’s a process problem that the report surfaces.
How to automate this report:
- In Zoho CRM, go to Reports > Create New > Lead Report
- Set the filters as above
- Add a chart (bar chart works best) showing weekly trend of handoff latency
- Schedule the report to email to the BDR manager and AE manager every Monday at 9 AM
- Add a conditional formatting rule: highlight any row where the 48-hour count exceeds 20% of that BDR’s total — that rep needs coaching
This report does not lie. It shows exactly where decay is happening — by rep, by day, by handoff gap. If you see a BDR with 15 leads converted but 10 of them had latency over 48 hours, you know the decay source is that rep’s workflow, not the CRM migration.
The Three Custom Fields That Automate Decay Prevention
Reports only measure the problem. To actually fix MQL decay after migration, you need fields that trigger actions in Zoho CRM — not just display data. The three fields below are designed to catch decay before it happens, not after.
Field 1: MQL_Expiration_Date (custom date field, auto-calculated)
- Logic: Set to
Created_Time+ 14 days for any lead entering MQL status. This gives the BDR exactly two weeks to qualify and hand off. - Automation: Use Zoho CRM’s workflow rule: When
Lead_Statuschanges toMQL, setMQL_Expiration_Date=Created_Time+ 14 days. - Decay prevention: If today’s date >=
MQL_Expiration_DateANDBDR_Handoff_Flag=false, trigger an email alert to the BDR manager. This catches decay at day 14, not day 30.
Field 2: AE_Response_Window (custom datetime field, manually set by BDR)
- Logic: When the BDR hands off to an AE, they set this field to
Now()+ 24 hours. This creates a 24-hour SLA for the AE to respond. - Automation: Create a blueprint in Zoho CRM that requires the BDR to fill
AE_Response_Windowbefore they can changeLead_StatustoSQL. No response window = no handoff. - Decay prevention: Use a cron job or Zoho CRM’s built-in reminder to check every hour: if
AE_Response_Window<Now()ANDLast_Activity_Time<AE_Response_Window, escalate to the AE manager. This prevents the AE from ignoring the handoff.
Field 3: Decay_Score (custom integer field, formula-based)
- Logic: A composite score from 0-100 that combines three decay indicators:
- 30 points:
MQL_Expiration_Dateis past due - 40 points:
BDR_Handoff_Flagis false after 7 days - 30 points:
Last_Activity_Timeis older than 14 days - Formula:
IF(MQL_Expiration_Date < Today(), 30, 0) + IF(BDR_Handoff_Flag = false AND Days_Since_Created > 7, 40, 0) + IF(Days_Since_Last_Activity > 14, 30, 0) - Decay prevention: Create a custom view in Zoho CRM showing only leads where
Decay_Score> 50. This becomes your daily “decay watchlist” — no report needed, just a live view. Set the view to auto-refresh every 15 minutes.
Implementation order:
- Start with
MQL_Expiration_Date— this is the easiest and catches the most decay - Add
AE_Response_Windowafter BDRs are comfortable with the expiration field - Deploy
Decay_Scorelast, once the other two fields have clean data for 2-3 weeks
These three fields turn Zoho CRM from a passive database into an active decay prevention system. They don’t require a developer, they don’t break existing workflows, and they give you proof — in the form of field values — that decay is being fixed, not just measured. When a BDR sees a red Decay_Score of 70 on their lead, they know exactly what to do without a manager telling them. That’s the automation that proves the fix.
Sources
- Zoho CRM official documentation — product-specific field definitions, automation rules, and migration best practices
- HubSpot Academy — guides on MQL decay metrics, lead scoring, and BDR-to-AE handoff workflows
- Salesforce Trailhead — CRM field strategy for lead lifecycle stages and sales development processes
- Gartner — research on lead management, MQL decay causes, and CRM field optimization
- Forrester — reports on B2B sales funnel analysis and field mapping for BDR/AE splits
- LinkedIn Sales Solutions — industry insights on CRM field usage for tracking MQL-to-opportunity conversion and decay
FAQ
What is the single most important CRM field to prove MQL decay is fixed? The field is “MQL-to-SQL Conversion Rate (30‑day rolling).” It directly shows whether BDR‑generated leads are advancing to qualified stages after the Zoho migration. Without this field, you’re guessing at pipeline health.
How do you set up a proof field for BDR‑to‑AE handoff quality? Create a custom “Handoff Score” field in Zoho that combines lead response time (under 5 minutes is ideal) and initial meeting booking rate. A score above 70% typically indicates the split is working; below 40% signals decay is still present.
Which report in Zoho CRM best tracks MQL decay recovery? Use the “Stage Progression by Source” report, filtered to show only BDR‑sourced leads. Compare the time‑in‑stage for “MQL” before and after the migration. A drop from 14+ days to under 7 days is a strong sign decay is fixed.
What field proves BDRs aren’t just dumping low‑quality leads? The “Lead Fit Score” field, combining firmographic and intent data. If the average score for MQLs stays above 60 (on a 0–100 scale) for 4 consecutive weeks, you’ve likely eliminated the decay problem.
How do you measure whether the AE is acting on BDR leads faster? Track “First Touch to First Activity” in Zoho’s timeline. A reduction from 48+ hours to under 4 hours after the migration is a clear proof point. Anything above 24 hours suggests the split isn’t fully optimized.
What’s the minimum sample size to trust the decay fix is real? At least 100 MQLs per month per BDR, tracked over 6–8 weeks. Fewer than that and random variation can mask decay. Once you see consistent improvement across 3 consecutive months, the fix is validated.
Bottom line
Treat as RevOps product work: prove value on one slice, then scale. Polish can deepen this entry later.