Deals and pipelines · how to

Manage deal stage, owner, and priority

Update deal stage, ownership, priority, probability, forecast category, and expected close date as separate evidence-based decisions.

3 min readUpdated August 12, 2026
For
Owner, Admin, Member
Availability
Your current plan and entitlements
Product evidence
WRKZY · reviewed August 12, 2026
Editorial review
WRKZY Editorial
Before you begin
  • Access to the deal and its latest customer/commercial evidence
  • The pipeline's stage-entry and exit criteria
  • An owner who has accepted the next commercial action
  • The team's priority definition

Do not collapse different signals into one

Deal fields are not substitutes
FieldIt means
StageWhere the customer decision is in the configured process
OwnerWho is accountable for progression
PriorityHow urgently the team should attend to it
ProbabilityCurrent evidence-based likelihood, from 0 to 100
Forecast categoryCommit, Best case, Pipeline, or Omitted for the selected period
Expected closeWhen the commercial decision is expected

A high-priority deal is not automatically a Commit. An advanced stage does not prove a close date. Keep each signal honest.

WRKZY deal pipeline board with stages and owned opportunities, annotated crop highlighting stage movement and riskOpen full size
Board position communicates stage, but the Deal Room supplies owner, priority, probability, close timing, and customer evidence. Update each signal independently, then confirm the deal appears in the expected operating view.

Update from the Deal Room

  1. Open the deal and read the pulse, stage journey, latest customer activity, active task, and quote state.
  2. In Deal details, select the accountable owner. Do not leave open value unassigned when a person is expected to act.
  3. Set priority using a team-agreed rule. Urgent should indicate work that truly needs immediate attention.
  4. Update expected close, probability, and forecast category from the latest customer evidence.
  5. Save and confirm WRKZY records the changes in history.
  6. Move stage through the stage journey or Deals view only after destination requirements are satisfied.

Example: customer asks for a revised proposal

Keep the deal in the proposal or decision stage that matches your pipeline. Assign the revision owner, create a due task, and update expected close if the customer’s decision date moved. Do not mark the deal Lost or lower probability solely because a revision was requested; use the actual substance of the request.

Movement controls

Stage rules can require fields, prevent skipping or backward movement, or request approval above a value threshold. A blocked move is a governance signal. Fill verified missing data or request approval; do not edit value or status merely to bypass the rule.

Closing stages use a confirmation dialog. Won and Lost require an actual close date, and Lost should record an outcome reason that will be useful in later analysis.

Verify in operating views

After saving, check that the deal enters or leaves the expected Work queues, appears under the correct Board column, and contributes to the intended Forecast period and category. If a change does not appear, refresh and inspect durable history before repeating it.

Deal signals align
  • Stage matches customer evidence
  • One owner is accountable
  • Priority uses team criteria
  • Probability and category were reviewed separately
  • Expected close reflects the decision date
  • History records the change
Was this guide useful?

Choose an answer. No message text or personal information is collected.

Still need help?

Contact WRKZY support with the workspace name and a safe, redacted example.

Contact support about this guide