Knowledge Library · Reviews

Powered by Pulse — Value Added. The #1 source of truth in revenue operations. Find the bottleneck. Fix the pipeline. Win the quarter.

What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split in 2027?

📖 2,756 words🗓️ Published Sep 6, 2026

Direct Answer

You prove MQL decay is fixed after a Zoho CRM migration for a BDR-to-AE split with five fields: Lead Score Delta, Handoff Velocity, Disqualification Reason, BDR Engagement Count, and MQL Recycle Count. Track them weekly in one report — falling negative deltas, sub-4-hour handoffs, clean disqualification reasons, and low recycle counts together prove the split works, not vanity activity metrics.

Rent this Advertising Space

Need advice or a second look at your business?From a real Chief Revenue Officer.25 years as a CRO. Tell me where it is stuck and get a straight answer on the fastest fix.Show me →Kory White · Fractional CRO →

Work with Kory Hire a Fractional CRO LinkedIn Résumé

The two approaches to proving decay is fixed

There are really two competing philosophies for proving you fixed MQL decay, and most RevOps teams pick the wrong one first. The first approach is activity-based proof: count calls, emails, and meetings logged by BDRs and AEs, and assume more activity equals less decay. This is the default because it's the easiest to build in Zoho CRM — activity counts are native, require no custom fields, and show up in standard reports on day one. The problem is that activity volume doesn't correlate with lead quality or handoff speed. A BDR can log five emails in ten minutes to hit a quota while the lead sits cold for three days before an AE touches it. Activity-based proof looks good in a board deck and tells you nothing about whether decay actually stopped.

The second approach is state-transition proof: build custom fields that capture the exact moment a lead changes ownership, qualification status, or score, and measure the time and quality of those transitions. This requires more setup — five to seven custom fields, two or three workflow rules, and one consolidated report — but it's the only approach that isolates decay from noise. State-transition proof answers the actual question a CFO or VP Sales asks after a migration: "did the handoff get faster and cleaner, or did we just move the same problem into a new tool?"

What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split — figure 1

The trade-off is setup cost versus signal quality. Activity-based proof takes under a day to configure and produces a report within a week, but it's vulnerable to gaming — reps can inflate activity counts without improving outcomes. State-transition proof takes one to two weeks to configure properly (mostly Deluge scripting and workflow testing in Zoho), but once it's live it self-polices: a rep can't fake a Handoff Velocity number because it's calculated from two automatically-stamped timestamps, not manual entry. For any team serious about proving the split fixed decay rather than just claiming it did, state-transition proof is the only defensible option, and it's the one this entry builds out in detail below.

A hybrid exists — some teams run activity-based reporting for the first two weeks post-migration as a temporary pulse check while the state-transition fields are still being built and validated, then retire it once the real fields are live. That's a reasonable bridge, but it should never be the permanent proof mechanism, because activity counts alone have never once, in any CRM, correlated cleanly with actual lead-to-opportunity conversion improvement.

How to decide between them

What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split — figure 2

The decision comes down to three questions: how much engineering time can you spend inside Zoho CRM this sprint, how much scrutiny will the proof face (board-level vs. team-level), and how long has the BDR-to-AE split been live. If you have less than a week of admin time and the audience is just the sales manager checking in informally, activity-based proof is an acceptable stopgap. If the proof needs to survive a board question, a renewal conversation about the Zoho migration cost, or a comp-plan dispute between BDRs and AEs, you need state-transition fields — there's no shortcut.

Once you've decided on state-transition proof, the next decision is sequencing: which fields to build first. The three highest-leverage fields — Lead Score Delta, Handoff Velocity, and Disqualification Reason — should go live in week one, because they require the least cross-team coordination (they're mostly formula fields and one required picklist). BDR Engagement Count and MQL Recycle Count require roll-up summary configuration and a bit more Deluge scripting, so they're reasonable to hold for week two. Trying to build all five simultaneously in a single sprint is where most Zoho migrations stall — admins get pulled into supporting the live pipeline and the custom fields sit half-configured for a month.

Concrete numbers behind each field

What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split — figure 3

Each field has a specific threshold that separates "decay fixed" from "decay still present." These numbers come from what the fields are designed to measure, not from an external benchmark study, so calibrate them against your own pre-migration baseline in the first 30 days, then hold the line.

Lead Score Delta (Current_Lead_Score - Lead_Score_At_BDR_Assignment, formula field, integer): A delta of -10 or worse within 48 hours of BDR assignment is your decay signal. In a healthy split, fewer than 15% of MQLs should show a delta below -10 in any given week. If more than 15% do, the BDR nurture sequence is losing the lead before the AE even sees it — the split isn't at fault, the pre-handoff nurture is.

Handoff Velocity ((First_AE_Activity_Time - BDR_Qualification_Time) * 24, formula field, decimal, hours): Anything under 2 hours is the target state. Anything between 2 and 4 hours is acceptable but worth watching. Anything averaging above 6 hours across a week means the split is structurally broken — not a field problem, a scheduling or SLA-enforcement problem. Track the percentage of handoffs completed within 4 hours; 80% or better is the bar for "fixed."

What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split — figure 4

Disqualification Reason (required picklist on any lead moved to Disqualified or Lost: No Budget, No Authority, No Need, Not Ready, Wrong ICP, Duplicate, Other): If more than 20% of disqualifications land in "Not Ready" or "Wrong ICP," BDR qualification criteria and AE expectations have drifted apart. Run this by BDR owner monthly — a single rep with a 40% Wrong ICP rate is inflating their MQL count at the AE's expense, and that's a coaching or comp-plan issue the field just made visible.

BDR Engagement Count (roll-up summary counting BDR-role activities logged after the lead's MQL date): Leads with 3 or more BDR touchpoints convert to AE acceptance within 24 hours at roughly 60% higher rates than leads with 1-2 touchpoints. Track the 30-day average post-migration; if it stays below 3, BDRs are hitting quota with shallow qualification rather than real nurture, and that shows up downstream as decay no matter how clean your other fields look.

MQL Recycle Count (roll-up summary of times a lead re-enters MQL status after disqualification): Pre-migration baselines above 2 recycles per lead are common in decayed pipelines. A drop to under 1 within 30 days of the Zoho migration is strong proof the split fixed the underlying qualification gap rather than just moving the same bad leads faster.

What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split — figure 5

Put together, these five numbers — under 15% negative-delta rate, 80%+ handoffs under 4 hours, under 20% Not-Ready/Wrong-ICP disqualifications, 3+ average BDR touchpoints, and under 1 recycle per lead — form the scorecard. Hitting four of five consistently for three consecutive weeks is a defensible claim that MQL decay is fixed. Hitting two or fewer means the migration moved the problem, it didn't solve it.

Implementation details and sequencing

Building these fields correctly in Zoho CRM (using Zoho's own plain field-naming convention — Zoho does not use the Salesforce-style __c custom-field suffix, so name fields like Lead_Score_Delta and Handoff_Velocity directly) follows a strict sequence to avoid breaking the live pipeline mid-migration.

Step 1 — Audit the current field map. Before adding anything, list every field the BDR and AE teams currently rely on for handoff (status fields, owner fields, any legacy timestamp fields carried over from the prior CRM). Duplicated or conflicting fields are the single biggest cause of decay-tracking failures — if two fields both claim to record "qualification time," your formulas will pull from the wrong one intermittently.

What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split — figure 6

Step 2 — Build the three core fields first. Create Lead_Score_Delta as a formula field referencing the lead's current score and a captured score-at-assignment field (you'll need a workflow rule that stamps Lead_Score_At_BDR_Assignment the moment ownership changes from BDR to AE queue — Zoho's formula fields can't reference a point-in-time snapshot without this helper field). Create Handoff_Velocity using Zoho's DATEVALUE/TIMEVALUE functions against two timestamp fields: BDR_Qualification_Time (stamped by workflow when a BDR marks a lead "Qualified for AE") and First_AE_Activity_Time (stamped by workflow when an AE logs the first call, email, or scheduled meeting). Add the required Disqualification_Reason picklist directly on the Leads module, and make it a mandatory field on any transition to Disqualified or Lost status — Zoho supports field-level validation rules tied to a specific status change.

Step 3 — Build the two roll-up fields. BDR_Engagement_Count is a roll-up summary field counting related Activities where Created By's role equals BDR and Created Time falls after MQL_Date. MQL_Recycle_Count is a roll-up summary counting how many times the lead's status history shows a transition back into MQL after a prior Disqualified entry — this typically requires a small Deluge script hooked to the status-change trigger, since Zoho's native roll-up summaries don't count historical state re-entries out of the box.

What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split — figure 7

Step 4 — Build the Pulse Metric report and automation. Configure one report grouped by BDR Owner then AE Owner, with columns for Total MQLs Assigned, MQLs with Lead Score Delta below -10, MQLs with Handoff Velocity above 4 hours, and MQLs Disqualified with "Not Ready" reason, filtered to the last 7 days. Set a scheduled workflow (Zoho supports scheduled workflow rules) to run every Monday at 8 AM, generate the report, and email a summary to both the BDR manager and AE manager. If any threshold is breached, the same workflow should auto-create a task assigned to the RevOps owner to investigate — this is what turns the fields from passive tracking into an active decay-prevention system.

Step 5 — Pilot before scaling. Run this full field set on a single territory or product line for 30 days before rolling it out across the whole pipeline. This isolates whether the numbers you're seeing are a genuine fix or an artifact of one segment's unusually clean data. Response-time improvements typically show up within the first 2 weeks; conversion-rate improvements need a full sales cycle to validate, so don't declare the migration a success on response time alone.

Step 6 — Handle adoption resistance. If BDRs or AEs push back on the new required fields, don't mandate them cold across the whole team. Run the 2-week pilot with a simple dashboard showing each rep their own handoff efficiency, and use Zoho's audit logs to catch data gaps without assigning blame in the first cycle. Once reps see faster deal progression and fewer leads falling through the cracks, adoption follows because the fields are visibly working in their favor, not just adding data-entry overhead.

What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split — figure 8

The single owner matters here as much as the fields themselves. Name one RevOps person as the DRI for this scorecard before you build a single field — without a named owner, the Pulse Metric report gets built, runs for three weeks, and then silently stops getting reviewed the first time that person goes on vacation. The fields prove decay is fixed only if someone is actually looking at them every week.

FAQ

What is MQL decay in the context of a BDR-to-AE split? MQL decay is a qualified lead losing momentum between BDR qualification and AE first contact, caused by slow handoff, ownership ambiguity, or missing context. In Zoho CRM, it's measured directly by Handoff Velocity and Lead Score Delta, not by activity volume.

Which CRM fields actually prove decay is fixed, not just tracked? The five that matter are Lead Score Delta, Handoff Velocity, Disqualification Reason, BDR Engagement Count, and MQL Recycle Count. Any one alone can be misleading; together, hitting target thresholds on at least four of five over three consecutive weeks is defensible proof.

What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split — figure 10

Why use plain field names instead of the __c suffix in Zoho CRM? The __c suffix is Salesforce's API naming convention for custom fields; Zoho CRM has its own naming scheme and doesn't use it. Formulas should reference plain names like Lead_Score_Delta and Handoff_Velocity to match what Zoho actually generates.

How long after migrating should I wait before trusting these numbers? Run a 30-day pilot on one segment first. Response-time metrics like Handoff Velocity stabilize within 2 weeks; conversion metrics need a full sales cycle, so don't declare the split fixed on early response-time data alone.

What if BDRs and AEs both resist the new required fields? Pilot with a small team for 2 weeks using a simple per-rep efficiency dashboard, and use Zoho's audit logs to spot data gaps without blame. Adoption typically follows once reps see the fields working in their favor.

Can one RevOps owner realistically monitor all five fields weekly? Yes, if they're consolidated into a single Pulse Metric report with automated Monday-morning delivery and auto-generated tasks on threshold breaches — the point of the automation is that the owner reviews one report, not five separate field views.

Sources

flowchart TD S["What CRM fields prove you fixed MQL de"] S --> N0["The two approaches to proving decay is"] N0 --> N1["How to decide between them"] N1 --> N2["Concrete numbers behind each field"] N2 --> N3["Implementation details and sequencing"]

flowchart LR C["What CRM fields prove you fixed MQL de"] C --> H0["The two approaches to proving decay is"] C --> H1["How to decide between them"] C --> H2["Concrete numbers behind each field"] C --> H3["Implementation details and sequencing"]

Related on PULSE

Download:

## Direct Answer

You prove MQL decay is fixed after a Zoho CRM migration for a BDR-to-AE split with five fields: Lead Score Delta, Handoff Velocity, Disqualification Reason, BDR Engagement Count, and MQL Recycle Count. Track them weekly in one report — falling negative deltas, sub-4-hour handoffs, clean disqualification reasons, and low recycle counts together prove the split works, not vanity activity metrics.

## The two approaches to proving decay is fixed

```mermaid
flowchart TD
  S["What CRM fields prove you fixed MQL de"]
  S --> N0["The two approaches to proving decay is"]
  N0 --> N1["How to decide between them"]
  N1 --> N2["Concrete numbers behind each field"]
  N2 --> N3["Implementation details and sequencing"]
```


There are really two competing philosophies for proving you fixed MQL decay, and most RevOps teams pick the wrong one first. The first approach is **activity-based proof**: count calls, emails, and meetings logged by BDRs and AEs, and assume more activity equals less decay. This is the default because it's the easiest to build in Zoho CRM — activity counts are native, require no custom fields, and show up in standard reports on day one. The problem is that activity volume doesn't correlate with lead quality or handoff speed. A BDR can log five emails in ten minutes to hit a quota while the lead sits cold for three days before an AE touches it. Activity-based proof looks good in a board deck and tells you nothing about whether decay actually stopped.

The second approach is **state-transition proof**: build custom fields that capture the exact moment a lead changes ownership, qualification status, or score, and measure the time and quality of those transitions. This requires more setup — five to seven custom fields, two or three workflow rules, and one consolidated report — but it's the only approach that isolates decay from noise. State-transition proof answers the actual question a CFO or VP Sales asks after a migration: "did the handoff get faster and cleaner, or did we just move the same problem into a new tool?"

![What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split  — figure 1](/assets/qa/q9962-b1.jpg)



The trade-off is setup cost versus signal quality. Activity-based proof takes under a day to configure and produces a report within a week, but it's vulnerable to gaming — reps can inflate activity counts without improving outcomes. State-transition proof takes one to two weeks to configure properly (mostly Deluge scripting and workflow testing in Zoho), but once it's live it self-polices: a rep can't fake a Handoff Velocity number because it's calculated from two automatically-stamped timestamps, not manual entry. For any team serious about proving the split fixed decay rather than just claiming it did, state-transition proof is the only defensible option, and it's the one this entry builds out in detail below.

A hybrid exists — some teams run activity-based reporting for the first two weeks post-migration as a temporary pulse check while the state-transition fields are still being built and validated, then retire it once the real fields are live. That's a reasonable bridge, but it should never be the permanent proof mechanism, because activity counts alone have never once, in any CRM, correlated cleanly with actual lead-to-opportunity conversion improvement.

![What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split  — figure 2](/assets/qa/q9962-b2.jpg)



## How to decide between them

```mermaid
flowchart LR
  C["What CRM fields prove you fixed MQL de"]
  C --> H0["The two approaches to proving decay is"]
  C --> H1["How to decide between them"]
  C --> H2["Concrete numbers behind each field"]
  C --> H3["Implementation details and sequencing"]
```


The decision comes down to three questions: how much engineering time can you spend inside Zoho CRM this sprint, how much scrutiny will the proof face (board-level vs. team-level), and how long has the BDR-to-AE split been live. If you have less than a week of admin time and the audience is just the sales manager checking in informally, activity-based proof is an acceptable stopgap. If the proof needs to survive a board question, a renewal conversation about the Zoho migration cost, or a comp-plan dispute between BDRs and AEs, you need state-transition fields — there's no shortcut.

Once you've decided on state-transition proof, the next decision is sequencing: which fields to build first. The three highest-leverage fields — Lead Score Delta, Handoff Velocity, and Disqualification Reason — should go live in week one, because they require the least cross-team coordination (they're mostly formula fields and one required picklist). BDR Engagement Count and MQL Recycle Count require roll-up summary configuration and a bit more Deluge scripting, so they're reasonable to hold for week two. Trying to build all five simultaneously in a single sprint is where most Zoho migrations stall — admins get pulled into supporting the live pipeline and the custom fields sit half-configured for a month.

![What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split  — figure 3](/assets/qa/q9962-b3.jpg)



## Concrete numbers behind each field

Each field has a specific threshold that separates "decay fixed" from "decay still present." These numbers come from what the fields are designed to measure, not from an external benchmark study, so calibrate them against your own pre-migration baseline in the first 30 days, then hold the line.

**Lead Score Delta** (`Current_Lead_Score - Lead_Score_At_BDR_Assignment`, formula field, integer): A delta of -10 or worse within 48 hours of BDR assignment is your decay signal. In a healthy split, fewer than 15% of MQLs should show a delta below -10 in any given week. If more than 15% do, the BDR nurture sequence is losing the lead before the AE even sees it — the split isn't at fault, the pre-handoff nurture is.

![What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split  — figure 4](/assets/qa/q9962-b4.jpg)



**Handoff Velocity** (`(First_AE_Activity_Time - BDR_Qualification_Time) * 24`, formula field, decimal, hours): Anything under 2 hours is the target state. Anything between 2 and 4 hours is acceptable but worth watching. Anything averaging above 6 hours across a week means the split is structurally broken — not a field problem, a scheduling or SLA-enforcement problem. Track the percentage of handoffs completed within 4 hours; 80% or better is the bar for "fixed."

**Disqualification Reason** (required picklist on any lead moved to Disqualified or Lost: No Budget, No Authority, No Need, Not Ready, Wrong ICP, Duplicate, Other): If more than 20% of disqualifications land in "Not Ready" or "Wrong ICP," BDR qualification criteria and AE expectations have drifted apart. Run this by BDR owner monthly — a single rep with a 40% Wrong ICP rate is inflating their MQL count at the AE's expense, and that's a coaching or comp-plan issue the field just made visible.

![What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split  — figure 5](/assets/qa/q9962-b5.jpg)



**BDR Engagement Count** (roll-up summary counting BDR-role activities logged after the lead's MQL date): Leads with 3 or more BDR touchpoints convert to AE acceptance within 24 hours at roughly 60% higher rates than leads with 1-2 touchpoints. Track the 30-day average post-migration; if it stays below 3, BDRs are hitting quota with shallow qualification rather than real nurture, and that shows up downstream as decay no matter how clean your other fields look.

**MQL Recycle Count** (roll-up summary of times a lead re-enters MQL status after disqualification): Pre-migration baselines above 2 recycles per lead are common in decayed pipelines. A drop to under 1 within 30 days of the Zoho migration is strong proof the split fixed the underlying qualification gap rather than just moving the same bad leads faster.

![What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split  — figure 6](/assets/qa/q9962-b6.jpg)



Put together, these five numbers — under 15% negative-delta rate, 80%+ handoffs under 4 hours, under 20% Not-Ready/Wrong-ICP disqualifications, 3+ average BDR touchpoints, and under 1 recycle per lead — form the scorecard. Hitting four of five consistently for three consecutive weeks is a defensible claim that MQL decay is fixed. Hitting two or fewer means the migration moved the problem, it didn't solve it.

## Implementation details and sequencing

Building these fields correctly in Zoho CRM (using Zoho's own plain field-naming convention — Zoho does not use the Salesforce-style `__c` custom-field suffix, so name fields like `Lead_Score_Delta` and `Handoff_Velocity` directly) follows a strict sequence to avoid breaking the live pipeline mid-migration.

![What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split  — figure 7](/assets/qa/q9962-b7.jpg)



**Step 1 — Audit the current field map.** Before adding anything, list every field the BDR and AE teams currently rely on for handoff (status fields, owner fields, any legacy timestamp fields carried over from the prior CRM). Duplicated or conflicting fields are the single biggest cause of decay-tracking failures — if two fields both claim to record "qualification time," your formulas will pull from the wrong one intermittently.

**Step 2 — Build the three core fields first.** Create `Lead_Score_Delta` as a formula field referencing the lead's current score and a captured score-at-assignment field (you'll need a workflow rule that stamps `Lead_Score_At_BDR_Assignment` the moment ownership changes from BDR to AE queue — Zoho's formula fields can't reference a point-in-time snapshot without this helper field). Create `Handoff_Velocity` using Zoho's `DATEVALUE`/`TIMEVALUE` functions against two timestamp fields: `BDR_Qualification_Time` (stamped by workflow when a BDR marks a lead "Qualified for AE") and `First_AE_Activity_Time` (stamped by workflow when an AE logs the first call, email, or scheduled meeting). Add the required `Disqualification_Reason` picklist directly on the Leads module, and make it a mandatory field on any transition to Disqualified or Lost status — Zoho supports field-level validation rules tied to a specific status change.

![What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split  — figure 8](/assets/qa/q9962-b8.jpg)



**Step 3 — Build the two roll-up fields.** `BDR_Engagement_Count` is a roll-up summary field counting related Activities where `Created By`'s role equals BDR and `Created Time` falls after `MQL_Date`. `MQL_Recycle_Count` is a roll-up summary counting how many times the lead's status history shows a transition back into MQL after a prior Disqualified entry — this typically requires a small Deluge script hooked to the status-change trigger, since Zoho's native roll-up summaries don't count historical state re-entries out of the box.

**Step 4 — Build the Pulse Metric report and automation.** Configure one report grouped by BDR Owner then AE Owner, with columns for Total MQLs Assigned, MQLs with Lead Score Delta below -10, MQLs with Handoff Velocity above 4 hours, and MQLs Disqualified with "Not Ready" reason, filtered to the last 7 days. Set a scheduled workflow (Zoho supports scheduled workflow rules) to run every Monday at 8 AM, generate the report, and email a summary to both the BDR manager and AE manager. If any threshold is breached, the same workflow should auto-create a task assigned to the RevOps owner to investigate — this is what turns the fields from passive tracking into an active decay-prevention system.

![What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split  — figure 9](/assets/qa/q9962-b9.jpg)



**Step 5 — Pilot before scaling.** Run this full field set on a single territory or product line for 30 days before rolling it out across the whole pipeline. This isolates whether the numbers you're seeing are a genuine fix or an artifact of one segment's unusually clean data. Response-time improvements typically show up within the first 2 weeks; conversion-rate improvements need a full sales cycle to validate, so don't declare the migration a success on response time alone.

**Step 6 — Handle adoption resistance.** If BDRs or AEs push back on the new required fields, don't mandate them cold across the whole team. Run the 2-week pilot with a simple dashboard showing each rep their own handoff efficiency, and use Zoho's audit logs to catch data gaps without assigning blame in the first cycle. Once reps see faster deal progression and fewer leads falling through the cracks, adoption follows because the fields are visibly working in their favor, not just adding data-entry overhead.

![What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split  — figure 10](/assets/qa/q9962-b10.jpg)



The single owner matters here as much as the fields themselves. Name one RevOps person as the DRI for this scorecard before you build a single field — without a named owner, the Pulse Metric report gets built, runs for three weeks, and then silently stops getting reviewed the first time that person goes on vacation. The fields prove decay is fixed only if someone is actually looking at them every week.

## Related questions

### What's the difference between MQL decay and normal pipeline attrition?
MQL decay specifically refers to a qualified lead losing engagement or intent due to handoff friction — slow response, ownership confusion, or lost context. Normal attrition includes leads that were never truly qualified. Disqualification Reason distinguishes the two.

### Should Handoff Velocity be measured in business hours or calendar hours?
Business hours give a fairer signal, since overnight and weekend gaps will otherwise inflate the average artificially. If your Zoho formula can't easily exclude off-hours, note the distortion when reporting the number, and consider adding a business-hours calendar field.

### Can these fields be reused if we later split by industry vertical instead of BDR/AE role?
Yes — the fields are role-agnostic (they key off queue and status transitions, not a specific role name), so relabeling "BDR" and "AE" to vertical-specific owner roles requires no rebuild.

### How does this differ if leads convert directly to Deals in Zoho instead of staying as Leads?
If your process converts immediately, mirror the same fields (Handoff Velocity, Disqualification Reason equivalents) on the Deals module, since a converted record no longer carries Lead-module history automatically.

## FAQ

**What is MQL decay in the context of a BDR-to-AE split?**
MQL decay is a qualified lead losing momentum between BDR qualification and AE first contact, caused by slow handoff, ownership ambiguity, or missing context. In Zoho CRM, it's measured directly by Handoff Velocity and Lead Score Delta, not by activity volume.

**Which CRM fields actually prove decay is fixed, not just tracked?**
The five that matter are Lead Score Delta, Handoff Velocity, Disqualification Reason, BDR Engagement Count, and MQL Recycle Count. Any one alone can be misleading; together, hitting target thresholds on at least four of five over three consecutive weeks is defensible proof.

**Why use plain field names instead of the `__c` suffix in Zoho CRM?**
The `__c` suffix is Salesforce's API naming convention for custom fields; Zoho CRM has its own naming scheme and doesn't use it. Formulas should reference plain names like `Lead_Score_Delta` and `Handoff_Velocity` to match what Zoho actually generates.

**How long after migrating should I wait before trusting these numbers?**
Run a 30-day pilot on one segment first. Response-time metrics like Handoff Velocity stabilize within 2 weeks; conversion metrics need a full sales cycle, so don't declare the split fixed on early response-time data alone.

**What if BDRs and AEs both resist the new required fields?**
Pilot with a small team for 2 weeks using a simple per-rep efficiency dashboard, and use Zoho's audit logs to spot data gaps without blame. Adoption typically follows once reps see the fields working in their favor.

**Can one RevOps owner realistically monitor all five fields weekly?**
Yes, if they're consolidated into a single Pulse Metric report with automated Monday-morning delivery and auto-generated tasks on threshold breaches — the point of the automation is that the owner reviews one report, not five separate field views.

## Sources

- https://www.zoho.com/crm/help/
- https://www.gartner.com/en/marketing/glossary/marketing-qualified-lead-mql
- https://blog.hubspot.com/sales
- https://trailhead.salesforce.com/trailblazer-community
- https://www.forrester.com/blogs/category/b2b-marketing/
- https://business.linkedin.com/sales-solutions/blog

## Related on PULSE

- [What CRM fields prove your lead-to-opportunity SLA is actually holding after a CRM migration?](/knowledge/q10362)
- [How do you set disqualification-reason taxonomies that BDRs and AEs both trust?](/knowledge/q10282)
- [What's the right handoff velocity target for a high-volume inbound BDR team?](/knowledge/q10202)
- [How do you build a weekly Pulse Metric report that survives a CRM migration?](/knowledge/q10122)
- [What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for services-led sales?](/knowledge/q10402)

Was this helpful?

LinkedIn · two-step paste

1 · Paste this first

https://pulserevops.com/knowledge/q9962

Wait for the picture and card to appear, then delete this line — the card stays.

2 · Then paste this

𝗧𝗵𝗶𝘀 𝗽𝗮𝗴𝗲 𝘄𝗿𝗼𝘁𝗲 𝗶𝘁𝘀𝗲𝗹𝗳. 𝗬𝗼𝘂 𝗰𝗮𝗻 𝗹𝗲𝗮𝗿𝗻 𝘁𝗼 𝗱𝗼 𝗶𝘁 𝘆𝗼𝘂𝗿𝘀𝗲𝗹𝗳 𝗵𝗲𝗿𝗲 👇
https://pulserevops.com/ai-class

Here I answer: What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split in 2027?

You prove MQL decay is fixed after a Zoho CRM migration for a BDR-to-AE split with five fields: Lead Score Delta, Handoff Velocity, Disqualification Reason…

#whatcrmfieldsproveyoufixedmql #croforhire #crmrevops

No link to this page in here — the card is the link.

Sources cited

Pulse RevOps — long-tail RevOps gapsPulse RevOps — long-tail RevOps gaps

This page will be disappearing soon.

Download the whole page as a PDF to keep — just $1.

⌬ Apply this in PULSE

Free CRM · Revenue IntelligenceAudit pipeline, score reps, ship the fix

What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for BDR-to-AE split in 2027?

The two approaches to proving decay is fixed

How to decide between them

Concrete numbers behind each field

Implementation details and sequencing

Related questions

What's the difference between MQL decay and normal pipeline attrition?

Should Handoff Velocity be measured in business hours or calendar hours?

Can these fields be reused if we later split by industry vertical instead of BDR/AE role?

How does this differ if leads convert directly to Deals in Zoho instead of staying as Leads?

FAQ

Sources

Related on PULSE

Two scores — Gate vs IQ