Marketing says the leads are being sent. Sales says they never arrive. The Salesforce dashboard shows one conversion rate, HubSpot reports another, and everyone blames the CRM. Meanwhile, a prospect sits unassigned because a lifecycle value, routing field, or automation trigger doesn't match the rule someone thought was running.
Process gap analysis replaces that argument with evidence. In a RevOps environment, it means mapping the current process, defining the target state, collecting system records, identifying the actual gap, testing its root cause, prioritizing remediation, and measuring whether the fix holds. The method applies across Salesforce Sales Cloud, Account Engagement, formerly Pardot, Service Cloud, Revenue Cloud, and HubSpot Sales and Marketing Hubs.
The important distinction is practical. A workshop can reveal what people believe happens. A system-evidence review shows what happened to a real lead, opportunity, case, or renewal. That difference determines whether your findings survive executive scrutiny.
A useful revenue operations framework treats marketing, sales, service, data, and technology as one operating system rather than separate departments. By the end of this guide, you'll have a way to scope an audit, map cross-platform workflows, assemble an evidence pack, build a defensible gap register, and turn the results into an owned remediation roadmap.
Defining Scope and Objectives for Your Gap Analysis
Start with a process slice, not the entire revenue engine. Lead routing, the MQL-to-SQL handoff, nurture-to-meeting conversion, case escalation, renewal management, and quote approvals can each support a useful analysis. If you begin with every lifecycle stage, object, integration, and team, the project will produce a large inventory rather than a decision.
Choose the slice where three conditions overlap:
- Visible business pain: Leaders can describe a consequence, such as delayed follow-up, inconsistent qualification, or unreliable forecast inputs.
- Observable system activity: Salesforce, HubSpot, Account Engagement, or an integration layer contains events you can inspect.
- An accountable owner: Someone can approve a process change and keep the new standard in place.
Write the scope statement before opening a process-mapping tool. A useful version names the entry point, exit point, systems, teams, analysis window, exclusions, and business outcome. For example, a team might examine inbound lead capture through first sales contact across HubSpot Marketing Hub, Salesforce, and Account Engagement, while excluding post-opportunity pipeline management.
Decide how far the boundary should extend
Keep the analysis inside one platform when the failure is clearly local, such as a Salesforce flow that doesn't update ownership or a HubSpot workflow that assigns the wrong lifecycle stage. Span platforms when the suspected gap involves synchronisation, enrichment, routing, consent, attribution, or a handoff. A process that looks correct in Salesforce can still fail because Account Engagement never sent the expected value or an integration rejected the update.
Set an analysis window that reflects the operating reality you need to understand. Include enough recent activity to observe normal flow, exceptions, reassignment, and backlog, rather than relying only on a demonstration record. Document any seasonal campaign, territory change, migration, or system release that could distort interpretation.
Put the right people in the room
Marketing operations can explain campaign and scoring logic. Sales operations can describe assignment, capacity, and pipeline rules. The CRM administrator can verify objects, fields, automation, and permissions. Include frontline representatives because they encounter queue behaviour, duplicate records, and exception paths that documentation often omits.
Define success in operational terms before mapping starts. The analysis might be judged by whether every handoff has an owner, whether routing failures have a documented fallback, whether timestamps exist for the critical events, or whether a repaired stage produces a trustworthy conversion view. The outcome should be measurable, owned, and connected to a decision.
Mapping Current-State Processes Across Salesforce, HubSpot, and MCAE
Current-state mapping should describe what the systems do, not what the standard operating procedure says they do. Start with one real record and follow it from capture through enrichment, lifecycle qualification, assignment, notification, acceptance, and first meaningful action. Then repeat the trace with an exception, such as a missing territory, duplicate contact, inactive owner, or failed synchronisation.
Use a repeatable mapping format
Create one row for each meaningful state change or handoff. Record the actor, platform, object, field, trigger, rule, output, timestamp, exception path, and evidence location. In Salesforce, that could include Lead Status, Contact, Account, Campaign Member, Opportunity, Flow, assignment rule, or Apex automation. In HubSpot, document contact and company properties, lifecycle stage, workflows, sequences, lists, and lead ownership. In Account Engagement, capture prospect status, automation rules, completion actions, scoring, grading, and the connector behaviour that passes information into Salesforce.
Lifecycle definitions need particular care. “Marketing qualified” might be a field value in one system, a calculated threshold in another, and a sales acceptance event in a third. Record the exact condition that moves a record forward, who can change it, and what happens when the condition isn't met.
The same discipline applies to routing. Document the source field, normalisation, rule order, territory logic, fallback queue, notification method, and owner response. If a company needs a specialised BDR motion, the map should show where the BDR receives the record, what information arrives with it, and how acceptance is recorded.
Add measurement to every step
A map without indicators is a presentation. California's Business Process Re-engineering guidance recommends baselining measures such as cycle time, backlog, errors and exceptions, costs, waste, handoffs, and volume, then using peer benchmarks to sanity-check target values in the state's BPR guidance. You don't need every measure for every workflow, but you do need enough to distinguish a slow process from a busy team or a broken rule.
For each step, ask:
- What enters the step: Which object, event, or field value starts it?
- What leaves the step: Which update, notification, assignment, or decision proves completion?
- What can fail: Which missing value, permission, integration, or exception sends work off path?
- What can be measured: Which timestamp, count, error, or queue state exposes performance?
Practical distinction: A process map decorates a slide when it describes activities. It enables measurement when every activity has a system event, an owner, an exit condition, and an exception path.
Documenting this way produces a usable business process mapping example rather than a polished approximation. It also makes later root-cause analysis faster because the team already knows where to retrieve proof.
Collecting System Evidence Instead of Opinions
Most gap analyses weaken during evidence collection. Teams hold workshops, ask participants to rate process maturity, and record statements such as “routing is inconsistent” or “sales doesn't follow up quickly.” Those observations may identify a symptom, but they don't prove where the workflow failed or whether the problem is systemic.
Build an evidence pack from the platforms first. Pull workflow histories, routing rule versions, field audit trails, automation errors, integration logs, queue records, and activity timestamps. Then use interviews to explain anomalies, not to replace system evidence.
Log the full handoff chain
For lead management, capture the complete sequence:
- Capture: When did the form, import, event, or campaign create the record?
- Enrichment: When were firmographic, intent, account, or contact fields added?
- Assignment: Which rule assigned ownership, and when?
- Notification: When did the system alert the owner or queue?
- First contact: When did a representative record a qualifying activity?
One practical lead-routing framework also recommends recording the fired rule, fallback reason, and rep workload alongside those timestamps in its lead-routing measurement guidance. That chain separates capture delay from enrichment delay, assignment delay, notification failure, and rep capacity. A dashboard that only shows created date and owner can't make those distinctions.
Use exports when the platform interface hides the necessary detail. A controlled Salesforce data export process can preserve record IDs, field history, ownership changes, activity dates, and error context for analysis. Protect access and document filters, because an evidence pack is only defensible when another analyst can reproduce how it was assembled.
Make findings citable
Attach a record ID, workflow name, rule version, screenshot, policy ID, or error message to every material finding. Screenshots help explain configuration to executives, while exports and logs prove frequency and sequence. Keep the two together. A screenshot shows what the system was configured to do, but an event record shows what it did for a real transaction.
Check data readiness before drawing conclusions. California-focused research from Stanford describes limited data infrastructure and variation in access and capacity to use data for continuous improvement, and reports that nearly half of interviewed districts said no outside entity was helping them implement continuous improvement in its California brief. The RevOps implication is direct: confirm that frontline teams can see the relevant status, timestamps, and exception reason in real time. If they can't, the process may be failing partly because the organisation lacks the instrumentation needed to manage it.
Identifying Gaps and Running Root-Cause Analysis
A gap exists only after you compare an evidence-backed current state with a defined target state. “Leads are routed poorly” isn't a useful entry. “Records with a populated territory value reach the correct owner, while records with an unnormalised value enter the fallback queue” is testable, assignable, and fixable.
Separate the gap register into categories because each category points to a different remedy:
- Missing process steps: The target requires an approval, validation, or acceptance event that the current workflow never performs.
- Data-quality gaps: Required fields are blank, duplicated, stale, inconsistently formatted, or stored in the wrong object.
- Broken handoffs: A record changes state, but ownership, notification, context, or service-level tracking doesn't travel with it.
- Ownership gaps: Teams disagree about who acts, who approves, or who maintains the rule.
- Automation gaps: A flow, workflow, connector, or trigger fires late, fails, conflicts with another automation, or lacks an exception path.
Trace the failure to its source
Routing provides a straightforward example. A territory rule can misfire when a State field contains “California,” “CA,” “ca,” and “Calif” as separate values. The remediation is upstream validation, a controlled picklist, or normalisation before routing, as outlined in lead-routing field standardisation guidance. Changing the assignment rule alone treats the symptom while leaving the inconsistent input intact.
Use the five whys, but attach every answer to evidence. If a lead reached the fallback queue, ask why. The log may show that the territory rule didn't match. The field history may show an unstandardised value. The form configuration may reveal free-text entry. The governance record may show that nobody owns the allowed-value list. The root cause may therefore be field design and ownership, not rep behaviour.
Distinguish three causes that often look identical in a dashboard:
- Process delay: The workflow contains a step, but the sequence or trigger is inefficient.
- Policy delay: The system is waiting for an approval, eligibility check, or compliance decision.
- Resource constraint: The process works as configured, but a queue, team, or owner lacks capacity.
Weak documentation and inconsistent ownership frequently create the most persistent gap. A process can contain every nominal step and still produce unreliable outcomes because no one maintains the definitions, monitors exceptions, or decides which team owns a disputed record.
Build a defensible gap register
Each entry should include the current evidence, target requirement, observed consequence, category, root cause, affected systems, owner, risk, and recommended action. Add a confidence level based on the quality of the evidence, not the confidence of the loudest participant.
For teams that need a broader operating-model lens, this guide to smart process optimization is useful alongside system-level diagnostics. It can help frame the relationship between workflow design, accountability, and improvement without allowing a high-level framework to substitute for Salesforce, HubSpot, or Account Engagement records.
Prioritizing Fixes and Building the Remediation Roadmap
A gap register is diagnostic. Leadership needs a sequence of decisions. Prioritize each item using business impact, effort, and risk, then validate the score with the system evidence. This prevents the roadmap from becoming a list ordered by the person who complained most recently.
Quick wins often belong first, but only when they don't create hidden structural debt. Normalising a routing field, correcting a rule condition, adding an error notification, or making an owner visible can stabilise flow quickly. A lifecycle redesign, object-model change, integration replacement, or Revenue Cloud architecture decision needs more discovery and controlled testing.
Use a transparent scoring conversation
| Gap Category | Business Impact | Effort to Fix | Priority |
|---|---|---|---|
| Invalid routing values | High, because records can reach the wrong owner or fallback queue | Low to medium, depending on form, integration, and historical data changes | Immediate |
| Missing handoff timestamps | Medium to high, because teams can't prove delay or accountability | Medium, requiring field, automation, and reporting changes | High |
| Conflicting lifecycle definitions | High, because reporting and qualification decisions diverge across platforms | High, requiring governance and cross-platform redesign | High |
| Automation exception handling | Medium to high, because failures can remain invisible | Medium, requiring error paths, alerts, and ownership | High |
| Documentation without system enforcement | Medium, because staff may follow different versions of the process | Low to medium, requiring governance, training, and control points | Planned |
The matrix is a starting point, not a mathematical verdict. Increase priority when a gap creates regulatory exposure, affects a high-value handoff, or prevents the organisation from measuring the rest of the funnel. Lower it when evidence is weak and the consequence is limited, but assign an owner to improve the evidence rather than allowing uncertainty to disappear.
Turn each fix into a runbook
A remediation runbook should name the accountable owner, affected objects and fields, configuration changes, test records, acceptance criteria, deployment window, monitoring period, and rollback plan. For Salesforce, specify whether the change affects Flow, validation rules, assignment rules, Apex, permissions, or reports. For HubSpot and Account Engagement, identify the workflows, properties, lists, scoring logic, connector settings, and suppression or exception rules involved.
Set hard data-quality targets. Generic instructions such as “clean the CRM” can't be approved or tested. Current CRM guidance places duplicate rates below 5% as a practical threshold and describes under 3% as good, 3% to 5% as acceptable, 10% to 20% as poor, and duplicate rates above 15% as a stop-and-fix priority, in this data-quality benchmark. Use only the thresholds that fit your governance policy, define the measurement method, and assign someone to monitor the result.
Phase the roadmap around dependencies. Stabilise inputs and ownership first, repair routing and exception visibility next, then redesign lifecycle logic or integration architecture. A clear sequence gives leadership a plan it can fund without pretending every gap has the same urgency.
Measuring Results and Making the Changes Stick
Most gap analyses fail after delivery. The report identifies the issue, the admin deploys a fix, and the organisation returns to the same dashboards without checking whether the process improved or merely changed shape.
Define the proof of success before deployment. A routing repair may require accurate owner assignment, visible fallback reasons, and reduced handoff latency. A lifecycle redesign may require consistent stage transitions, reliable conversion reporting, and an agreed definition across marketing and sales. A service handoff may need response timing, ownership acceptance, and escalation visibility.
Build measurement into the operating rhythm
Use dashboards that show the process, not just the outcome. A useful GTM view can combine:
- Handoff latency: Time between assignment, notification, acceptance, and first action.
- Routing accuracy: Correct owner, fallback frequency, and unassigned records.
- Stage integrity: Records that meet the required entry and exit conditions.
- Exception volume: Failed automations, rejected synchronisations, missing fields, and duplicate creation.
- Ownership health: Records without accountable owners, stale queues, and unresolved exceptions.
Review the metrics with the people who can change the process. Marketing operations may own capture and nurture logic, sales operations may own routing and acceptance, and the CRM administrator may own configuration quality. If the dashboard has no named decision-maker, it will become another reporting surface rather than a control.
Design for continuity
Training isn't a launch email. Representatives need to know what changed, why it changed, where to find the status, and what to do when an exception appears. Administrators need documented ownership for fields, workflows, integrations, picklists, lifecycle definitions, and reports. Without that governance, the next campaign, territory change, or tool migration can recreate the same gap.
California's Department of Consumer Affairs shows what institutionalised process analysis looks like at scale. Its Business Modernization 2021 Annual Report recorded 89 As-Is process maps, 90 Could-Be process maps, and 341 functional requirements as of August 2021. The lesson for RevOps isn't to copy the counts. It's to treat mapping and requirements as repeatable governance milestones rather than a one-time consulting deliverable.
A 2026 California Natural Resources Agency Lean Six Sigma assessment of Timber Harvest Plan workflows recommends a “workflow roles and responsibilities gap analysis” and connects the review to DMAIC and multiple data-collection methods, as described in the CNRA assessment. That public-sector example reinforces a useful RevOps principle: clarify accountability and inspect the workflow before buying another tool.
Operating principle: Process gap analysis isn't a one-off report. It's a repeatable control system for messy GTM operations, with evidence, ownership, measurement, and review built into normal management.
A practical first-90-days checklist
- Days 1 to 30: Select one process slice, define the target state, name owners, and collect record-level evidence.
- Days 31 to 60: Publish the gap register, confirm root causes, approve the priority sequence, and test the first remediation in a controlled environment.
- Days 61 to 90: Deploy approved fixes, launch the dashboard, train affected teams, review exceptions, and schedule the next control review.
Teams ready to run their first cycle should start with one high-friction handoff rather than a full-funnel transformation. Document the evidence, assign the fix, measure the result, and use the findings to decide whether the next analysis belongs in Salesforce, HubSpot, Account Engagement, Service Cloud, Revenue Cloud, or the integration layer between them.
MarTech Do can audit your Salesforce or HubSpot processes, lifecycle stages, routing rules, automation, integrations, data quality, and reporting, then turn the evidence into an owned RevOps remediation roadmap. Visit MarTech Do to discuss a focused process gap analysis and the next practical fix for your GTM operation.
