What CRM fields prove you fixed MQL decay after migrating to Zoho CRM for outbound SDR in 2027?

The two (or more) options compared

There are really two competing approaches to proving decay is fixed after a Zoho migration, and most RevOps teams default to the wrong one without realizing it.

Option A: Activity-count proof. This is the lazy default — count how many calls, emails, and touches SDRs logged post-migration and call rising volume "proof" of health. It's what most CRM out-of-the-box dashboards show you because Calls Logged and Emails Sent are native fields requiring zero setup. The problem is that activity volume and lead health are only weakly correlated. An SDR can hammer a dead list with 50 calls a week and every activity counter goes up while the underlying MQLs keep decaying. This option requires no field engineering, ships in day one, but it lies to leadership.

Option B: Signal-and-velocity proof. This is the harder path — build the nine custom fields described below (three signal-freshness, three engagement-velocity, three conversion-intent), wire them into Deluge-scripted automations, and report on them weekly. It requires roughly two to three weeks of RevOps configuration time post-migration, ownership from a single DRI, and buy-in from SDR managers to enforce Blueprint-gated sequences. But it produces something Option A never can: a field-level answer to "did the migration fix decay or just move the spreadsheet."

The trade-off is straightforward. Option A is free and instant but proves nothing — a board member asking "how do you know decay is fixed" gets a shrug dressed up as a chart. Option B costs setup time and requires discipline (SDRs must actually follow the Blueprint-enforced sequence, or the fields go stale), but it's the only approach that produces an audit trail a CRO can defend. Every RevOps org migrating to Zoho for outbound SDR should treat Option B as the actual deliverable of the migration, not a nice-to-have layered on afterward.

How to decide between them (mermaid)

The decision isn't really "which option" — it's "how fast do you need defensible proof, and who is going to own the fields." If you're a five-person SDR team with no dedicated RevOps headcount, Option A might be all you can sustain, but you should say so explicitly rather than pretending activity counts are decay proof. If you have any RevOps or sales-ops capacity at all, Option B pays for itself within the first reporting cycle because it catches decay while it's still fixable instead of after the quarter is blown.

The decisive factor is almost always ownership. Fields that nobody owns decay just as fast as the leads they're meant to track — a Last_Valid_Signal_Date field with no workflow rule updating it is worse than no field at all, because it creates false confidence. Before you build a single custom field, name the person (usually a RevOps analyst or senior SDR manager) who will be accountable for the weekly report showing these fields are still populating correctly. If you can't name that person, you're not ready for Option B yet, and you should be honest with leadership that you're running on activity-count proxies until you are.

Concrete numbers behind each option

Here's what separates a real proof point from a vanity one, with the actual thresholds RevOps teams use in Zoho after an outbound SDR migration.

Signal freshness thresholds. A lead with a genuine buying signal (email reply, qualifying form submission, or a call over 120 seconds) within the last 14 days stays "active." Between 15 and 30 days it needs re-engagement. Past 31 days it moves to nurture. Track this with a Source_Recency_Flag formula field (Today() - Created_Time) color-coded green (0–7 days), yellow (8–14 days), red (15+ days). Teams that implement this flag consistently report roughly a 40% reduction in SDRs wasting call time on stale records, because reps triage by color instead of by gut feel.

Data quality baseline. During migration, don't leave the Data_Quality_Score picklist blank or default it to "Unknown" — run a bulk update setting every migrated lead to "Low" initially, then let the first verified touch upgrade it to Medium or High. This matters because an unset or ambiguous default gets ignored by SDRs, while "Low" forces a deliberate upgrade action tied to a real verification event (a Lusha or ZoomInfo enrichment hit, or a confirmed live contact).

Velocity benchmarks. For outbound SDR specifically, healthy stage velocity is 5–8 touches over 10–14 days to move a lead from "Contacted" to "Qualified." Anything stretching past 21 days in a single stage is a decay signal worth flagging in the Stage_Transition_Speed field. Touch-sequence compliance above 80% (measured via a Blueprint-enforced checkbox field) correlates with roughly double the MQL-to-SQL conversion rate compared to sequences where reps skip or reorder steps. Engagement frequency should sit between 0.3 and 0.5 touches per day (Total_Touches / Days_Since_First_Touch); below 0.2 the lead is being neglected, above 0.8 you risk burning the contact out.

Conversion-intent thresholds. An Intent_Score_Composite of 12 or higher out of a 20-point roll-up (email click rate above 30%, LinkedIn profile views, webinar attendance, content downloads scored 1–5 each) marks a lead ready for sales handoff. Pair that with Last_Valid_Signal_Date within 7 days and Stage_Transition_Speed under 14 days, and you get the Handoff_Readiness_Flag. The number that actually proves decay is fixed: once more than 60% of your MQL pool carries a "Ready for Sales" flag, and that percentage holds for two consecutive reporting cycles, the migration has done its job. For deal efficiency, target a Conversion_Velocity_Index (days from MQL to Close Won divided by deal value) under 0.05 — a $10k deal closing in 30 days computes to roughly 0.003, which is the kind of number that silences skeptical board members.

Implementation details and sequencing (mermaid)

Building these fields isn't a one-afternoon task, and sequencing matters — build the wrong field first and you'll be re-mapping data twice. Do it in this order.

Week 1 — Signal freshness fields. Create Last_Valid_Signal_Date (Date field, Leads module) with a workflow rule triggered on email reply, qualifying form fill, or calls over 120 seconds. Add Data_Quality_Score (picklist: Low/Medium/High) and run the migration bulk-set to "Low," letting first-touch verification move it up. Add Source_Recency_Flag as a formula field with the color-coded thresholds above. Validate these three fields against a sample of 50 leads before rolling out org-wide — this catches workflow-trigger misfires early.

Week 2 — Engagement velocity fields. Build Stage_Transition_Speed using the Audit Log or a custom timestamp module (Days_in_Current_Stage = Today() - Stage_Entry_Date). Configure a Zoho Blueprint to enforce your prescribed touch sequence (Call → Email → LinkedIn → Call → Email), auto-flagging Touch_Sequence_Compliance as non-compliant when steps are skipped or gaps exceed 72 hours. Add Engagement_Frequency_Index as a nightly Deluge-scripted number field. This week is where SDR pushback usually surfaces — reps dislike Blueprint gating because it slows down quota-chasing shortcuts, so get sales-manager sign-off before enforcing it.

Week 3 — Conversion intent fields and reporting. Build the Intent_Score_Composite roll-up pulling from Emails, Events, and Campaigns modules. Add Handoff_Readiness_Flag as a daily automated workflow combining the three criteria above. Add Conversion_Velocity_Index as a formula field. Then build the three reports that make the fields visible: a Decay Risk Dashboard (SDR name × signal-recency bucket, red/yellow/green), a Velocity Trend Report (12-week line chart of stage speed and engagement frequency against MQL-to-SQL conversion), and an Intent Health Scorecard (composite score, Ready-for-Sales percentage, median conversion velocity, broken out by lead source).

Expect 4–8 weeks after the fields go live before you have a defensible trend line — the first two weeks show initial activity as SDRs adjust to the new fields, and sustained improvement over 30–60 days is what actually proves the fix rather than a one-week spike. If, after two full reporting cycles, the Ready-for-Sales percentage hasn't moved, the diagram above points you back to whichever field family is weakest — usually it's Touch_Sequence_Compliance, because that's the field most dependent on SDR discipline rather than automation.

Related questions

What's the difference between MQL decay and lead rot?

MQL decay specifically describes previously-qualified leads losing engagement after a system change like a CRM migration. Lead rot is broader and includes leads that were never properly qualified to begin with. The fields above target decay because they measure change in signal freshness, not initial qualification quality.

Should these fields live on the Lead or Contact module in Zoho?

Build them on the Leads module for outbound SDR work, since that's where pre-conversion activity lives. If your team converts leads to Contacts early, mirror the key fields (Last_Valid_Signal_Date, Intent_Score_Composite) onto Contacts via a workflow so the proof trail survives conversion.

Can these same fields prove decay is fixed for inbound leads too?

Mostly yes, but add a Source = Outbound field and a Sequence_Step field so you can filter outbound-specific decay separately — inbound decay usually stems from routing delays rather than sequence compliance, so mixing the two pools muddies the report.

How often should the Decay Risk Dashboard be reviewed?

Daily by SDR managers, weekly by RevOps leadership, and monthly by the CRO. Daily review catches individual reps drifting into the red zone before it becomes a pipeline-wide problem; the weekly and monthly cadences are for trend validation.

FAQ

What is MQL decay in the context of a Zoho CRM migration? MQL decay is when leads that were previously qualified stop showing engagement or moving through the pipeline after a system change. In Zoho, it typically appears as records with no updated Last_Valid_Signal_Date and flat or dropping Intent_Score_Composite values, indicating the migration didn't preserve the signals that made those leads qualified in the first place.

Which specific Zoho CRM fields prove you've fixed MQL decay? The core set is Last_Valid_Signal_Date, Data_Quality_Score, Source_Recency_Flag (signal freshness); Stage_Transition_Speed, Touch_Sequence_Compliance, Engagement_Frequency_Index (velocity); and Intent_Score_Composite, Handoff_Readiness_Flag, Conversion_Velocity_Index (intent). When these fields show sustained positive trends across two or more reporting cycles, decay is proven fixed.

How do you set these fields up in Zoho without disrupting active SDR workflows?

Roll them out in the three-week sequence above rather than all at once. Start with passive fields (date and formula fields that don't require SDR behavior change), validate on a small sample, then layer in the Blueprint-enforced compliance fields once managers have signed off, since those change how reps actually work day to day.

What reporting cadence confirms MQL decay is actually resolved? A weekly Pulse-style report to the CRO showing the three dashboards (Decay Risk, Velocity Trend, Intent Health Scorecard). The definitive threshold is more than 60% of MQLs carrying a "Ready for Sales" Handoff_Readiness_Flag, sustained for two consecutive weekly cycles — a single good week is noise, not proof.

How long after migrating should you expect to see proof of fixed decay? Four to eight weeks of consistent field population and reporting. The first two weeks mostly reflect SDRs adapting to new required fields; real proof comes from the 30–60 day trend line showing rising Intent_Score_Composite and Stage_Transition_Speed alongside a shrinking red zone on the Decay Risk Dashboard.

Do these fields work the same way for outbound and inbound SDR teams? The nine fields apply to both, but outbound teams should add a dedicated Source field and Sequence_Step field to isolate outbound-specific patterns, since outbound decay is usually a sequencing and cadence problem while inbound decay more often traces back to routing delays rather than the fields themselves.

Sources

• https://www.zoho.com/crm/help/
• https://www.zoho.com/deluge/help/
• https://blog.hubspot.com/marketing/marketing-qualified-lead
• https://trailhead.salesforce.com/content/learn/modules/lead-management
• https://www.gartner.com/en/sales/topics/sales-development
• https://www.forrester.com/blogs/category/sales/
• https://business.linkedin.com/sales-solutions/blog

Related on PULSE

• How do you sequence a Zoho CRM migration without losing SDR outbound momentum?
• What lead-scoring formula fields survive a CRM migration intact?
• How do you set MQL-to-SQL conversion benchmarks after a CRM platform switch?
• What Blueprint rules keep outbound SDR sequences compliant in Zoho?
• How do you audit CRM field health 90 days after a RevOps system migration?