How do you prove Palantir Foundry improved win rate without creating a new shadow data mart for inbound SDR teams on Salesforce when SDRs on Outreach in 2027?

The outcome you should expect

Set expectations before you set up the measurement, because the number you find will be smaller and noisier than the number the vendor slide promised, and a RevOps leader who has not pre-committed to a range will retro-fit the story around whatever the report spits out.

For an inbound SDR motion running on Salesforce with sequencing in Outreach, the realistic first-order effect of a Foundry-style enrichment or scoring layer is not a dramatic win-rate jump on already-created opportunities. It is upstream: better lead-to-opportunity conversion, better routing, fewer wasted first touches. Win rate at the opportunity stage moves later and moves less, because by the time a deal is an opportunity, the AE's execution, the competitive set, and the budget cycle dominate the outcome far more than whatever signal the SDR used to prioritize the dial. If you promise the CRO a win-rate lift and the actual improvement shows up as a shorter time-to-first-meeting and a higher meeting-held rate, you will look wrong while being right.

So define the outcome as a small stack of measurements, ordered by how fast they move:

Fast movers (2–4 weeks). Connect rate and meeting-booked rate per sequence in Outreach, segmented by whether the prospect record carried a Foundry-derived attribute at the time of the first touch. These are high-volume metrics; an inbound pod touching a few hundred prospects a week reaches a readable signal quickly.

Medium movers (6–10 weeks). Meeting-held rate, SAL acceptance rate by the AE team, and opportunity creation rate from accepted meetings. This is where prioritization quality actually shows: if the scoring layer is working, the AEs stop rejecting the meetings SDRs book, because the meetings are with accounts that plausibly buy.

Slow movers (one to two full sales cycles). Win rate and average deal size on closed-won. If your average cycle is 60 days, you cannot honestly claim a win-rate delta until roughly 120–150 days after the exposure begins, and even then only if you have enough closed opportunities in both cohorts to say anything. Twenty closed deals per cohort is a directional anecdote. Two hundred is an argument.

The framing that survives executive scrutiny is: "Foundry improved the quality of the pipeline SDRs create; here is the win rate of that pipeline versus comparable pipeline created without it." That is a claim you can defend, and it does not require you to prove causation across a system where a dozen other things changed in the same quarter.

The second half of the outcome is what you did *not* build. A shadow data mart is any place where opportunity-level truth gets computed outside the CRM and then narrated back to leadership — a Foundry object that recomputes "win rate" with its own stage definitions, a warehouse table joining Outreach activity to Salesforce IDs on email address, a recurring spreadsheet a single analyst maintains. Each one creates a second version of the number, and the moment those two numbers disagree in a board deck, the credibility cost exceeds whatever the analysis was worth. The successful outcome is a measurement that lives in the same report the sales manager already opens on Monday.

What drives that outcome

The mechanism is worth being precise about, because "Foundry improved win rate" is a sentence with at least four different possible mechanisms hiding inside it, and they demand different proofs.

Mechanism one: better account selection. If Foundry is ranking or filtering which inbound leads get worked first, the effect is selection. You are not making any individual deal more winnable; you are winning a higher share because the mix shifted toward winnable accounts. The proof is a mix-adjusted comparison — win rate within segment, not blended — because otherwise you are just measuring that you started calling better companies, which is real but should be stated as such.

Mechanism two: better first-touch relevance. If SDRs are pulling a Foundry-derived fact into the Outreach message (a signal about the account's operating reality, a fit attribute, a stated initiative), the effect shows up as reply rate and meeting-booked rate, and only indirectly as win rate. Measure the near-term metric and let the downstream number follow.

Mechanism three: better qualification at handoff. If the SDR is using Foundry context to disqualify earlier, win rate rises trivially because the denominator shrank. This is the mechanism most likely to produce a flattering number and the least likely to represent value. Always report opportunity count alongside win rate; a 6-point win-rate lift on 30% fewer opportunities is usually a loss.

Mechanism four: better AE preparation. If the AE inherits Foundry context in the handoff, that is a genuine deal-level effect and the one most likely to move win rate honestly. It is also the one that has nothing to do with SDR tooling, which matters when someone tries to attribute the whole lift to the SDR layer.

Because those mechanisms interleave, the measurement design has to hold everything else roughly constant. Concretely, that means the exposed and control cohorts should match on inbound source, segment, region, product line, and time window. Same weeks, same lead sources, same AE bench where possible. If your exposed group is enterprise inbound in Q3 and your control is mid-market inbound in Q1, you have measured seasonality and segment, not Foundry.

The cleanest design available to most teams without new infrastructure is a staggered rollout: turn the Foundry-informed workflow on for pod A and not pod B for one full cycle, then swap. The swap matters — it controls for the possibility that pod A is simply better. Each pod acts as its own control across the two periods, and the comparison becomes a difference-in-differences rather than a naked A-vs-B, which is far more defensible when Finance asks whether pod A always outperformed.

The instrumentation this requires is deliberately small. On the Opportunity object: one datetime field capturing when Foundry exposure occurred relative to lead creation, and one picklist capturing the type of signal used. On the Lead or Contact: the same exposure stamp, so you can measure the upstream conversion steps too. Populate them with a Flow that fires on the existing sync, not with a nightly job that reaches out to a separate system — the moment you build a nightly reconciliation job, you have started building the mart you were avoiding.

One trap specific to Outreach: the Salesforce–Outreach sync writes activity, not attribution. Outreach knows which sequence a prospect sat in and which steps fired; Salesforce knows the opportunity outcome. The join key is the Contact/Lead ID, and it is reliable only if your SDRs work prospects that were pushed from Salesforce rather than created natively in Outreach and matched back later. Audit that before you trust any cohort assignment. In most orgs, some meaningful fraction of prospects are created in Outreach first, and those records match back on email with a failure rate high enough to poison a cohort analysis. Filter them out and say you did, rather than silently absorbing them.

Benchmarks and realistic ranges

Be careful with numbers here, and be more careful with numbers you did not generate yourself. Published win-rate benchmarks vary enormously by segment, deal size, and how the reporting org defines a "win," so treat any external figure as a sanity band rather than a target.

What you can rely on are internal ratios and the arithmetic of statistical power, which are the same everywhere.

Sample size is the binding constraint, not the tooling. If your baseline win rate is 25% and you want to detect a 5-percentage-point absolute lift with reasonable confidence, you need on the order of several hundred closed opportunities per cohort. Most inbound SDR pods do not produce that in a quarter. This is the single most common reason these proofs fail — not bad instrumentation, but a manager declaring victory on 40 deals where the swing is well inside noise. Do the power calculation before the pilot, not after, and if the answer is "we cannot detect a 5-point lift in one quarter," say so up front and pick a faster-moving proxy metric as the primary.

Practical thresholds to hold yourself to. A cohort under 50 closed opportunities is a signal to watch, not a result to present. Between 50 and 150, report the delta with an explicit confidence interval and the word "directional." Above 150 per cohort, you can start using the word "improved" in a slide without a caveat clause.

Field-completeness floor. Whatever the exposure field is, it needs to be populated on the large majority of records in the window or the cohorts are garbage. Target 90%+ population on the exposure stamp and check it weekly; a field that is 60% populated does not give you a control group, it gives you two mystery groups. If population drops, that is an adoption problem or a sync problem, and either one invalidates the window you are currently measuring.

Time-window discipline. Measure on close date, cohort on exposure date, and never let a deal move cohorts. If a deal enters as control and later gets Foundry context applied mid-cycle, it stays control — intent-to-treat. Allowing reassignment is how you accidentally build a machine that assigns every won deal to the exposed group.

Expect the upstream numbers to be larger and cleaner. Meeting-booked rate on a few thousand touches reaches significance in weeks; win rate on a few dozen deals may never reach it. If the enrichment layer is genuinely working, you will usually see it first in the ratio of meetings-held to meetings-booked and in AE acceptance of SAL handoffs. Those are also the metrics where a modest relative improvement compounds visibly, because they sit early in the funnel and multiply through every downstream stage.

Adjacent metrics worth tracking in the same report. Average sales price by cohort, cycle length by cohort, and loss-reason distribution by cohort. If win rate rose but cycle length rose more and ASP fell, you likely shifted the mix toward smaller, easier deals — a real effect, but not the one you were claiming. Loss reasons are especially useful: if the exposed cohort loses less to "no decision" and about the same to competitors, the mechanism is qualification, which is a genuine and explainable improvement.

Risks, edge cases, and failure modes

The shadow mart grows by accident, one reasonable step at a time. Nobody sets out to build one. Someone exports a report to reconcile a discrepancy. The export becomes weekly. Someone adds a tab joining Outreach activity. Someone schedules it. Six months later there is a pipeline object nobody owns, computing win rate with stage definitions that drifted from Salesforce two releases ago. The defense is procedural, not technical: name a single system of record for the number in writing, and require that any derived analysis reproduce the CRM number exactly before it is allowed to add anything on top. If the derived view cannot reproduce the base number, the derived view is wrong until proven otherwise.

Selection bias masquerading as effect. If SDRs get to choose when to use the Foundry signal, they will use it on the accounts they already believe in. The exposed cohort then wins more because it was pre-selected for winnability. This is the most common way these analyses lie, and it is invisible in the report — the field is populated, the query is correct, the number is wrong. The staggered-rollout design solves it; voluntary adoption does not. If you cannot enforce assignment, at minimum measure whether exposed accounts differ from control on the obvious fit attributes before you interpret anything.

Contamination between pods. SDRs sit next to each other and talk. If pod A learns something useful, pod B hears about it inside a week, and the control group quietly becomes a partially-treated group, which biases your measured effect toward zero. Physical or channel separation helps; so does keeping the pilot short. Accept that the effect you measure is a floor, not a point estimate, and say so.

Sync-lag artifacts. Outreach-to-Salesforce syncs are near-real-time but not instant, and activity written after an opportunity closes will still land on the record. If your exposure stamp gets written by a Flow that fires on activity sync, some deals will get stamped after the fact and land in the wrong cohort. Guard with a rule: exposure only counts if the stamp precedes the opportunity's created date. Enforce it in the report filter, not just in policy.

Attribution collision with everything else that changed. Territories were redrawn. Pricing changed. A competitor had an outage. A new enablement program launched. In a real quarter, at least three things move at once. This is exactly why difference-in-differences beats before/after: shared shocks hit both cohorts. If you only have before/after, enumerate the confounders in the same document as the result and let the reader discount appropriately. A result presented with its confounders listed is more persuasive than a bigger result presented naked.

The disqualification illusion. Covered above but worth its own line, because it recurs. Any change that makes SDRs pickier raises win rate mechanically. Always publish opportunity count, total pipeline created, and closed-won *dollars* next to win rate. If dollars fell while the rate rose, the honest headline is "we got more selective," and leadership should decide whether that trade is worth it.

Privacy and access edges. If Foundry holds data with access restrictions, be careful that the field you push into Salesforce does not leak a restricted attribute to a much wider audience. A boolean "signal present" or a coarse tier is usually sufficient for measurement and dramatically reduces the governance surface compared with syncing the underlying attributes. Check this before you build the Flow, not after Security finds it.

The null result. Plan for it. If two cycles produce no detectable difference, the first question is adoption, not efficacy: what share of exposed records actually had the signal visible to the SDR at the moment of the touch? In practice, adoption is frequently the answer. A tool that 30% of the pod uses on 40% of their touches cannot move a quarterly number, and reporting that honestly is more valuable than manufacturing a lift. Write the null result down and treat it as a finding about rollout, not a verdict on the platform.

A practical rollout plan

Run this as an operating sequence with explicit exit criteria at each stage. The point of the exit criteria is that they let you stop early without it being a failure.

Week 0 — define and baseline. Write a one-page definition covering: what counts as exposure, what counts as a win, which segments are in scope, what the primary metric is, and what sample size you need. Pull the trailing four quarters of inbound-sourced opportunities from Salesforce and compute win rate by segment, by source, by quarter, and by AE tenure band. This is your variance baseline — you need to know how much your win rate bounces naturally before you can recognize a real change. If quarter-over-quarter swing is already ±6 points with nothing changing, a 4-point lift is not detectable and you should know that on day one.

Week 1 — instrument. Add the exposure fields to Lead/Contact and Opportunity. Build the Flow that stamps them off the existing sync. Add the cohort filter to a single saved report and share it with the pod manager and the RevOps lead. Do not build a dashboard yet. One report, one owner, one URL. Validate the Flow against 20 hand-checked records before trusting it on anything.

Weeks 2–3 — dry run. Run the instrumentation with no workflow change at all. The only goal is to confirm the field populates correctly, the cohorts split roughly as expected, and the join between Outreach activity and Salesforce records holds. You will find problems here — mismatched prospects, records created natively in Outreach, a Flow that fires twice. Fix them now, while the data does not matter yet. Teams that skip the dry run discover the sync defect in week ten and lose the whole window.

Weeks 4–16 — period one of the staggered rollout. Pod A works the Foundry-informed motion; pod B works as before. Both pods keep the same sequences, same quotas, same routing rules otherwise. Weekly, the manager opens the one saved report and checks two things: exposure-field population rate, and cohort volume. Not results — results at week five are noise and looking at them invites narrative-building. Manager inspection at this stage is about instrumentation health only.

Weeks 17–30 — swap and period two. Pod B takes the treatment, pod A returns to baseline. This is the step most teams skip and the step that makes the analysis defensible. Now you can compare each pod against itself across periods, which controls for the durable differences between pods that no amount of matching would fix.

Week 31 — read it out. Compute the difference-in-differences on the primary metric with a confidence interval. Report opportunity counts, pipeline dollars, ASP, and cycle length alongside. State the confounders. State the adoption rate. If the result is null, say so plainly and pivot the readout to what adoption told you.

A note on scaling without creating the thing you avoided. When this works and leadership wants it everywhere, the pressure to build central reporting arrives immediately. Resist the reflex to stand up a parallel analytics object. Copy the same fields to the adjacent teams unchanged, reuse the same saved report with a different filter, and let the CRM stay the single arithmetic authority. If you eventually do need warehouse-level analysis — and at real scale you will — the rule that keeps you honest is that the warehouse view must reproduce the CRM's win rate to the decimal before it is permitted to compute anything the CRM cannot. That one rule is the difference between a data platform and a shadow mart.

Who needs to be involved. The Salesforce admin owns the fields and the Flow. The pod manager owns adoption and the weekly instrumentation check. The RevOps lead owns the analysis and the readout. Security reviews the field contents once, before the Flow ships. Nobody else is needed until the expand phase, and adding people earlier mostly adds opinions about what the number should be.

Related questions

Can we prove impact without a control group at all?

Weakly. Before/after on a single cohort confounds every other change in the period. If a control is genuinely impossible, use a synthetic comparison — the same pod's same-segment performance in prior equivalent quarters — and present it explicitly as suggestive rather than causal.

Should win rate be measured on opportunities created or opportunities closed?

Cohort on creation, measure on close. Cohorting by close date pulls in deals created long before exposure existed, which dilutes the treatment group with untreated history and drags any real effect toward zero.

How do we handle deals that touch both cohorts?

Intent-to-treat: whichever cohort the record entered at first touch is the cohort it keeps, permanently. Allowing reassignment mid-cycle is the single fastest way to manufacture a lift that is not there.

Does this approach work for outbound rather than inbound?

Yes, and outbound is often cleaner because you control list assignment directly, so randomization is easier. The complication is that outbound cycles are usually longer, so the win-rate readout sits further out.

What if Foundry data reaches the AE but never reaches the SDR?

Then measure the AE stage, not the SDR stage. Exposure should be stamped where the information actually became available. Measuring at the wrong stage is how teams conclude a working tool did nothing.

FAQ

Is adding a custom field to Salesforce a shadow data mart?

No. A shadow mart is a separate store that recomputes business truth outside the system of record. One or two fields on an existing object, populated by a Flow off an existing sync, extend the system of record rather than duplicating it. The line is whether a second place is computing win rate.

How long before we can honestly claim Foundry improved win rate?

Two full sales cycles minimum, and only if each cohort has enough closed opportunities to detect the effect size you care about. For a 60-day cycle that is roughly five to seven months end to end. Earlier readouts on upstream metrics are legitimate; earlier win-rate claims are not.

What if leadership will not wait that long?

Give them the fast-moving metrics on a weekly cadence — connect rate, meeting-booked rate, meeting-held rate, SAL acceptance — and be explicit that win rate is a lagging indicator arriving later. Most executives accept a staged readout when the schedule is stated in advance rather than negotiated after a bad week.

Can Foundry's own audit or usage logs serve as the exposure signal?

They can, as a cross-check. Platform access logs tell you who opened what and when, which is a reasonable proxy for exposure. Treat them as validation of your Salesforce stamp rather than as the primary source, because the moment your analysis depends on joining exported logs to CRM records outside the CRM, you have started building the mart.

We are creating this measurement mid-quarter. Should we wait for a clean boundary?

Instrument now, start the measurement window at the next clean boundary. Instrumentation takes a week or two and always surfaces defects, so getting the fields and the Flow live early costs nothing and buys you a working dry run before the window that counts.

What is the minimum viable version of all this?

One checkbox or timestamp on the Opportunity, one Flow, one saved report grouped by that field, a named owner, and a written commitment to read it after two cycles rather than two weeks. Everything else in this page is hardening.

Sources

• https://help.salesforce.com/s/articleView?id=sf.reports_builder_overview.htm — Salesforce report builder and grouping
• https://help.salesforce.com/s/articleView?id=sf.customize_functions.htm — custom fields and formula fields on standard objects
• https://help.salesforce.com/s/articleView?id=sf.flow.htm — Salesforce Flow for record-triggered automation
• https://support.outreach.io/ — Outreach support center: sequences, activity logging, and CRM sync behavior
• https://palantir.com/docs/foundry/ — Palantir Foundry platform documentation
• https://hbr.org/2017/12/a-refresher-on-ab-testing — Harvard Business Review on A/B testing fundamentals
• https://hbr.org/2015/11/a-refresher-on-statistical-significance — Harvard Business Review on statistical significance and sample size
• https://www.gartner.com/en/sales — Gartner sales practice research on revenue technology evaluation
• https://www.forrester.com/blogs/category/revenue-operations/ — Forrester revenue operations research

Related on PULSE

• How do you prove Palantir pipeline digital twins improved win rate without creating a new shadow data mart for inbound SDR teams on Dynamics 365 when consumption pricing with minimum commits?
• How do you prove Palantir-driven forecast simulations improved win rate without creating a new shadow data mart for channel co-sell teams on Salesforce when SDRs on Outreach?
• How do you prove Palantir Foundry improved win rate without creating a new shadow data mart for usage-based pricing teams on Pipedrive when data warehouse in Snowflake?
• How do you prove Palantir Foundry improved win rate without creating a new shadow data mart for enterprise outbound teams on Dynamics 365 when consumption pricing with minimum commits?
• How do you prove Palantir Foundry improved win rate without creating a new shadow data mart for multi-year ramp contracts teams on Dynamics 365 when marketing ops on Marketo?
• How do you prove Palantir Foundry improved win rate without creating a new shadow data mart for services-led sales teams on Zoho CRM when post-merger CRM merge?