One row per submitted proposal (grain `proposal_id`), sourced from `int_rfx__proposal_economics`. Each row carries the deal's `segment` (off the account), `region` and `rfx_type` (off the opportunity); the `outcome` (`won` / `lost` / `pending` / `withdrawn`) and the derived `is_won = (outcome = 'won')`; the `total_price` / `total_cost` / `margin_pct` trio ((price − cost) / price · 100); the decision `cycle_time_days` (`decision_date − submitted_date`); and both the `submitted_date` and `decision_date`. `decision_date` and `cycle_time_days` are Nullable and NULL while a proposal is still `pending`. This is the per-entity outcomes table that the `proposal_win_rate` and `proposal_economics` metrics aggregate over — prefer those metrics for grouped counts/rates; read rows here when you need to inspect or rank individual proposals.
- highTreating pending proposals as losses in a win-rate calc
`outcome` includes `pending` and `withdrawn`, not just won/lost. Computing win rate as won / total rows understates the rate by counting undecided deals in the denominator. Restrict to `outcome IN ('won','lost')` (what the `proposal_win_rate` metric's decided_count does) before dividing.
- mediumAggregating cycle_time_days without filtering pending rows
`decision_date` and `cycle_time_days` are NULL while a proposal is `pending`. avg() skips NULLs (fine), but a COUNT over cycle_time_days or a naive coalesce-to-0 silently includes / zero-fills undecided deals and biases the average down.
- mediumSumming total_price across all rows as "pipeline value"
This table is submitted proposals (which can be lost or pending), not the open pipeline. For pipeline sizing use `mart_rfx_pipeline` / the `rfx_pipeline` metric. Here, summing `total_price` over `is_won = 1` gives won bookings, not pipeline.
- “What is the win rate for enterprise RFPs in EMEA?”
- “Which won proposals had the longest decision cycle time?”
- “What is the average margin on lost deals by segment?”