Situation
Business Development relied on LeadIQ Contact Tracking for job-change and lifecycle signals. When RevOps removed it during a stack consolidation, the team lost reliable visibility into contact job changes and lifecycle signals.
public case study
Rebuilding contact intelligence after RevOps removed LeadIQ from the stack — designing an internal signal system in Salesforce and Clay that increased tracked contacts by roughly 50x while cutting annual software spend by approximately $30,000.
Business Development relied on LeadIQ Contact Tracking for job-change and lifecycle signals. When RevOps removed it during a stack consolidation, the team lost reliable visibility into contact job changes and lifecycle signals.
Challenge the either/or framing — keep the paid tool or accept less pipeline — and determine whether contact tracking value could be preserved without reintroducing vendor dependency.
Ran stakeholder discovery across RevOps and BD, then designed a modular signal engine in Clay organized by sales motion — champion tracking, new role changes, closed-lost reactivation, customer expansion, and custom campaign signals — with Salesforce as the source of record.
Increased tracked contacts by roughly 50x, restored warm outbound motions, and reduced annual software spend by approximately $30,000 while supporting RevOps consolidation goals.
At Transcend, Business Development used LeadIQ Contact Tracking to identify when prospects changed jobs or hit other key milestones. Those signals helped reps turn historical relationships into timely, relevant outbound.
When RevOps moved to consolidate the tech stack and reduce spend, LeadIQ was removed. The decision made sense operationally, but it created an immediate gap: BD lost reliable visibility into contact job changes and lifecycle signals.
Rather than reintroduce another paid point solution, I designed and implemented an internal contact intelligence system using Salesforce, Clay, and enrichment providers — preserving the business value of contact tracking without preserving the vendor dependency.
The project started with two teams optimizing for different outcomes.
RevOps wanted to:
Business Development wanted to:
The initial framing was a tradeoff: keep LeadIQ and preserve signal coverage, or remove LeadIQ and accept fewer tracked contacts. My role was to determine whether we could preserve contact tracking value on better terms.
I interviewed stakeholders across RevOps and Business Development to understand what the team actually needed from the existing workflow.
Discovery clarified that the team did not need a like-for-like LeadIQ replacement. They needed a reliable way to identify actionable buying signals from contacts and accounts they already cared about — shifting the project from “replace a tool” to “design a signal system.”
I built a modular signal engine in Clay that monitored contacts across lifecycle events and routed them into campaign-specific workflows. Instead of one generic contact-change feed, the system organized around distinct signal archetypes — each representing a different sales motion with its own prioritization logic.
Identified when former champions joined new companies, letting reps reopen relationships at accounts where trust already existed.
Detected when existing contacts changed responsibilities, seniority, or departments — moments where privacy, data governance, or consent infrastructure might become newly relevant.
Tracked contacts from previously closed-lost opportunities and surfaced changes that justified a new conversation — leadership movement, company growth, department changes, or new responsibilities.
Monitored customer stakeholders for movement across the organization or into new roles, creating expansion and cross-sell opportunities.
Custom campaign signals supported additional outbound programs by turning Salesforce and enrichment data into configurable signal logic — so BD could prioritize by relevance instead of treating every contact change equally.
Salesforce
Source of record
Clay orchestration
Signal engine
Campaign routing
Core components included:
The architecture was intentionally flexible. Because signal logic lived in Clay, new signal types could be added without purchasing another vendor tool or waiting on a heavier RevOps build cycle. Reps and operators also gained visibility into how signals were created — inspectable logic instead of opaque third-party alerts.
Business impact
Operational impact
The project worked because it reframed the problem. The original question was “How do we replace LeadIQ?” The better question was “What decisions are reps trying to make, and what signals help them make those decisions?” Once framed around rep decision-making rather than vendor replacement, the solution became more effective, more flexible, and less expensive.
Software replacement projects become more powerful when they start with workflow understanding instead of feature parity. Rebuilding LeadIQ directly would have been narrower and less defensible. Focusing on the underlying sales motion produced a system that better matched how the team actually generated pipeline.
This reinforced GTM engineering as a bridge between RevOps constraints and sales execution. The right solution was not simply an automation — it was a business system that translated stakeholder needs into reusable signal infrastructure.
This case study abstracts the implementation and uses sanitized examples. It does not include customer records, proprietary Clay table logic, enrichment provider contracts, internal Salesforce configuration, or private routing rules.