DoorDash Revenue Operations Manager (Mid-Level) Interview Preparation Guide

Clarifying scope & goals
Design a 3NF warehouse schema to provide a single source of truth for ARR/Bookings attribution and churn analysis across CRM, Marketing, Billing, and CS.

Core tables / entities

• dim_customer (customer_id PK, name, account_owner_id, industry, created_date, customer_tier)
• dim_account_hierarchy (account_id PK, parent_account_id, account_type)
• dim_date (date_key PK, date, month, quarter, year)
• fact_opportunity (opp_id PK, customer_id FK, stage, amount, close_date_key FK, lead_source, campaign_id)
• fact_lead (lead_id PK, customer_id FK nullable, created_date_key FK, source, campaign_id, status, converted_opp_id)
• fact_invoice (invoice_id PK, customer_id FK, invoice_date_key FK, amount, currency, invoice_type, billing_period_start, billing_period_end, recognized_date_key FK nullable)
• fact_payment (payment_id PK, invoice_id FK, customer_id FK, payment_date_key FK, amount, method)
• fact_cs_touchpoint (touch_id PK, customer_id FK, touch_date_key FK, touch_type, sentiment_score, outcome, associated_opp_id nullable)
• dim_campaign (campaign_id PK, name, channel, owner)

Important fields & notes

• Use surrogate integer PKs; maintain source_id and source_system fields for lineage.
• Store recognized revenue date for GAAP attribution; store invoice and payment dates for cash views.
• Capture lifecycle events (churn_date, churn_reason) in dim_customer or a separate fact_churn.

Example SQL join — Revenue attribution by campaign (bookings + recognized)

SELECT c.customer_id, c.name, d.month, coalesce(SUM(i.amount),0) AS bookings, coalesce(SUM(r.amount),0) AS recognized
FROM dim_customer c
LEFT JOIN fact_invoice i ON i.customer_id = c.customer_id
LEFT JOIN dim_campaign camp ON i.campaign_id = camp.campaign_id
LEFT JOIN dim_date d ON i.invoice_date_key = d.date_key
LEFT JOIN (
  SELECT invoice_id, amount FROM fact_invoice WHERE recognized_date_key IS NOT NULL
) r ON r.invoice_id = i.invoice_id
WHERE camp.campaign_id = :campaign_id AND d.year = :year
GROUP BY c.customer_id, c.name, d.month;

Example SQL join — Churn cohort by CS touchpoints

SELECT d.month, COUNT(DISTINCT c.customer_id) AS churned_customers,
       AVG(cs.touch_count) AS avg_touch_before_churn
FROM dim_customer c
JOIN dim_date d ON c.churn_date_key = d.date_key
LEFT JOIN (
  SELECT customer_id, COUNT(*) AS touch_count
  FROM fact_cs_touchpoint
  WHERE touch_date_key < (SELECT churn_date_key FROM dim_customer WHERE customer_id = fact_cs_touchpoint.customer_id)
  GROUP BY customer_id
) cs ON cs.customer_id = c.customer_id
WHERE d.year = :year
GROUP BY d.month
ORDER BY d.month;

Trade-offs & operational notes

• Normalize for consistency; build marts/flattened views for analytics performance.
• Ensure ETL preserves source lineage and handles partial matches (leads -> opportunities -> customers).
• Maintain incremental pipelines and reconciliation tables for bookings vs recognized revenue.

Overview / objective
As Revenue Ops I’d run a data-driven RCA to find why “Committed” deals slip in last two weeks of each quarter, quantify impact, test causes, and recommend operational fixes to reduce slippage and improve forecast reliability.

Tables / data sources to examine

• CRM Opportunities table (stage history with timestamps, owner, ACV, close_date, committed_flag)
• Activity logs (calls, demos, emails, quotes sent)
• Contract/CLM & Legal queue (SLA timestamps, redlines count)
• Pricing/Discounting ledger (approved discounts, deal desk approvals)
• Billing/Subscription and Implementation tasks
• Rep & AE quota/comp schedule
• Forecast & Actual revenue ledger

Key metrics

• Slip rate by week of quarter ( % committed → slipped )
• Time-in-stage distributions and median days for “Committed”
• Win rate and conversion velocity by AE and segment
• Volume of last-minute discounts, contract redlines, & legal turnaround time
• Forecast accuracy (MAPE) and bias in final two weeks
• ACV concentration of at-risk deals

Visualizations

• Time-series: weekly committed count vs slips heatmap across quarters
• Funnel with cohort waterfall for deals entering “Committed” by week
• Boxplots of time-in-stage for committed deals split by outcome
• Rep/segment scatter: ACV vs slip probability
• Gantt/timeline of contract lifecycle for slipped vs won deals

Hypotheses & tests

1. Legal/contract bottleneck causes slips — test: compare legal turnaround time for won vs slipped (t-test/Mann-Whitney).
2. Deals pushed to quarter-end artificially (pipeline sandbagging) — test: distribution of stage-entry dates; autocorrelation of AE-level last-week closing.
3. Higher discounting/approval delays increase slips — test: logistic regression predicting slip using discount %, time-in-stage, legal days.
4. Resource/implementation capacity causes late cancellations — correlate slipped deals with open PO/implementation backlog.

Operational remediations

• Deal gating: require signed SOW or countersigned contract before marking “Committed”
• SLA & capacity: set legal/finance SLAs; prioritize quarter-end throughput (extra capacity or rotating escalation)
• Deal desk controls: automatic alerts for high-ACV last-week commits requiring managerial review
• Forecast rules: flag and discount last-week commits (probability adjusters) and make rep-level accountability visible
• Process: standardize contract templates, pre-approve common discounts, and enable e-signature + automated reminders
• Training & incentives: discourage artificial compression by aligning comp/forecasting cadence; coach negotiation timelines

Next steps
Run the visualizations, share findings with Sales/Legal/Finance, pilot gating + adjusted forecast probabilities for one quarter, measure reduction in slip rate and forecast bias.

Approach summary
I’d build a regularized distributed-lag regression that models weekly closed‑won revenue as a function of current and lagged channel spend, channel interactions, seasonality controls, and business covariates — then use decomposition (and holdout/experiment validation) to estimate each channel’s marginal contribution.

Model form

Revenue_t = α + Σ_c Σ_l β_c,l * Spend_{c,t-l} + Σ_{c1<c2} γ_{c1,c2} * Spend_{c1,t} * Spend_{c2,t} + f_season(t) + δX_t + ε_t

• f_season(t): Fourier terms or weekly/month dummies or splines to capture seasonality.
• Lags l: e.g., 0..8 weeks, chosen from AIC/lag-decay prior.
• X_t: controls (promotions, pricing, macro, number of sales reps, lead quality score).

Key variables

• Dependent: closed‑won revenue (weekly, by cohort if possible).
• Main features: channel spend (paid search, social, display, email, events), impressions/CTR/leads if available.
• Controls: promo flags, funnel metrics (MQLs, SQLs), seasonality dummies, macro indicators.

Handling multicollinearity

• Use Elastic Net / Ridge to stabilize coefficient estimates and allow correlated spends.
• Compute VIFs; for extremely collinear channels, create grouped composites (e.g., brand vs. performance) or use PCA on spend features and map back via Shapley for interpretability.
• Impose lag-decay priors (Bayesian ridge) to regularize lag coefficients.

Controlling interactions

• Add pairwise interaction terms selectively (business-driven) and regularize heavily to avoid explosion.
• Alternatively use hierarchical models that pool across channels to estimate interactions with shrinkage.

Validation & incrementality

• Holdout time window (future weeks) and backtest forecasting accuracy.
• Compare predicted revenue with and without channel spend (counterfactual): set Spend_{c}=0 in holdout and measure delta.
• Use geo or A/B experiments where possible; validate modelled incremental lift aligns with experimental lift.
• Use Shapley-value decomposition or attribution by proportion of predicted incremental revenue to allocate marginal contribution.
• Sensitivity checks: different lag lengths, alternate seasonality specs, perturb regularization strength; report confidence intervals via bootstrapping or Bayesian posterior.

Operational notes

• Deploy weekly pipeline to refresh estimates; surface channel ROI and recommended budget shifts.
• Document assumptions (causality vs correlation) and align with Marketing/Sales before policy changes.

Clarify scope & constraints

• 12 concurrent revenue initiatives, each owned by a squad; delivery in 2‑week sprints; target: high adoption and minimal revenue disruption.

High-level approach

• Treat change-management (CM) as a first-class cross-functional capability embedded into Agile program delivery via a centralized Adoption Chapter that supplies CM leads (1 per 3 squads) and a shared Adoption Backlog prioritized by revenue impact, risk, and readiness.

Embed change activities into sprints

• Add CM story types to squad sprint backlogs: stakeholder comms, training assets, playbook updates, acceptance gating tasks.
• Each feature/user story includes a related “adoption task” with owner and DoR/DoD for readiness (see acceptance criteria).
• Weekly Adoption sync (15–30m) aligns CM tasks with squad sprint planning and demo.

Prioritized adoption backlog

• Maintain a program-level Adoption Backlog in the same tool (Jira): fields = initiative, revenue impact, risk, required training, dependencies, target cohorts.
• Prioritization formula: Priority = Revenue Impact * Urgency * Adoption Complexity — reviewed at triage with Product, RevOps, and Sales Enablement.

Acceptance criteria for user readiness

• For each release, require measurable criteria:
  • 80% of impacted users completed role-based training with pass score ≥70%
  • 95% of critical configs validated in staging by RevOps
  • UAT task completion and documented playbooks
  • Support SLA increased coverage for 2 weeks post-release
• Attach these checks as Release Gates in CI/CD and release checklist.

Coordinate release & adoption milestones

• Map release train timeline to adoption milestones (train → pilot → roll‑out → stabilize).
• Use feature toggles for phased rollouts to cohorts with adoption telemetry.
• Release calendar aligned with sales cycles; RevOps owns readiness sign‑off.

Scale change coaching

• Coaching hub model: Senior coaches (Adoption Chapter) coach squad CM reps; create templated playbooks, training modules, and a Champion network inside GTM teams.
• Automate onboarding: LMS micro‑modules + in-app tooltips for self‑service.
• Metrics & feedback loop: adoption rate, feature usage, funnel conversion lift; review in fortnightly business reviews.

Trade-offs

• Centralized prioritization accelerates high‑impact adoption but may add coordination overhead; mitigate with lightweight governance and service-level agreements.

This plan embeds CM into Agile rhythm, creates measurable readiness gates tied to revenue outcomes, and scales coaching through a hub-and-spoke model controlled by RevOps.

Approach (brief)
As a Revenue Operations Manager I’d group MQLs by the week of mql_date, count MQLs, count distinct contacts that have a qualified_date within 90 days of their mql_date, and compute conversion_rate = sql_count / mql_count. I’ll use BigQuery/Snowflake date functions.

-- BigQuery / Snowflake-compatible SQL
WITH mql AS (
  SELECT
    contact_id,
    mql_date,
    DATE_TRUNC(mql_date, WEEK) AS mql_week
  FROM marketing_contacts
),
qualified AS (
  SELECT
    contact_id,
    qualified_date
  FROM sales_leads
)
-- join to find qualifications within 90 days of each contact's MQL
, mql_with_qual AS (
  SELECT
    m.mql_week,
    m.contact_id,
    m.mql_date,
    MIN(q.qualified_date) AS first_qualified_date
  FROM mql m
  LEFT JOIN qualified q
    ON m.contact_id = q.contact_id
    AND q.qualified_date BETWEEN m.mql_date AND DATE_ADD(m.mql_date, INTERVAL 90 DAY)
  GROUP BY m.mql_week, m.contact_id, m.mql_date
)
SELECT
  mql_week,
  COUNT(DISTINCT contact_id) AS mql_count,
  COUNT(DISTINCT CASE WHEN first_qualified_date IS NOT NULL THEN contact_id END) AS sql_count,
  SAFE_DIVIDE(
    COUNT(DISTINCT CASE WHEN first_qualified_date IS NOT NULL THEN contact_id END),
    NULLIF(COUNT(DISTINCT contact_id),0)
  ) AS conversion_rate
FROM mql_with_qual
GROUP BY mql_week
ORDER BY mql_week;

Key notes / assumptions / edge cases (in-comments):

• Week starts per DATE_TRUNC(..., WEEK) (Sunday or Monday depends on SQL dialect; confirm org standard).
• Use first qualification within 90 days; if multiple qualifications, count once.
• LEFT JOIN ensures MQLs with no SQL still counted.
• SAFE_DIVIDE/NULLIF avoids divide-by-zero.
• If multiple MQLs per contact in different weeks, each MQL counts independently (change if you want unique-contact attribution).
• Timezone and partial dates: ensure dates standardized to same timezone.

Clarify goals & SLAs

• Objective: surface sales-ready leads with a single composite score, update CRM < 60s for high-intent events, daily full re-score for fit changes.

Data sources

• Behavioral: website events (page views, pricing clicks, demo requests), product usage (trial activation, key feature usage), marketing touches (email opens, ad clicks) via tracking pixel / event stream.
• Firmographic / intent: company size, industry, revenue, technographic, 3rd-party intent signals (G2, Bombora), enrichment (Clearbit) via batch and API enrich.
• CRM & engagement history: past deals, stage, contact role.

Scoring model

• Two pillars: Fit (static signals: firmographic, technographic) and Engagement (dynamic signals: behavioral, product). Weighted sum: Score = w_fit * Fit + w_engage * Engagement, with recency decay and event multipliers for high-value actions (demo, pricing).
• Use rules + ML classifier (gradient boosted tree) trained on historical conversion to ARR to tune weights and thresholds; fallback rules for explainability.

Architecture

• Event ingestion: Segment / Kafka for streaming events → CDP (mParticle/Segment) with identity stitching.
• Real-time scoring: Stream processor (Kafka Streams / Flink / AWS Lambda) applies rule engine + calls to ML endpoint for enrichment; maintains Redis cache for recent scores.
• Enrichment & batch: Airflow pipelines call Clearbit/Bombora, store in Snowflake; periodic model retrain.
• CRM sync: Push score updates via queued webhook worker to CRM (Salesforce) using platform APIs and Change Data Capture; use message queue (SQS/Kafka) for retries and rate-limits.
• Observability: Metrics in Datadog, audit log of score changes, explainability fields (top contributing signals) in CRM.

Operational controls

• Governance: data quality alerts, SLA on enrichment latency, manual override tags for ABM.
• Adoption: map score thresholds to routing rules, SLAs for SDR outreach, and dashboard for leadership.

Approach (brief)
As a Revenue Operations Manager I focus on drivers that directly change recurring revenue and forecasting accuracy. For each driver I state why it matters, how I'd source/measure it, and typical forecast sensitivity.

ACV / ARPA

• Why: Sets baseline revenue per customer; drives ARR/MRR scale.
• Source/Measure: CRM + billing; average contract value or monthly revenue per account, segmented by cohort/plan. Use signed ACV for bookings and billed ARPA for revenue.
• Sensitivity: High — small % changes scale linearly across base and new bookings.

Churn (logo & revenue churn)

• Why: Directly reduces ARR and indicates retention health.
• Source/Measure: Billing system and customer success records; calculate monthly logo churn % and gross revenue churn %. Use cohort analysis.
• Sensitivity: Very high for mature base; small increases compound and materially reduce LTV.

Expansion / Net Revenue Retention (NRR)

• Why: Upsells and cross-sells can offset churn and drive growth without new customer acquisition.
• Source/Measure: Billing/usage data; measure expansion MRR by cohort and compute NRR.
• Sensitivity: High — positive expansion markedly improves growth; negative expansion worsens decay.

Win Rate

• Why: Converts pipeline into bookings; affects new ARR forecast.
• Source/Measure: CRM opportunity history by segment, rep, funnel stage. Use weighted pipeline and stage-to-close conversion.
• Sensitivity: Medium — affects new business but mitigated by pipeline volume.

Sales Ramp & Quota Attainment

• Why: New rep productivity timing shapes bookings velocity.
• Source/Measure: Ramp curves from historical hires; track attainment vs quota per quarter.
• Sensitivity: Medium-high in growth phases when many new reps are hired.

Sales Cycle Length

• Why: Impacts timing of revenue recognition and funnel conversion rates.
• Source/Measure: CRM timestamps from lead → closed-won; segment by deal size and vertical.
• Sensitivity: Medium — longer cycles delay revenue and require larger pipeline.

Other important drivers (brief)

• CAC / Payback: influences hiring pace and go-to-market spend. Sensitivity: affects growth cadence.
• Pricing changes, contract term mix, and seasonality: source from finance/CRM; sensitivity varies.

I prioritize cohort-level measurement, automated ETL from CRM/billing, and sensitivity testing (scenario and Monte Carlo) to show how each driver shifts ARR/MRR.

Definition

• Average Contract Value (ACV): the average annualized value of a closed contract (typically ARR per customer/contract).
• Average Revenue Per Account (ARPA): average recurring revenue generated per customer/account over a period (usually annual).

Calculation

ACV / ARPA = Total ARR ÷ Number of Customers
ACV / ARPA = $2,400,000 ÷ 200 = $12,000

Plain-English: each customer generates on average $12k ARR.

How this influences GTM segmentation & quota

• Segmentation: Use ACV/ARPA to define tiers (SMB: <$5k, Mid-market: $5–25k, Enterprise: >$25k). With $12k ACV, majority fall mid-market — tailor packaging, retention plays, and CAC targets accordingly.
• Quota setting: Translate ACV into sales math — e.g., quota = target bookings * ACV. If a rep’s annual new ARR target is $600k, that’s ~50 deals at $12k ACV; hire/comp plans should reflect deal velocity and conversion rates.
• Forecasting & capacity: Combine ACV with win rates and sales cycle to size pipeline, assign territories, and set realistic activity targets.
• Risk management: Higher ACV reduces deal volume but increases concentration risk; adjust quota collars and renewal incentives to protect ARR.

Approach
I’d group events by date (UTC or company time zone), count distinct user_id per day for the last 30 days, and return date + unique_user_count ordered ascending. This supports adoption tracking on the pipeline feature.

SQL

SELECT
  DATE(event_time) AS date,
  COUNT(DISTINCT user_id) AS unique_user_count
FROM user_events
WHERE event_type = 'new_pipeline_view'
  AND event_time >= CURRENT_DATE - INTERVAL '29' DAY
  AND event_time < CURRENT_DATE + INTERVAL '1' DAY
GROUP BY DATE(event_time)
ORDER BY date ASC;

Notes & edge cases

• I used CURRENT_DATE - 29 days to include today + previous 29 = 30 days. Adjust timezone with AT TIME ZONE if needed.
• If you need zero-filled dates for days with no activity, join against a calendar table or generate_series.
• Useful for weekly trending, funnel analysis, or forecasting adoption velocity.

Overview (role perspective)
As a Revenue Operations Manager, I’d design a VP-facing pipeline health dashboard that surfaces roll-up signals + drilldowns by team and region so leadership can act fast on risk and opportunity.

Six widgets / tiles

1. Weighted Pipeline (by ARR/MRR) — stage-weighted value, trend vs. target
2. Conversion Rate by Stage — % advance/drop between stages last 30/90 days
3. Pipeline Coverage Ratio — (weighted pipeline / quota) by team & region
4. Deal Velocity & Age — median days in current stage and top stuck deals
5. Forecast Commit vs. Best/Worst Case — aggregated forecast categories with variance to plan
6. Top Risk Deals List — high-value deals with low engagement score / recent inactivity

Filters available

• Time window (30/90/180 days, YTD)
• Team / Manager / Rep
• Region / Country / Territory
• Product / ARR vs. one-time / ACV band
• Lead source / Opportunity type
• Deal size band and close date bucket

Threshold alerts (proactive risks)

• Pipeline Coverage < 1.2x for next quarter by team/region — high priority
• ≥ 20% of weighted pipeline aged > 60 days in same stage — medium priority
• Conversion rate by stage drops > 15% vs. prior period — medium priority
• Top 10% deals with no activity in 14 days OR missing champion — high priority
• Forecast Commit variance > 10% vs. historical close rate — high priority

Each alert includes suggested actions (rep coaching, reforecast, executive review) and links to underlying SFDC records for rapid remediation.