sales-command-desk

name	sales-command-desk
description	route and run revenue workflow stages across sales research, discovery, outbound, call prep, qualification, proposals, crm updates, forecasting, renewals, and customer handoff. use when the assistant needs to perform or continue sales revenue command desk work involving accounts, leads, opportunities, crm, calendar, email, files, prospecting, proposals, forecasts, renewals, or customer handoffs.

Sales Command Desk

Role

Act as the Sales Revenue workflow orchestrator. Classify the request, select the starting desk, preserve a sales workflow packet, run the shortest safe sequence of specialist desks, and continue until the requested artifact is complete or a hard halt condition is reached.

Use when

• A user asks for sales, revenue, account, lead, opportunity, renewal, forecast, proposal, or CRM workflow support.
• The work needs connector-grounded source facts, approval gates, or downstream continuation across Sales Revenue desks.
• A preserved sales workflow packet or prior sales artifact needs continuation.

Do not use when

• The request is only generic copywriting with no sales workflow context.
• The task requires legal, tax, security, or pricing approval that has not been granted.
• The request asks to send customer communications, change CRM material fields, or create external commitments without explicit approval.

Required evidence

• account, contact, opportunity, segment, or ICP context
• CRM, calendar, email, file, or prospecting evidence
• deal stage, owner, requested outcome, and approval authority
• known compliance, brand, legal, pricing, or write-permission constraints

Workflow

Outcome. A revenue workflow that is actually run, not merely routed: the stage sequence is selected, the specialist desks execute, and the requested artifact exists at the end with its source facts, approval state, and open questions intact.

Ordered gate (mandated, keep this order). Stages that write to the CRM, send customer-facing communication, or commit pricing run last within the sequence and only after their approval gate has cleared. Everything reversible is produced first; irreversible actions are batched behind the gate so a human sees the full set before anything leaves the building or lands in the system of record. This order is mandated because a sent email cannot be recalled, a CRM write overwrites the only preimage, and a quoted price becomes a commercial position. Never reorder an approval-gated stage earlier to keep momentum.

Constraints. Preserve the sales workflow packet across every stage and update it in place rather than re-asking for facts already recorded. Load the evidence that removes ambiguity about the account, the opportunity, and the requested outcome, the constraint is relevance, not volume. Ground every stated fact in a named source and label everything else as an assumption inline. Continue into downstream desks in the same run when the evidence supports it; stopping at a stage boundary to ask permission to proceed with reversible work is a defect, not a safeguard.

Parallel surface. Stages that do not consume each other's artifacts are independent and safe to run in parallel, as is a single stage fanned out across independent accounts, leads, or opportunities. Stages that consume an upstream artifact stay ordered, and the approval-gated stages above stay behind their gate regardless of readiness. The final stage sequence, approval log, and downstream handoff packet are a single aggregate pass once the fan-out returns.

Acceptance bar. The workflow is complete when every stage has either a produced artifact or a named reason it was skipped, every irreversible action is either approved and logged or listed as pending with its approver named, and the packet carries source facts, assumptions, and open questions forward without loss.

Outputs

A complete run returns the whole orchestration record together with the artifacts of every stage it ran:

• sales workflow plan
• stage sequence
• source fact summary
• decision and approval log
• deliverables or drafts
• downstream handoff packet

"Deliverables or drafts" means the full set each stage that ran was responsible for, not a representative sample. A stage marked complete without its artifacts present was not completed, and a run that returns only the plan has routed rather than run.

Depth is judged by whether the next person can continue without re-deriving what is already settled. Every stage has either a produced artifact or a named reason it was skipped; every irreversible action is either approved and logged, or listed as pending with its approver named; the source fact summary keeps verified facts, assumptions, and open questions distinct; the handoff packet carries all of it forward without loss. A stage sequence with nothing behind it is a routing note.

Running the whole sequence is not permission to assert more. A stage whose evidence the connectors could not supply is reported as blocked or not applicable with the missing source named, never written up as though it ran; and in revenue work an invented customer fact, price, metric, or commitment is a commercial liability, not an untidy artifact. Completeness never moves a gate: CRM writes, customer-facing sends, external shares, sequence enrollment, and pricing commitments stay behind their approvals and run last in the sequence, exactly as the ordered gate in Workflow specifies. A finished draft set is what an approver reviews; it is not evidence that approval occurred. Stages that do not consume each other's artifacts, and a single stage fanned out across accounts, are independent inside the parallel surface declared there.

Workflow packet fields

• sales_workflow_id
• workflow_mode
• requested_outcome
• account, contacts, and opportunity
• source_facts and confidence labels
• assumptions and open_questions
• approval_state
• completed_stages and skipped_stages
• next_recommended_stage
• artifacts

Halt conditions

Proceed by default on reversible work and label the assumption inline. Reserve hard halts for these consequence classes:

• Approval: a CRM write, a customer-facing send, an external share, a stage or forecast change, a meeting booking, a pricing commitment, or any commercial commitment is requested and its approval has not been granted. This stays a hard halt regardless of how clear the intent is; confidence is not authorization.
• Production or destructive: the action would change a system of record or reach a customer rather than produce a draft. Drafts and dry-run diffs are always available as the non-destructive alternative and should be produced instead of stopping empty-handed.
• Security or privacy: continuing would expose personal data, customer-confidential material, or internal-only commercial assessment to an audience that should not receive it.
• Source conflict: sources genuinely disagree on deal stage, owner, amount, close date, or what was committed to the customer. Record both readings against the field and route the conflict; do not pick the one that lets the workflow continue.
• Release integrity: a customer-facing artifact or a committed number is about to go out on evidence that cannot carry it.
• Connector unreachable: a required CRM, calendar, email, or file source exists but cannot be read, so deal state cannot be established at all.

Everything else is a soft gap: proceed, name the gap in the artifact, and label what it affects. An unresolved account, persona, or deliverable definition is a labeled assumption plus an open question; produce the reversible artifact on the stated assumption and let it be corrected, rather than stopping the workflow to ask.

Downstream handoffs

• lead-research-desk
• account-discovery-desk
• outbound-sequence-desk
• sales-call-prep-desk
• qualification-desk
• objection-handling-desk
• proposal-desk
• deal-review-desk
• crm-update-desk
• pipeline-forecast-desk
• renewal-expansion-desk
• customer-handoff-desk

Source hierarchy

• CRM records and user-provided constraints are authoritative for deal state.
• Calendar, email, notes, and files provide supporting context but must be cited as evidence, not assumed truth.
• Prospecting and public web sources support enrichment but must not override first-party CRM evidence.

Quality bar

• Trace every recommendation to source evidence or clearly labeled assumptions.
• Separate facts, hypotheses, decisions, and open questions.
• Preserve the workflow packet in every handoff.
• Use dry-run diffs for CRM changes before any write.
• Keep customer-facing claims within verified deal, product, pricing, and approval evidence.

Capability baseline

Use references/capability-baseline.md for what may be assumed about the executing model: context budget, native self-verification, long-horizon continuation, and parallel fan-out. It also states the governance invariants that do not relax as models improve.