ELT pipelines, governed business metrics, and CRM activation. A large enterprise cybersecurity organization wanted to make account-level intent signals usable by field teams. Marketing, CRM, digital engagement, and third-party intent data existed across separate systems, making it hard to consistently identify which target accounts were actively engaging — and to route those signals to sellers quickly. I led the cross-functional program that brought those sources into a governed cloud analytics flow, aligned Sales and Marketing on common engagement definitions, coordinated Data Engineering and CRM delivery, and moved the resulting signals into the sellers’ existing Salesforce workflow.
Case study snapshot
The business problem
Sales and Marketing already had useful information — third-party account intent, website engagement, campaign activity, and CRM accounts and opportunities. But those signals lived in separate systems.
Teams couldn’t easily combine external intent with first-party engagement and CRM account information.
Marketing, Sales, and Analytics did not initially agree on what qualified as a meaningfully engaged account.
Even useful analytics were unlikely to create value if sales representatives had to leave Salesforce to find them.
Program scope
Scoped around six capabilities.
Bring approved intent, digital engagement, and CRM data into the central cloud data platform.
Normalize source fields and create consistent account-level identifiers.
Associate engagement signals with CRM target accounts using agreed, deterministic business rules.
Create shared engagement tiers and definitions that Sales, Marketing, and Analytics could consistently interpret.
Validate freshness, completeness, required fields, and pipeline execution before downstream consumption.
Expose relevant intent signals inside the seller workflow rather than forcing users into another reporting application.
I led the program across them. Implementation ownership was distributed — my role was coordination, decisions, and delivery, not building every component.
| Team | Primary responsibility |
|---|---|
| TPM / Program Lead | Program plan, requirements, dependencies, decisions, RAID, readiness, rollout |
| Data Engineering | Source ingestion, transformations, orchestration, data-quality implementation |
| Analytics | Business metric logic, engagement definitions, validation |
| CRM / Salesforce Engineering | Salesforce fields, account-page integration, seller workflow |
| Marketing Ops / ABM | Intent use cases, target-account requirements, business definitions |
| Sales Ops / BDR pilot users | Workflow requirements, UAT, usability feedback, adoption |
| External data provider | Third-party intent feed and API / interface support |
Security and platform teams supported access, credentials, environment controls, and production readiness where required.
The distinction that matters
My job was not to personally build every pipeline. My job was to make sure the business definitions, source dependencies, engineering work, quality controls, downstream integration, and rollout converged into one usable production capability.
Simple ELT architecture
The solution primarily followed an ELT pattern: source data was extracted and landed in the cloud data platform before standardization and business transformations were applied downstream. That gave us retention of source-level data for troubleshooting, easier replay when transformation logic changed, centralized transformation logic, and a clean separation between ingestion and business rules.
Program sequence
Objective: help field teams identify target accounts showing meaningful buying activity, and make those signals available inside their normal workflow. TPM: stakeholder identification, initial requirements, KPI alignment, scope definition, success measures.
Sources: third-party intent, first-party digital engagement, CRM account data. TPM: source-owner identification, access dependencies, refresh requirements, interface constraints, security dependencies, availability risks. Source & Dependency Register
Teams initially interpreted account engagement differently. TPM: facilitated a Sales + Marketing + Analytics workshop, captured competing definitions, converted ambiguity into agreed engagement tiers, obtained approval, documented centrally. KPI Dictionary Decision Log Requirements Traceability
Architecture and Data Engineering determined the source-to-consumption flow. TPM: architecture-review cadence, dependency identification, decision tracking, milestone alignment, non-functional requirement tracking. Architecture Decision Log Integrated Program Plan
Data Engineering implemented ingestion and transformations. TPM: source readiness, environment dependencies, sequencing, blockers, testing entry criteria, cross-team milestones. Quality controls: required fields, data freshness, completeness, schema validation, failed-run alerts.
Analytics and business stakeholders reviewed whether the account-level signals made sense. TPM: reconciliation issues, metric discrepancies, business validation, defect ownership, decision escalation. Data Quality & Reconciliation Matrix
The first version exposed signals through Tableau reporting. Technically, the capability worked — adoption did not. Usage dropped after the initial dashboard rollout because sellers spent their working day in CRM, not another analytics interface.
Rather than treating this as a training issue, I ran pilot-user feedback sessions. The information was useful; the delivery surface was wrong. CRM Engineering exposed the most relevant account-level intent inside Salesforce. TPM: decision framing, scope adjustment, dependency coordination, rollout planning, UAT, stakeholder communication.
A third-party interface change later disrupted a scheduled ingestion run. Instead of treating it as an isolated incident, the program strengthened the interface boundary. Data Engineering implemented schema validation, required-field checks, and failure alerts. TPM: RCA discussion, vendor coordination, remediation ownership, readiness criteria, operating follow-up.
Three key program challenges
Sales, Marketing, and Analytics were using different interpretations of account engagement. The risk: the platform could technically produce data while users distrusted what the numbers meant.
Facilitated a cross-functional definition workshop and converted the disagreement into explicit engagement tiers and documented business rules.
KPI / Data Dictionary.
Data pipelines cannot compensate for undefined business semantics.
Initial Tableau usage declined after launch. The program could meet its technical requirements but still fail to produce business adoption.
Conducted targeted pilot-user interviews and found that sellers wanted the intelligence inside Salesforce. Worked across Data Engineering, CRM Engineering, Sales Ops, and Marketing to change the delivery model.
UAT / Adoption Feedback Log.
Where data lands in the user’s workflow is a functional requirement, not a change-management detail.
A change in the external data provider’s interface caused an ingestion failure. Upstream changes could create delayed or incomplete downstream analytics without immediate visibility.
Coordinated the vendor and Data Engineering teams to establish clearer interface expectations, schema validation, and automated failure notification.
External Dependency Register + Interface Validation Criteria.
External feeds should be treated as dependencies that can fail, not trusted inputs.
Governance & TPM artifacts
| Artifact | Why it mattered |
|---|---|
| Program Roadmap | Connected business milestones with engineering delivery |
| Source & Dependency Register | Exposed upstream systems and blocking dependencies |
| KPI / Data Dictionary | Prevented semantic disagreements |
| RACI | Clarified ownership across Data, CRM, Marketing and Sales |
| Decision Log | Captured metric, architecture and rollout decisions |
| RAID Register | Managed risks, issues, assumptions and dependencies |
| Data Quality / Reconciliation Matrix | Defined what “trusted data” meant |
| UAT & Production Readiness Checklist | Established release gates |
Each artifact existed to resolve a specific coordination, ownership, quality, or decision problem.
Outcomes
The delivery surface changed from Tableau to CRM, so pre/post activity was measured through different system events. Treat the comparison as directional rather than a controlled adoption experiment.
What I intentionally do not claim
I don’t attribute win-rate, pipeline-generation, or revenue improvement directly to this platform. Those outcomes are influenced by sales execution, market conditions, campaign strategy, account selection, product changes, pricing, and territory changes. Without a controlled experiment, those effects can’t be cleanly isolated — so I don’t claim them.
What I would do differently
The early program focused heavily on which signals mattered, how they’d be standardized, and how account engagement would be represented. We spent less time asking “where does a seller actually need this information during their workday?” Five early interviews with pilot users would likely have identified Salesforce as the correct delivery surface before the Tableau rollout.
Takeaway: I now validate the consumption workflow during discovery, not after initial launch. User workflow is part of system design.
Technology context
Technologies are shown for architectural context; implementation ownership was distributed across the engineering teams described above.