CRM MVP
How a closed opportunity ended. Two values: won, or lost. Undefined while the opportunity is open.
Status and resolution do not overlap, which is why one field can carry both. You cannot have a resolution without being closed, and a closed opportunity always has one.
No win rate, and therefore no way to answer whether the team is getting better or worse. Lost reasons have nothing to attach to, and every backward-looking sales number loses its numerator.
Identical to status, including the evidence standard: in full as an attribute of the record, alone or carried losslessly alongside status; in part where readable only from the stage's own metadata; not at all where won and lost are stage names with nothing behind them.
The same Status field carries the outcome. Closing is performed by choosing Closed - Won or Closed - Lost in the Status box, with an optional Reason. Because the single field distinguishes won from lost as well as open from closed, the won-versus-lost fact sits on the opportunity record itself rather than on the stage.
Won and lost are milestones, selected from the same milestone menu used to advance the opportunity. The milestone model requires probability to be exactly 0 or 100 when complete is true, so the won-versus-lost distinction is read from the closed milestone's probability rather than from any attribute on the opportunity. The opportunity does carry an optional lostReason, but the vendor describes it as an optional reason applied to opportunities already lost, not as the record of the outcome.
The same Current State attribute distinguishes Won from Lost, and Abandoned is a third settled outcome. A configurable State Reason can be attached at the moment the state is changed, which is also stored against the opportunity.
The same status attribute on the deal distinguishes won from lost, and the deal also carries won_time and lost_time, each of which the vendor states can only be set when the status is won or lost respectively.
The same status attribute distinguishes won from lost, so the outcome sits on the opportunity itself. Vendor documentation lists the ways it is set - a Status dropdown on the record, dragging to the won or lost target on the pipeline board, the Update a status CRM action inside an automation, or the API passing 1 for won and 2 for lost - and states that only changing the status makes the platform treat the opportunity as closed.
The same status_type attribute on the opportunity distinguishes won from lost, since its three permitted values are active, won and lost. One combined attribute therefore carries both the live-or-settled fact and the won-or-lost fact.
The same Status attribute distinguishes Won from Lost. Keap documents it as a single dropdown on the deal whose selection determines the outcome the deal closes with, and pipeline automation offers a Deal is closed trigger, so the outcome is recorded against the deal.
Won versus lost is likewise carried by the status definition, not the opportunity. Each status is configured as a positive, neutral or negative outcome, and the vendor gives Lost as an example of a negative outcome and Won as a positive one. Reporting on lost work is built on filtering for statuses whose outcome is negative.
The same status attribute carries Won and Lost as distinct values, so the outcome is an attribute of the opportunity rather than something inferred from the stage it ended in. Copper's help centre describes Won, Lost and Abandoned as the closing statuses a user applies.
Won and lost are stage names rather than recorded values. The vendor's own material treats the literal stage name as the signal: the loss reason pop-up is described as appearing when the sales stage is changed to Closed Lost, and the developer API exposes only salesStageName and salesStageId on the opportunity, with no won, lost or outcome parameter. Nothing in the documented stage configuration marks a stage as the winning or losing one.
The same statecode column carries Won and Lost as distinct values, and a statuscode column, labelled Status Reason, adds In Progress, On Hold, Won, Lost and Out of scope. The outcome is therefore held on the opportunity, not inferred from the stage it stopped in.
Nothing in folk's documentation records won as distinct from lost at platform level. There is no won or lost attribute on the deal object in the API reference, and the only place the vendor mentions such values is the dashboards article, which describes measuring the Status field a user added to a group using a value such as Closed or Won. That makes the distinction a user-supplied select option with nothing behind it.
An IsWon checkbox sits on the opportunity alongside IsClosed. Salesforce's documented win rate recipe builds a summary formula that sums Opportunity.IsWon over a row count, which only works because IsWon is a field on the record. The stage picklist independently types each value as Closed Won or Closed Lost, and the article on stage types in reporting shows those types driving the Status filter.
Won and Lost are two of the four default titles on the Deal stage status attribute, alongside Lead and In Progress, and the vendor notes those options are editable per workspace. The status attribute type reference shows no property distinguishing a winning stage from a losing one, and no won, lost or outcome attribute appears on the Deals object. The distinction therefore lives in the text of a stage title rather than in a recorded value.
Nothing designates a stage label as won as opposed to lost. The done flag on a status label separates settled from unsettled but not the two outcomes, and the Deal Stages widget only lets a board owner pick which labels mean complete or incomplete. Won and lost exist as label text that the buyer types: the Funnel Chart widget is documented as calculating conversion between whichever status labels the buyer names, and the Forecasting View reads whichever label the buyer has designated as the closed won stage.
Same gap. Streak documents that its sales reports work when a pipeline has a value column and a Won stage, defines close rate as the share of boxes won out of all boxes, and the create-a-stage endpoint takes a name and nothing else, which suggests won and lost are stage names the buyer types. But no reachable source enumerates the box object's properties or the stage object's properties, so the claim that no won, lost or outcome attribute ships cannot be evidenced.
Won and lost are also read from the stage rather than the record. The stage picklist metadata splits the settled categories into Closed Won and Closed Lost, with matching forecast_type and a probability of 100 or 0. In the interface the outcome is applied by dragging the record onto a Pipeline Record Won or Pipeline Record Lost target, which sets its stage; no won or lost attribute exists among the module's default fields.
The same per-deal action that closes the opportunity records which way it went: the user chooses Won or Lost on the deal, and won and lost deals then sit in their own lists. A lost reason can also be attached, configured per pipeline. The record overview article does not name a status field explicitly, so the evidence is the documented behaviour rather than a named attribute.
Everything reachable points to the outcome being carried by the stage name rather than by any property. The vendor's sample views define Won deals and Lost deals as deals whose deal stage is Won or Lost, the analytics article treats closed Won as a stage a deal moves into, and the vendor guarantees only that stages named Won and Lost exist as default stages in every pipeline without documenting them as reserved, undeletable or unrenamable. The stage itself exposes no won or lost designation in either the settings screen or the API. One counter-signal exists: the API's Contact object carries vendor-computed rollups won_deals_amount and won_deals_count, so the platform does classify deals as won internally, but the vendor's own description of that attribute is number of deals moved to won stage, which points back at the stage rather than at a deal attribute. As with status, the Deals attributes table could not be retrieved, so a record-level won or lost attribute cannot be ruled out.
The same stage-level status type separates the two outcomes, since Deal Won and Deal Lost are its two settled values and the API enum spells them as DEAL_WON and DEAL_LOST on the Status object. The vendor states plainly that the type is chosen while editing a stage, not on the individual opportunity.
The same status attribute separates Won from Lost and from Cancelled. An Outcome is captured alongside it, selected from a drop-down the vendor says appears whenever a lead is lost or cancelled, and outcome is reported on separately from status.
The same pair of default record properties separates the two outcomes: Is closed won and Is closed lost are independent booleans on the deal, populated by HubSpot rather than by the user. A HubSpot staff reply in the vendor's community states these update when the deal moves to a stage whose probability is set to Won.
Same gap. Won and lost appear only as Sales Stage values in the vendor's prose, and no stage property reviewed separates them: the stage editor offers a name, a probability, the roles allowed to set it and a colour, the four documented forecast categories are Pipeline, Best Case, Commit and Closed and nest cumulatively so Closed Lost falls in none of them, and the Closed Deals vs Goals chart is documented as showing deals marked Closed Won. But none of those sources enumerates the attributes the deal object carries, so the claim that no won, lost or outcome attribute ships cannot be made on this evidence.
Won and lost are carried by the same stage-level Deal Category, which separates Closed won from Closed lost, and by the forecast_type the pipelines API returns for each stage. Each stage is additionally tied to a forecast category of Pipeline, Closed or Omitted. Nothing on the deal record itself distinguishes a win from a loss.