Revenue Operations Manager Interview Preparation Guide - Mid Level (FAANG Standard)

I would evaluate and implement each routing strategy depending on coverage goals, ARR motion, and SDR capacity. Below are the three approaches with CRM configuration, pros/cons, and one monitoring metric per strategy.

1) Territory-based (by geography / account segments)
CRM configuration:

• Territory model with geo fields (country/region/state) + account segment tags; territory assignment rules in Salesforce/Microsoft Dynamics; automation (Flow/Process Builder/Power Automate) to assign owner; territory hierarchy and quota roll-ups.
  Pros:
• Aligns reps to local markets and time zones; improves relationship/context.
• Simplifies forecasting and quota management by territory.
  Cons:
• Coverage gaps when demand is uneven across regions; rebalancing needed as company grows.
  Monitoring metric: Territory coverage ratio = leads assigned in territory / total inbound leads for territory (target ~100% within SLA).

2) Account-based (named accounts / owned accounts)
CRM configuration:

• Account ownership model, account lists (ABM tags), lead-to-account matching rules, routing rule: favor assigned account owner; fallback owner or ABM pod assignment if owner not available.
  Pros:
• Consistent owner relationship for high-value accounts; higher conversion for named accounts.
  Cons:
• Risk of unassigned or stale owners; slower response if owner is overloaded.
  Monitoring metric: Named-account SLA adherence = % inbound leads for owned accounts responded to within SLA.

3) Round-robin queueing (balanced load across SDR pool)
CRM configuration:

• Lead queue object, round-robin assignment automation (Apex/Functions or native queue settings), capacity caps, skip/overflow rules, assignment logs for audit.
  Pros:
• Even workload distribution; easy to scale and fair.
  Cons:
• Less contextual ownership; can assign low-fit reps to strategic accounts.
  Monitoring metric: Assignment fairness Index = variance (or Gini) of leads assigned per SDR per week (target low variance) plus SLA response time.

I’d pair any strategy with weekly dashboards (assignment counts, SLA response times, conversion by route), audit logs, and periodic rebalancing rules to ensure coverage and ROI as the business scales.

Brief framing (goal)
I would replace brittle spreadsheets with a repeatable, auditable forecasting pipeline that improves accuracy, reduces manual edits, and gives stakeholders transparent assumptions.

Model choice & approach

• Hybrid ensemble: baseline time-series (Prophet or ETS) per segment + machine-learning uplift (XGBoost/LightGBM) that ingests drivers (pipeline, win rates, seasonality, marketing spend).
• Use hierarchical forecasting to reconcile product/region/channel to company-level and allocate roll-ups automatically.

Data inputs & feature engineering

• Source canonical CRM/opps, billing, marketing spend, lead quality, rep-level activity, product usage signals.
• Create features: weighted pipeline stages, aging, conversion velocities, cohort retention, seasonality flags, macro indicators.
• Implement data quality checks (completeness, schema, freshness) before modeling.

Validation & backtesting

• Walk-forward backtests, rolling windows, and calibration by segment and rep.
• Metrics: MAPE, RMSE, bias, and percentile coverage for prediction intervals.
• Develop a performance dashboard showing historical errors and drivers of misses.

Governance for model changes

• Version control for data schemas and model code (Git).
• Change approvals: data owner + RevOps + Finance sign-off for production deploy.
• Maintain model registry with lineage, validation reports, and rollback plan. Schedule quarterly model reviews and ad-hoc when error thresholds exceed SLA.

CI/CD & deployment

• Automated ETL (Airflow) to prepare features; unit/integration tests for data and model.
• CI pipeline runs tests and backtests; CD deploys containers (Docker) to staging; promote to production with canary forecasting for a week.
• Expose forecasts via APIs and a BI layer (Looker/Tableau) with editable assumption inputs for scenario analysis; preserve audit trail of manual overrides and feed into next retrain.

This plan balances accuracy, transparency, and operational control so RevOps can trust forecasts and reduce weekly spreadsheet firefighting.

Overview (role context)
I will lead a 3-month phased Lightning adoption focusing on minimizing pipeline disruption, ensuring data integrity, and driving user productivity across Sales, SDRs, CS, and Revenue Ops.

Month 0 — Governance & Prep (Weeks 0–2)

• Executive sponsor: VP Revenue; Steering committee: Sales, CS, Marketing, IT, Legal, RevOps.
• Lightning PM: me (RevOps) + Admin lead. Weekly steering cadence.
• Inventory: critical pages, custom components, Apex, integrations; create compatibility backlog and rollout risk register.

Pilot Strategy (Weeks 3–6)

• Pilot groups: 10 SDRs (high-frequency, low customization), 5 AEs (top reps using custom objects), 3 CS CSMs, 2 RevOps admins = ~20 users.
• Scope: core Sales Console, Leads->Opportunities flows, dashboards. Enable feature flags for roll-forward. Collect UX issues and change requests.

Training Cadence & Channels

• Week 1 pilot onboarding: role-based 90-min hands-on sessions + quick-start cheatsheets.
• Ongoing: weekly 30-min drop-in clinics, recorded micro-videos (2–6 mins), in-app guidance (WalkMe/Guided Actions), Slack channel + office hours.
• Full rollout: role-specific 1-hour workshops + sandbox practice.

Success Metrics

• Adoption: 90% of active users on Lightning within 4 weeks post-rollout.
• Productivity: no >5% negative delta in closed-won velocity or activities logged.
• Quality: <2% increase in data errors, ticket volume to helpdesk within expected bounds. Net Promoter Score for UX ≥+10 post-30 days.

Key Communications

• Executive announcement + timeline, weekly pilot summaries, change highlights for reps, go/no-go emails 72/24 hours before waves, post-rollout wins and FAQ updates.

Contingency Plans

• If major blockers appear: pause rollout, rollback affected profiles to Classic feature flag, accelerate hotfix sprint, expand pilot with power users for validation, extend training and office hours. Escalate to steering committee for decision within 48 hours.

I’ll track risks, report weekly, and iterate based on metrics and user feedback to ensure a smooth revenue-safe migration.

Direct answer

Randomize at the individual-lead level to maximize sample size and avoid rep-level imbalance, define false-positive rate as a co-primary metric alongside qualification time so a faster script that lets bad leads through doesn't look like a win, and monitor per-rep behavior explicitly because reps, not leads, are the most likely source of hidden bias in this design.

Structured elaboration

Randomization

Assign each incoming lead to control (current script) or treatment (shorter script) at routing time, 1:1, stratified by lead source and rep experience so the two arms stay balanced on the factors most likely to affect both qualification time and quality.

Sample size

Target detecting a 10-15% relative reduction in mean qualification time at 80% power and alpha of 0.05. The standard two-sample size formula, per arm, is:

Here $z_{\alpha/2}$ is the z-score for the two-sided significance level (1.96 for alpha = 0.05), $z_{\beta}$ is the z-score for the target power (0.84 for 80% power), and $\sigma$ is the standard deviation of qualification time in minutes, estimated from historical data or a short pilot. Plugging in illustrative numbers: if the current script's qualification time averages 25 minutes with a standard deviation of 10 minutes, and the target is the conservative end of the range above, a 10% relative reduction ($\Delta = 2.5$ minutes), then $n = 2(1.96+0.84)^2 (10)^2 / (2.5)^2 \approx 251$ leads per arm, which is why the 200-400 floor below lands where it does rather than being an arbitrary round number.

If baseline variance is unknown, run a one-week pilot to estimate it before committing to a final sample size, rather than guessing. As a practical floor, 200-400 leads per arm is a reasonable heuristic minimum for this kind of test.

Metrics

• Primary: mean qualification time (minutes per lead).
• Co-primary (safety): false-positive rate, the share of leads marked qualified that never convert to opportunity within a fixed window.
• Secondary: conversion-to-opportunity at 14 and 30 days, downstream win rate, and rep handling time per day.

Statistical criteria

A two-sided test for time (t-test, or a non-parametric alternative if the distribution is skewed) and a proportion test for false positives. Declare a win only if qualification time drops significantly (p < 0.05) AND the false-positive rate does not rise beyond a pre-agreed non-inferiority margin, for example plus 2 percentage points, confirmed with a 95% confidence interval, not just a point estimate.

Bias mitigation and detection

Monitor per-rep assignment balance and adjust with covariate regression controlling for rep, lead source, and experience. Present the test to reps as a routine operational change rather than naming the hypothesis, to reduce behavior change from reps who know they're being measured. Run rep-level subgroup analysis specifically to catch gaming, a rep whose false-positive rate spikes relative to peers is a signal worth a manual audit, and pre-register a stopping rule for that case rather than deciding ad hoc mid-test.

Variant: automated lead-to-rep matching

A related pilot-design problem swaps the treatment: instead of a shorter script, an algorithm decides which rep a lead is routed to. The scope narrows to segment and region, rolling out to two or three regions rather than randomizing individual leads, because the matching logic operates at the rep-pool level, not the lead level. The same sample-size heuristics apply: estimate baseline variance from a one- to two-week window, then size for the target detectable effect using the same formula above. The dominant new risk is wrong assignment, a lead routed to a rep without the right language, industry, or product expertise, and the rollback plan for that risk is a manual-override queue plus a same-day re-routing SLA (service-level agreement) so a bad match doesn't sit unserved, with a kill switch that reverts all routing to the prior rule-based system if the wrong-assignment rate crosses a predefined threshold.

Trade-offs and pitfalls

A shorter script that hits its time target by asking fewer disqualifying questions will show up as a false-positive-rate increase eventually, but if the measurement window closes before leads have had time to convert or fail to convert, the test can declare victory on a script that's quietly passing bad leads downstream. Blinding reps to the hypothesis reduces behavior change but isn't perfect: reps often notice a shorter call flow regardless of what they're told, so subgroup monitoring is a backstop, not a substitute for a clean design. And randomizing at the lead level, while it maximizes power, can let a single rep work leads from both arms, which is exactly the contamination risk the per-rep monitoring step exists to catch.

Approach (high-level)
I’d implement a hybrid pipeline: deterministic rules first (high-precision merges), then a probabilistic model for remaining candidate pairs, with human-in-the-loop (HITL) review for ambiguous scores. This balances revenue safety (avoid false merges) with deduplication efficiency.

Deterministic rules (fast, high precision)

• Exact email match (when present) + non-conflicting billing ID
• Exact phone match + same country code
• Same external customer ID (billing or payment token)

Probabilistic model (features)

• Email: normalized, domain match, local-part levenshtein
• Phone: E.164 normalized, edit distance, carrier/country match
• Name: first/last token match, phonetic (Double Metaphone), Levenshtein ratio
• Company domain: domain match, subdomain similarity
• Address: postal normalization, geo distance
• Behavioral/IP: last seen IP hash, overlapping sessions, device fingerprint similarity
• Interaction metadata: timestamps, conversion path overlap, marketing cookie IDs
• Source/system confidence: origin system weight (billing > CRM > marketing)

Training & evaluation

• Label data from historical merges and manual adjudications; synthesize negatives by pairing unlikely records.
• Train a gradient-boosted tree (e.g., XGBoost) outputting match probability and feature importances.
• Metrics: precision@threshold, recall, ROC-AUC, and business KPIs (revenue at risk, merge rollback rate). Optimize for high precision (e.g., >=98%) at auto-merge threshold.

Thresholding & actions

• Score >= 0.98 → auto-merge (deterministic fallback checks)
• 0.7–0.98 → queue for HITL review with explanations
• < 0.7 → no action; suggest potential link for downstream segmentation only

Human-in-the-loop workflow

• Reviewer UI shows record side-by-side, top feature contributions, history, risk flags, and “confidence rationale.”
• Allow actions: confirm merge, reject, link (soft), escalate for legal/finance (billing conflicts).
• Capture reviewer decisions to retrain model; prioritize ambiguous cases with high revenue impact.
• Periodic calibration: review sample of auto-merges, monitor rollback rate, adjust thresholds.

Governance & ops

• Audit trail for every merge, reversible via controlled rollback.
• Daily monitoring dashboard: merge volumes, false-positive rate, revenue affected.
• Cross-team SOPs: billing wins on contractual identifiers; marketing dynamics preserved in linked timeline.

This approach protects billing integrity while improving unified customer view for revenue teams, with measurable feedback loops to continuously improve matching quality.

Direct answer

My review process is the same shape whether the missed target was a shipped feature, a sales deal, or an analysis that didn't land: pull the actual evidence before the conversation rather than relying on memory, keep the room to the people who were actually close to the work, and end with a small number of specific, owned, tracked actions rather than a document full of general lessons nobody is accountable for.

What I actually do

Before the review, gather the real evidence. I pull whatever record exists of what actually happened: timelines, decisions made along the way, the original target and assumptions, rather than relying on how people remember it a week later, since memory tends to smooth over the specific decision points that actually mattered.

Keep the room small and close to the work. I include the people who were directly involved and whoever owns the target that was missed, and generally avoid a large audience, since a bigger room tends to produce more defensiveness and less specific, honest detail.

Ask a small set of standing questions regardless of what kind of work it was. What did we expect to happen and why did we expect that. Where did reality diverge from that expectation, and how early could we have noticed. What would have changed the outcome if we'd known it in time. I ask these the same way whether the missed target was a delivery deadline or a deal that didn't close, since the shape of a useful review doesn't actually depend on what kind of work it was.

Convert findings into a small number of owned actions, not a document. I resist letting the review end in a list of general lessons like "communicate earlier." Every real finding gets turned into one specific action with a name attached and a way to check later that it actually happened, and I deliberately cap the list short, usually two or three items, because a long list of actions is a sign none of them will actually get done.

Make sure the conclusions show up in the next piece of work, not just the next document. If a review concludes I was missing a specific skill or piece of context, I turn that into a concrete, time-boxed plan with something checkable at the end of it, so I can tell later whether the gap actually closed.

Worked example

A feature I owned to reduce signup drop-off missed its target badly: we'd projected a meaningful lift in completed signups within two weeks of launch, and by day ten we were sitting at roughly a third of that. Before the review, I pulled the actual daily completion numbers, the original rollout plan, and the two decisions we'd made along the way about which user segment to launch to first, rather than trusting how the team remembered the sequence a week later. I kept the room to the three people who'd built and shipped it plus the manager who owned the target, five people, not the wider team. Working through the standard questions, we traced the gap to two things: the in-product prompt explaining the change to users had shipped a week late, and the segment we'd launched to first turned out to overlap heavily with people who rarely touched that part of the product at all, so even a working feature had almost nobody in front of it. Both were visible in the data if anyone had checked mid-launch, and nobody had. That turned into three owned actions: I took the mid-launch data check-in for my own future rollouts, with a specific date attached; the engineer who owned the prompt copy moved it into the same release checklist as the code so it can't ship late again; and the PM agreed to sanity-check target audiences against real usage data before picking one next time. Two launches later, the mid-launch check-in caught a similar prompt delay early enough to fix it before it cost the whole window, which is the actual evidence the review changed something, not just a document that described it well.

Trade-offs and pitfalls

The most common pitfall is producing a thorough-looking document that changes nothing, because the findings stayed general enough that no one felt individually responsible for acting on them. The trade-off in keeping the action list short is that some real findings get left out; I accept that, because a long list that nothing gets done on teaches less than a short list that actually changes the next attempt.

Direct answer

The core structure, learn, then contribute, then own, stays the same, but at a seed-stage startup I compress discovery to days, act on thinner evidence, and expect the ground to shift under my plan, while at a large public company I extend discovery, work through more formal process and sign-off before acting, and lean on existing documentation and specialists rather than figuring everything out myself.

Framework

• Discovery speed and depth: at a seed-stage startup, often pre-product-market-fit, there's little or no documentation, a handful of people hold all the context, and I can talk to nearly everyone, including the founders, within the first week. At a large public company already generating stable, predictable ARR (annual recurring revenue), there's more documentation but also more of it is stale or contradictory, and no single conversation gives the full picture, so discovery takes longer and needs multiple rounds with different specialist teams.
• Timelines: at a startup, my day-30 milestone might already be a shipped, customer-facing change, because the company can't afford three months of pure ramp-up. At a large company, day-30 might legitimately still be mostly learning, because the blast radius (how many systems, teams and customers a single mistake actually reaches) of an uninformed early change is much larger. Detection is the second, separate multiplier: more layers of abstraction and more owners sit between the change and whoever would notice it, so the same mistake both travels further and runs longer before anyone catches it. At a startup you usually get neither, which is a large part of why the same change is cheap there and expensive here.
• How fast to push for change: at a startup, especially pre-product-market-fit, I'd push faster and accept more risk, because the cost of being slow, running out of runway, missing a market window, usually exceeds the cost of a wrong but reversible bet. At a large, regulated, or public company, like a financial institution versus a fast-growth consumer startup, I'd push more slowly and go through more formal validation, because the cost of an unreviewed change, a compliance breach, a regression affecting a large existing customer base, is asymmetric and hard to undo.
• What stays constant: I still get explicit agreement from my manager on the plan, still map stakeholders, and still aim for a concrete deliverable, not just activity, by day 90. Only the pacing and risk tolerance shift.
• If the product itself is still changing shape quickly (a variant of the startup case), I'd treat my own 90-day plan as similarly disposable, revisiting it every two to three weeks rather than trusting a plan written on day one to still be right by day 60.

Worked example

At a seed-stage, pre-product-market-fit startup with eight people, my week one includes a 1:1 with literally every person in the company, and by day 10 I've shipped a small but real customer-facing fix, because there's no formal review process and the founders want visible momentum immediately. At a large public company in a regulated space like a financial institution, my first 30 days is almost entirely discovery, reading compliance and architecture documentation and meeting a risk and compliance stakeholder I wouldn't need to involve at all at the startup, and my first proposed change doesn't ship until it clears a formal review process, likely closer to day 60. The plan skeleton is identical, but at the startup "act" starts inside the first week and has already shipped by day 10, while at the regulated company "act" might not start until day 45 and does not ship until closer to day 60.

Trade-offs and pitfalls

Applying startup-speed instincts at a large regulated company reads as reckless and can trigger a real compliance or trust problem. Applying large-company caution at an early-stage startup means the company can run out of time before you've delivered anything. Moving fast at a startup means accepting a higher rate of small, reversible mistakes as the cost of speed; moving slow at a large company means accepting that your early credibility-building takes longer to show results. Both are the right trade-off for their context, misreading which context you're actually in is the real risk.

Brief definition of funnel conversion metrics
As a Revenue Operations Manager I treat funnel conversion metrics as stage-to-stage conversion rates that reveal friction, quality, and capacity issues across acquisition → activation → monetization. They power forecasting, capacity planning, and where to run experiments.

Benchmark ranges

• SaaS self-serve (web acquisition → activation → paid)
  • Acquisition → Activation: 3%–10%
  • Activation → Paid: 2%–8%
  • End-to-end (acq → paid): 0.06%–0.8%
• Enterprise sales (lead → opportunity → close)
  • Lead → Opportunity: 10%–30%
  • Opportunity → Close: 15%–35%
  • End-to-end (lead → close): 1.5%–10%

Ranges vary by price point, channel mix, and ICP.

How I interpret deviations & next actions

• If early-stage rate low (acq→activation or lead→opp): diagnose traffic quality, landing page UX, form friction, source-level CPL; run cohort/source analysis and A/B tests; tighten targeting or lead scoring.
• If mid-stage drops (activation→paid or opp→close): inspect product onboarding, time-to-value, demo quality, sales enablement, pricing objections; instrument funnel with session/interaction analytics and win/loss interviews.
• If close rate low but pipeline healthy: coach sales, update playbooks, adjust qualification criteria, deploy deal-level forecasting signals.
• If rates exceed benchmarks: validate data quality, ensure sustainable CAC and deal economics, and scale the winning channels.

I pair these actions with dashboards, experiments, and OKRs to close gaps within a 30–90 day cadence.

Context & goals (as Revenue Ops)
Ensure marketing→sales→revops workflows that use PII for lead routing/scoring meet GDPR/CCPA: lawful basis, consent propagation, DSAR fulfillment, minimal retention, auditable trails, and vendor compliance without hurting lead velocity.

High-level architecture

• Consent capture at entry: consent banner + granular checkboxes; store consent token with timestamp, source, and retention period in CRM (lead record).
• Central Privacy Service: single source-of-truth API that returns consent status, purpose, and allowed actions to all downstream systems (CDP, marketing automation, sales engagement).
• Event bus for propagation: sync consent changes and DSAR events to systems in near real-time.

Controls & processes

• Consent capture & propagation
  • Capture explicit opt-ins with purpose tags; persist token and S2S verify via Privacy Service.
  • On routing/scoring, call Privacy API to validate allowed processing purposes; block or flag records without consent.
• Data subject requests (DSR)
  • Self-service portal creates DSR ticket; Privacy Service orchestrates erasure/export across vendors using event bus; RevOps owner monitors SLA (e.g., 30 days).
• Data minimization & retention
  • Field-level minimization: store only needed PII for scoring/routing; pseudonymize identifiers where possible.
  • Retention rules per purpose: e.g., marketing leads 24 months of inactivity; automated purge jobs with pre-delete notifications to owners.
• Audit trails & monitoring
  • Immutable audit log for consent changes, DSR actions, data exports/deletes (WORM storage). Expose dashboards with metrics: outstanding DSRs, consent coverage, purge backlog.
• Vendor/processor controls
  • Maintain approved vendor registry with data flows, SCCs/Data Processing Addenda, subprocessors list, security posture, and periodic attestation.
  • Contract clauses: assistance with DSRs, breach notification timelines.
  • Technical: SCIM/SFTP/API connectors to enforce deletes/exports; require transfer of consent tokens.

Trade-offs & implementation

• Latency vs. compliance: cache consent locally for 24h with TTL + revocation webhook to balance routing speed and compliance.
• Quick wins: implement Privacy Service + consent field in CRM, enforce policy in lead-assignment rules; next phase integrate CDP and vendor connectors.

KPIs

• DSR SLA compliance %, consented lead rate, time-to-propagation, number of vendors with signed DPA, audit log completeness.

Approach (brief)
Calculate time-to-first-contact = first non-automated activity timestamp − lead_created_at for leads created in last 90 days; compute percentiles (p10, p25, p50, p75, p90). Handle missing logs by marking as null or using a censoring flag; normalize all timestamps to UTC; cap or winsorize extreme values and report counts.

Pandas implementation

1. Filter leads last 90 days, exclude activities with source = 'system' or user_id IS NULL.
2. Normalize tz, compute first contact per lead, merge to leads, compute delta.
3. Compute percentiles and winsorize outliers.

import pandas as pd

# assume leads_df (id, created_at) and activities_df (lead_id, ts, source, user_id)
leads_df['created_at'] = pd.to_datetime(leads_df['created_at']).dt.tz_convert('UTC')
activities_df['ts'] = pd.to_datetime(activities_df['ts']).dt.tz_convert('UTC')

cutoff = pd.Timestamp.utcnow().tz_localize('UTC') - pd.Timedelta(days=90)
leads_recent = leads_df[leads_df['created_at'] >= cutoff]

# exclude automated pings
acts = activities_df[(activities_df['source'] != 'system') & activities_df['user_id'].notna()]

first_contact = acts.sort_values('ts').groupby('lead_id', as_index=False).first()[['lead_id','ts']]
df = leads_recent.merge(first_contact, left_on='id', right_on='lead_id', how='left')
df['ttfc_hours'] = (df['ts'] - df['created_at']).dt.total_seconds()/3600

# handle missing: mark as NaN and add censor flag
df['censored'] = df['ttfc_hours'].isna()

# winsorize at 99th percentile
upper = df['ttfc_hours'].quantile(0.99)
df['ttfc_winsor'] = df['ttfc_hours'].clip(upper=upper)

percentiles = df['ttfc_winsor'].quantile([0.1,0.25,0.5,0.75,0.9]).to_dict()
counts = {'total_leads': len(df), 'with_contact': df['censored'].value_counts().get(False,0)}

SQL implementation (Postgres)

WITH leads AS (
  SELECT id, created_at AT TIME ZONE 'UTC' AS created_utc
  FROM leads_table
  WHERE created_at >= (now() AT TIME ZONE 'UTC') - interval '90 days'
),
acts AS (
  SELECT lead_id, min(ts AT TIME ZONE 'UTC') AS first_ts
  FROM activities
  WHERE source <> 'system' AND user_id IS NOT NULL
  GROUP BY lead_id
),
joined AS (
  SELECT l.id, l.created_utc, a.first_ts,
         EXTRACT(EPOCH FROM (a.first_ts - l.created_utc))/3600 AS ttfc_hours
  FROM leads l
  LEFT JOIN acts a ON a.lead_id = l.id
)
SELECT
  percentile_disc(0.10) WITHIN GROUP (ORDER BY ttfc_hours) AS p10,
  percentile_disc(0.25) WITHIN GROUP (ORDER BY ttfc_hours) AS p25,
  percentile_disc(0.5)  WITHIN GROUP (ORDER BY ttfc_hours) AS median,
  percentile_disc(0.75) WITHIN GROUP (ORDER BY ttfc_hours) AS p75,
  percentile_disc(0.90) WITHIN GROUP (ORDER BY ttfc_hours) AS p90,
  count(*) AS total_leads,
  count(ttfc_hours) AS leads_with_contact
FROM joined;

Handling specifics

• Missing activity logs: treat as censored; report percent missing; consider using CRM sync logs to reconcile; optionally impute with business rule (e.g., max SLA).
• Timezones: convert all timestamps to UTC on ingest or at query time; store tz-aware datetimes.
• Outliers: cap at 99th percentile or log-transform; always report both raw and cleaned metrics and counts of capped values.

Why this matters for RevOps
Provides accurate SLA and lead response metrics, surfaces data quality issues for system integrations, and supports operational SLAs for sales enablement and forecasting.