SfSkills Domains Docs GitHub

Home / admin / marketing-automation-requirements

marketing-automation-requirements

Use this skill when gathering, documenting, or validating requirements for a Salesforce marketing automation program — covering MCAE (Account Engagement / Pardot) lifecycle stages, MQL/SQL threshold definitions, scoring model specifications (sources, weights, decay, ceiling), handoff notification design, CRM field updates on status change, and sales SLA.

Open the skill folder on GitHub

Marketing Automation Requirements

This skill activates when a practitioner needs to gather, document, or validate the business requirements for a Salesforce marketing automation program before any platform configuration begins. It produces the requirements artifacts — scoring model spec, MQL/SQL threshold definitions, lifecycle stage map, handoff mechanism design, and sales SLA — that implementation skills (mcae-lead-scoring-and-grading, mcae-pardot-setup) depend on as inputs.

Before Starting

Gather this context before working on anything in this domain:

Core Concepts

Lifecycle Stages and Platform Mapping

MCAE defines a standard set of lifecycle stages used in the Lifecycle Report (accessible via B2B Marketing Analytics):

StageDescriptionCRM Correlation
VisitorAnonymous site visitor — no prospect record yetNo CRM record
ProspectKnown contact in MCAE database — below MQL thresholdLead or Contact record exists
MQLCrossed the agreed score (and optionally grade) threshold — flagged for salesLead Is_MQL__c stamped, rep notified
SQLRep has accepted and qualified the MQL against BANT/MEDDIC criteriaLead status updated to "Accepted" or Contact linked to Opportunity
OpportunityActive sales cycle underwaySalesforce Opportunity in open stage
CustomerOpportunity closed-wonOpportunity Stage = Closed Won
WonPost-sale tracking within MCAE lifecycle reportOpportunity Stage = Closed Won, confirmed in MCAE

Source: Salesforce Help — Lifecycle Report Metrics.

Requirements must define which stage transitions are automated (e.g., Prospect → MQL fires automatically when score threshold is crossed) and which require manual rep action (e.g., MQL → SQL requires rep to update Lead status).

Scoring Model Specification

A compliant scoring model requirements document must specify six elements:

  1. Scoring sources — the complete list of activities that generate score points: form fills, email link clicks, email opens, page views on tracked pages, content downloads, webinar registrations, custom redirect clicks, and any custom event integrations. Each source must be listed explicitly; "standard MCAE activities" is not a sufficient specification.
  2. Point weights per activity — the numeric point value assigned to each scoring source. Weights must reflect relative intent signal strength: a demo request form fill (high intent) should outweigh a blog page view (low intent). Default MCAE weights (e.g., form fill = +50, email click = +5, page view = +1) are a starting point, but the requirements must confirm or override each value.
  3. Score decay rules — time-based point reduction logic to ensure old engagement does not permanently inflate scores. A decay rule specifies: the inactivity period (e.g., 30 days with no tracked activity), the point reduction per cycle (e.g., −10 points), and whether multiple rules stack (e.g., −10 at 30 days AND −20 at 60 days). Without decay rules, prospects from old campaigns remain MQL-eligible indefinitely. Source: Salesforce Help — MCAE Scoring and Grading.
  4. Ceiling score — the maximum score a prospect can accumulate. MCAE does not enforce a hard ceiling by default, but requirements may specify a logical ceiling (e.g., 250 points) above which additional activity does not increase the score. This prevents a highly active competitor or researcher from permanently occupying the top of the MQL queue.
  5. Grade profile criteria — for orgs using the score+grade MQL model, requirements must document the Profile criteria: which job titles, industries, company sizes, and geographies earn positive grade points, and which earn negative grade points. Each criterion must map to a specific Salesforce field value.
  6. Negative scoring — activities that indicate disqualification (unsubscribe, hard bounce, opt-out) must be listed with their deduction values (e.g., Unsubscribe = −50, Hard Bounce = −75).

MQL and SQL Threshold Definition

The MQL threshold is the quantitative boundary at which marketing certifies a prospect as ready for sales engagement. Requirements must document:

Marketing Cloud Next Scoring Models vs. MCAE Scoring

Marketing Cloud Next (MC Next) supports configurable Scoring Models that operate on Data Cloud engagement data, not on MCAE prospect activity. If the org uses MC Next, requirements must specify:

MC Next Scoring Models are distinct from MCAE Scoring. Requirements must be explicit about which system owns the authoritative score. Running both without a clear ownership rule causes conflicting scores on the same contact.

MCE Automation Studio vs. MCAE Engagement Studio

These are two separate automation engines that are frequently confused in requirements documents:

Requirements must state explicitly which automation engine is in scope. Conflating them leads to implementation specs that describe MCAE behavior using MCE terminology or vice versa, causing rework.

Common Patterns

Pattern 1: Score + Grade MQL with Lifecycle Stage Field Updates

When to use: B2B orgs with MCAE where both behavioral engagement and ICP fit must be confirmed before MQL handoff. This is the recommended baseline for most B2B use cases.

How it works:

  1. Define MQL threshold: Prospect Score >= 100 AND Prospect Grade >= B.
  2. Specify the MCAE Automation Rule that fires at this threshold and performs: (a) update Prospect_Status field to "MQL", (b) assign to Sales queue, (c) create CRM task on the Lead record with subject "New MQL — follow up within 24 hours", (d) send alert email to assigned rep.
  3. Specify CRM field updates: Is_MQL__c = true, MQL_Date__c = today, Lifecycle_Stage__c = "MQL".
  4. Define the SLA: rep must accept or recycle within 1 business day. Recycled leads must have Recycle_Reason__c populated.
  5. Document the SQL acceptance gate: rep confirms BANT and updates Lifecycle_Stage__c = "SQL", SQL_Date__c = today.

Why not score alone: High-scoring, low-fit contacts (competitors researching your product, non-buyers in wrong geographies) generate noise in the Sales queue. The grade gate filters for ICP fit.

Pattern 2: Score-Only MQL with Segmented Scoring Rules

When to use: Orgs with a single, broad ICP where firmographic fit is less variable, or orgs where MCAE Profiles are not yet configured and the team needs an initial MQL model to start collecting conversion data.

How it works:

  1. Define MQL threshold: Prospect Score >= 75 (lower threshold may be appropriate without a grade gate).
  2. Specify per-asset score overrides for high-intent assets: demo request form = 75 points (enough to qualify on a single fill); pricing page view = 10 points (overrides the default 1-point page view).
  3. Specify decay rules: −10 points after 30 days of inactivity, −20 points after 60 days.
  4. Define ceiling: cap effective score at 150. If a prospect exceeds 150, no additional points are awarded until decay reduces the score below the ceiling.
  5. Specify that a follow-up review is scheduled 90 days after go-live to assess MQL-to-SQL conversion rate and calibrate threshold.

Why not implement grade profiles immediately: If the org does not have reliable ICP field data (e.g., Title, Industry fields are sparsely populated), a grade Profile will produce inaccurate grades. Start with score-only and add grading once field data quality is confirmed.

Pattern 3: MC Next Scoring Model Requirements for Data Cloud Orgs

When to use: Orgs using Marketing Cloud Next with Data Cloud as the engagement data backbone, replacing or supplementing MCAE with MC Next's configurable Scoring Models.

How it works:

  1. Identify the engagement event streams in Data Cloud that will feed the scoring model: email engagement DMO, web engagement DMO, mobile push DMO.
  2. Specify the scoring dimensions in the MC Next Scoring Model: which event types award points, what weights apply, and whether the model uses recency weighting (more recent events count more).
  3. Specify the output: the computed score field on the Individual profile object in Data Cloud, and the cadence of score recalculation (near-real-time vs. scheduled batch).
  4. Specify the CRM surface: how the MC Next score is mapped through the Data Cloud — Salesforce CRM connector to a Lead or Contact field, and how it is consumed by CRM-side routing (Flow, Assignment Rules).
  5. Document the relationship between MC Next score and any residual MCAE score: if both systems are active, which score is authoritative for MQL evaluation.

Decision Guidance

SituationRecommended ApproachReason
MCAE is the primary MAP, B2B org with ICP fit varianceScore + Grade MQL (Pattern 1)Dual-dimension filtering reduces false positives in Sales queue
MCAE active, ICP field data quality is poor or sparseScore-only MQL with per-asset overrides (Pattern 2) until data quality improvesGrade model on bad data produces meaningless grades
MC Next + Data Cloud is the engagement platformMC Next Scoring Model requirements (Pattern 3)MCAE scoring concepts do not map to MC Next architecture
Org uses MCE Automation Studio for batch processesSpecify Automation Studio scope separately from Engagement Studio scopeThese are different engines; conflating them creates incorrect requirements
Sales disputes MQL quality after go-liveRequirements doc must include a calibration review milestone at 60–90 daysThreshold calibration requires post-launch conversion data; build the review into the SLA
Multiple ICP segments with different fit criteriaRequire separate grade Profiles per segment in requirementsOne Profile cannot accurately represent multiple ICP segments with different fit signals
Org needs to track Marketing Lifecycle Metrics (B2B MA Analytics)Include MCAE Lifecycle Stage field mapping in requirementsLifecycle Report metrics require specific CRM field values mapped per stage

Step-by-step instructions for an AI agent or practitioner working on this task:

  1. Establish platform scope. Confirm which marketing automation platforms are active in the org: MCAE, MCE, MC Next, or a combination. Document in the requirements scope section which platforms are in scope for this automation program and which are explicitly out of scope. Confirm that the implementation team will not conflate MCE Automation Studio with MCAE Engagement Studio.
  2. Map lifecycle stages and transitions. Working from the MCAE standard lifecycle model (Visitor → Prospect → MQL → SQL → Opportunity → Customer → Won), confirm which stages are in scope, define the trigger for each stage transition (automated vs. manual rep action), and list the CRM field updates each transition must produce. Get explicit confirmation from both marketing and sales on the stage definitions.
  3. Define the scoring model specification. For each scoring source (form fills, email clicks, page views, content downloads, webinar registrations, unsubscribes), document the agreed point weight. Confirm score decay rules (inactivity period and point reduction per cycle). Confirm the ceiling score. If the org uses MCAE grading, document the Profile criteria per ICP segment. Record any per-asset score overrides (e.g., pricing page view = 10 points instead of default 1).
  4. Agree on and document the MQL threshold. Run a joint session with marketing and sales leadership. Document the threshold (score alone or score+grade), the names and dates of approvers, and the agreed SQL qualification framework (BANT or MEDDIC). This is the single most important output of the requirements process — do not proceed to implementation without this sign-off.
  5. Specify the handoff mechanism. Document how the MQL is surfaced to the sales rep: which MCAE Automation Rule triggers (or which Engagement Studio program step fires), what CRM field updates occur (Is_MQL__c, MQL_Date__c, Lifecycle_Stage__c), what notification is sent (task creation, alert email, Slack notification via CRM Flow), and which queue or user the lead is assigned to.
  6. Define the sales SLA. Document the maximum response time for each MQL tier (e.g., 1 business day for demo-request MQLs, 3 business days for content-download MQLs), the recycle trigger and recycle field requirements (Recycle_Reason__c, Recycle_Date__c), and the escalation process if a rep fails to act within the SLA window.
  7. Produce the requirements document and run the checklist. Compile all decisions into the work template. Run the review checklist to confirm no section is incomplete. Hand off the completed requirements document to the implementation team as the input to mcae-lead-scoring-and-grading or the appropriate implementation skill.

Review Checklist

Run through these before marking work in this area complete:

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

  1. MCAE lifecycle stage names do not auto-populate CRM fields — The MCAE Lifecycle Report uses internally computed stage metrics; it does not write a "current lifecycle stage" value to the Salesforce Lead or Contact record automatically. If CRM-side reporting or Flow logic needs a lifecycle stage field, a separate custom picklist field (Lifecycle_Stage__c) must be created on Lead/Contact, and an MCAE automation rule or Engagement Studio completion action must update it at each stage transition. Requirements that assume the Lifecycle Report data is accessible in CRM reports will result in missing data.
  2. Score decay does not fire automation rules — When MCAE's score decay silently reduces a prospect's score below the MQL threshold, no automation rule or completion action fires to remove the MQL flag or notify Sales. If requirements include a "de-MQL" process (returning a prospect to nurture when their score drops), this must be specified as a separate automation rule that evaluates score against the threshold on a scheduled basis, or a CRM-side scheduled Flow that checks Score on Lead records periodically.
  3. MCE Automation Studio is not real-time and does not evaluate individual engagement — Automation Studio in Marketing Cloud Engagement runs batch processes on a schedule. It cannot evaluate a prospect's current score and route them to Sales when a threshold is crossed in real time. Requirements that describe real-time individual routing must reference MCAE Automation Rules or MCAE Engagement Studio, not MCE Automation Studio.

Output Artifacts

ArtifactDescription
Platform scope documentLists which marketing automation platforms are in scope, explicitly excludes others, and maps platform responsibilities
Lifecycle stage mapAll lifecycle stages in scope with transition triggers, responsible system, and CRM field updates per transition
Scoring model specificationComplete scoring source list, point weights, decay rules, ceiling, grade Profile criteria, and negative scoring deductions
MQL threshold definitionAgreed threshold (score or score+grade), approver names and sign-off dates, effective date
SQL qualification frameworkNamed framework (BANT/MEDDIC) with confirmed criteria for SQL acceptance
Handoff mechanism specAutomation rule or Engagement Studio step design, CRM field updates, notification method, assignment target
Sales SLA documentMax response time by MQL tier, recycle criteria, recycle field requirements, escalation process
CRM field requirements listAll Lead/Contact fields required: API name, type, owning system, and purpose

Package files