Prioritize Accounts

Skill Configuration

User Context

• Invoke sales:user-context in preflight mode by loading [$sales:user-context](../user-context/SKILL.md) and running its preflight script before searching connectors, retrieving evidence, or drafting output. Do not look for a callable MCP tool named sales:user-context.
• Use the returned sales_preflight envelope as authoritative for saved context, source-category mapping, final obligations, and conditional guidance.
• Apply hard final_obligations unless the response is clarification-only. If an obligation is an onboarding reminder and the account-prioritization output also needs a skill-owned final continuation, satisfy both in one final natural continuation instead of rendering a standalone onboarding reminder plus a second CTA.
• Apply context_gap_note only when missing setup or inaccessible sources materially limits the prioritization.

Audience And Language

Source Resolution

Required Inputs

• [required] crm_account_truth: live CRM data, CRM export, or user-provided CRM-equivalent account truth that includes candidate accounts, owner scope, pipeline view, customer status, or opportunity/account records
• [defaulted] account_set: candidate accounts, owner scope, territory, ICP, segment, pipeline view, or other account universe to prioritize; default open pipeline deals when the user does not specify
• [defaulted] ranking_basis: what "best" means for this run, such as deal value, likelihood to close soon, product or usage signal, expansion potential, named-account priority, or mixed rep actionability; default deal value / ACV

• motion_goal: net_new, expansion, or mixed; default mixed
• batch_size; default 5
• capacity_window; default to batch_size
• signal_preference
• product_focus
• exclude_accounts
• uploaded_examples

• For broad requests such as "prioritize accounts", assume account_set=open pipeline deals, ranking_basis=deal value / ACV, motion_goal=mixed, and the user's saved CRM preference as source of truth.
• Always attempt CRM first for account truth, owner scope, open opportunities, stage, amount, forecast posture, close date, account status, recent activity, and CRM next step fields.
• If live CRM is unavailable, inaccessible, not installed, or not authorized, offer to connect/install the CRM source when that capability is available. If installation/connection is not available in the current context, ask the user for a CRM export, account list with CRM fields, owner scope, territory, or enough CRM-equivalent context to proceed.
• If CRM is available but the assumed account set returns no candidates, stop before broadening. Briefly report the empty result and ask whether to broaden to recent account activity, expansion customers, net-new targets, a different owner scope, or a user-provided CRM export/list.
• Treat ambiguous company-like proper nouns, partner names, and account shorthands as possible account-set or account-list anchors. Use a bounded CRM lookup to resolve account identity, ownership, customer status, or candidate-list scope before asking.
• Ask a clarification question only when CRM and prompt context cannot determine the account universe, when multiple CRM scopes would produce materially different results, or when the user's requested ranking basis conflicts with available CRM truth.
• When asking, present up to 5 concrete CRM-backed candidates or next-step choices with one-line rationale. Make lettered options usable as reply targets, but omit a separate reply-with-letter footer when the choices are already clear.

Default Intake Behavior

• account set: open pipeline deals from CRM
• ranking basis: deal value / ACV, adjusted by timing, momentum, risk, and actionability
• source of truth: saved CRM preference when available, otherwise the available CRM connector/source
• enrichment: pull any available and potentially relevant Calendar, meeting notes, internal messaging, external messaging, document-store, and enrichment context after CRM anchors the account universe

Workflow Sources

• crm: account truth, owner scope, territory or book, customer status, open opportunities, stage, amount, forecast posture, recent activity, contacts, account hierarchy, suppression signals, and CRM-backed account lists.
• calendar: recent or upcoming external meetings that suppress, down-rank, or explain active motion.
• meeting_notes: recent customer-call context, objections, decision process, urgency, stakeholder coverage, and continuity signals that materially change ranking or next action.
• document_store: account plans, territory docs, named-account lists, ICP guidance, sales plays, saved team priorities, or source-of-truth ranking/suppression conventions.
• data_enrichment: account fit, contact availability, tech stack, funding, hiring, and other account trigger context when CRM or user-provided CRM-equivalent truth is thin.
• external_messaging: recent customer engagement, timing, objections, stakeholder continuity, or duplicate-motion signals.
• internal_messaging: active seller/team motion, internal blockers, owner ambiguity, deal-desk or account-team signals, and suppression evidence when the user wants internal context.
• user-provided context: pasted account lists, CRM exports, enrichment tables, ICP notes, named-account lists, prior Sales outputs, examples, and explicit ranking criteria.

• crm is required as the source of account truth for the standard account action view. If live CRM is unavailable, use a CRM export or user-provided CRM-equivalent account truth only after making clear that live CRM was unavailable. If neither live CRM nor CRM-equivalent truth exists, stop and offer to connect/install CRM when possible, or ask for a CRM export, account list with CRM fields, owner scope, territory, or account context.
• Use data_enrichment only after the CRM account universe or CRM-equivalent export is anchored. It can improve fit, contactability, and why-now context, but it must not create the candidate universe by itself or overwrite CRM/user-provided CRM truth.
• Use calendar, meeting_notes, external_messaging, internal_messaging, and document_store whenever they are available and plausibly relevant to suppression, active-motion detection, timing, risk, contact choice, deal context, or next action. If checked and no relevant evidence appears, note the no-match only when it affects confidence.
• For "best/top N accounts" prompts, return the requested number of Suggested Focus rows whenever the confirmed candidate universe contains enough viable accounts. Use Low confidence or partial status for weaker but still actionable rows; return fewer than N only when fewer viable candidates remain after suppression/blocking, and say why.

• Prefer crm truth and existing internal motion before enrichment or drafting.
• Prefer known account context before generic web-style personalization.
• Treat calendar, meeting_notes, external_messaging, and internal_messaging as timing, suppression, and why-now signals; do not use them to create the candidate account universe or overwrite CRM/user-provided account truth.
• Do not let public research, enrichment exports, docs, messages, or inferred personalization override CRM-owned account truth.
• Use public research, enrichment exports, or user-provided market intelligence only to fill account coverage gaps when CRM or user-provided CRM truth is thin.
• Do not use lower-confidence lanes to overwrite stronger crm or user-provided truth.
• If no account truth is available from crm, CRM export, or user-provided CRM-equivalent inputs, stop and explain the blocker briefly.

Context Gathering Principles

• Start with CRM and the narrowest owner/account scope.
• After CRM anchors the candidate set, gather available Calendar, meeting-note, messaging, document-store, and enrichment evidence that materially improves prioritization, suppression, confidence, or next action.
• Take the 80/20 path when it gives a useful, grounded result.
• Broaden only when the first pass is empty, thin, or misleading.
• Answer once the core artifact is supported; name limitations and offer expansion options.

First-Run Banner

## Prioritize Accounts
This skill helps decide which accounts to work now and why. It can use account lists, territories, CRM, firmographic/enrichment context, calendar, recent engagement, pipeline data, saved ICP guidance, and user-provided priorities. It produces a source-grounded account action view plus a ranked account list with reasons, confidence, suppressions, key contacts or gaps, and recommended next actions.

Definitions:
- ICP: ideal customer profile, the criteria that define what a strong-fit account looks like for the sales motion.
- Suppression: a reason to deprioritize or exclude an account for now, such as active motion, unclear ownership, or unsafe duplicate outreach.

• Primary default prompt: Prioritize accounts for pipeline focus.
• @Sales prioritize these target accounts for pipeline focus this week.
• @Sales rank my territory accounts by where I should spend time next.
• @Sales use this ICP and account list to pick the best ten outreach targets.

• Suppress the final CTA unless this skill intro is the active onboarding step.
• Return status and next-step candidates for onboarding to arbitrate.
• Mark whether this skill was introduced, tried, skipped, blocked, or accepted.

Next Step Guidance

Final Continuation Invariant

Journey States

Acceptance Handling

Account Action View Output

• macOS/Linux: ${TMPDIR:-/tmp}/prioritize-accounts/index.html
• Windows: %TEMP%\prioritize-accounts\index.html

1. Build the account action package using the Suggested Focus, Monitor, Suppress Or Block, Evidence Gaps, and Source & Run Details contracts below. Serialize Suggested Focus rows under the existing workNow payload key for template compatibility.
2. Serialize the same package as JSON using the payload shape below.
3. Escape the JSON for safe embedding in a script tag by replacing every < with \u003c.
4. Replace the exact template placeholder __PRIORITIZE_ACCOUNTS_DATA_JSON__ with the escaped JSON.
5. Write the resulting HTML as UTF-8 to the local output path.
6. Sanity check that the generated file contains no unresolved placeholder.
7. Final response: put the file link first, then a short summary and the required natural continuation from Next Step Guidance.

{
  "title": "Prioritize Accounts",
  "generatedAt": "2026-05-29T19:30:00Z",
  "source": {
    "label": "Salesforce/CRM",
    "status": "Connected sources used"
  },
  "scope": {
    "accountSet": "Open pipeline deals",
    "rankingBasis": "Deal value / ACV",
    "sourceOfTruth": "Salesforce/CRM plus recent meetings",
    "sourceScope": "Salesforce/CRM plus recent meetings",
    "actionOwner": "Rep-owned next actions",
    "accountOwner": "Rep-owned next actions",
    "ownershipActionModel": "Rep-owned next actions",
    "motionGoal": "mixed",
    "batchSize": 5,
    "capacityWindow": 5,
    "sourcesChecked": ["crm", "calendar", "meeting_notes"],
    "evidenceLanes": ["crm", "calendar", "meeting_notes"],
    "assumptions": "Assumption-based only when applicable"
  },
  "workNow": [
    {
      "rank": 1,
      "account": "Acme Corporation",
      "accountUrl": "https://example.my.salesforce.com/001000000000000",
      "motion": "expansion",
      "whyNow": "Source-grounded timing reason.",
      "primaryContact": "Dana Price, VP Operations",
      "secondaryContact": "Lee Chen, Director Data Platform",
      "oppRecommendation": "work account before opp",
      "nextStep": "Confirm security reviewer and send pilot success criteria.",
      "sequenceAngle": "Pilot success criteria tied to expansion timeline.",
      "confidence": "High",
      "status": "ready_now"
    }
  ],
  "monitor": [
    {
      "account": "Beta Inc.",
      "accountUrl": "https://example.my.salesforce.com/001000000000001",
      "motion": "net_new",
      "reasonToMonitor": "Good fit, but no immediate trigger.",
      "triggerToRevisit": "New executive hire or product signal.",
      "status": "monitor"
    }
  ],
  "suppressOrBlock": [
    {
      "account": "Gamma LLC",
      "accountUrl": "https://example.my.salesforce.com/001000000000002",
      "motion": "expansion",
      "suppressorOrBlocker": "Recent external meeting already in motion.",
      "evidence": "CRM activity and calendar meeting.",
      "status": "suppressed"
    }
  ],
  "evidenceGaps": [
    "Missing direct contact path for some otherwise strong accounts."
  ]
}

Procedure

1. Normalize the rep request

• Resolve whether the user wants net_new, expansion, or mixed.
• Resolve whether the request is account-led, owner-led, territory-led, ICP-led, or pipeline-view-led.
• Set an execution cap from capacity_window or batch_size.
• Preserve any explicitly supplied candidate accounts as the top evaluation set.
• Use references/request-schema.yaml only when structured input validation, YAML normalization, or machine-readable field shape matters.
• If the user request is broad, proceed with the default CRM-backed assumptions from Default Intake Behavior.
• If CRM is unavailable or cannot resolve the account universe, offer to connect/install CRM when possible or ask for CRM-equivalent account context.

2. Build the candidate account set

• Use crm as the required account truth source for the standard run.
• Prefer user-supplied CRM scopes, owner scopes, or CRM-backed account lists before broad discovery.
• If the default or assumed source returns no owned open pipeline, no matching account list, or no candidate set for the stated scope, stop before broadening the request. Briefly report the empty result and ask whether to broaden to recent account activity, expansion customers, net-new targets, or a user-provided account list or territory.
• Do not silently pivot from "best accounts to go after" to "accounts where the user can help or coordinate" unless the user chooses that broader action model.
• Fetch enough candidates before suppression to satisfy the requested cap when possible, but do not widen beyond the confirmed account set unless the first pass is empty, thin, or misleading.
• If the user requested an explicit count, preserve it as the target Suggested Focus row count throughout selection. Do not demote an otherwise viable Nth account to Monitor solely because confidence is lower; use confidence and status labels instead.

3. Branch and classify each account

• Classify each account as net_new, expansion, or unknown_branch.
• Prefer crm-backed evidence for customer status, current owner, open opportunities, recent or upcoming meetings, and current stage of any existing motion.
• Treat missing owner, weak account identity, or no usable contact path as execution blockers, not minor enrichment gaps.
• Do not blend net_new and expansion logic in the same row. Pick one branch and state it.
• If branch evidence is weak, mark the row partial or blocked instead of guessing.

4. Apply suppressors before drafting

• active open opportunity;
• recent or upcoming external meeting already in motion;
• clearly active seller, SE, account-team, or internal team motion that would make new outreach duplicative;
• unresolved account ownership or contact-path ambiguity that makes immediate rep action unsafe to recommend.

5. Score for rep actionability

• strongest why_now;
• reachable stakeholder path;
• clear branch fit;
• absence of suppressors;
• fit with the rep's capacity window.

6. Select contacts and next action

• Resolve one primary contact per account row.
• Prefer crm contact truth first.
• If crm is thin, use user-provided contacts, document_store account context, public research, or user-provided market intelligence as fallback.
• Use meeting_notes, external_messaging, and internal_messaging only as corroboration or continuity lanes, not as the sole source of contact fit.
• Add a secondary contact only when it materially supports multithreading.
• Never fabricate a contact. If the path is weak, keep the row out of Suggested Focus.

7. Gather why-now and message-angle evidence

• Use crm first for account and opportunity truth.
• After CRM anchors the account set, pull in any available and potentially relevant calendar, meeting_notes, external_messaging, internal_messaging, document_store, and data_enrichment context that could improve prioritization, suppression, timing, confidence, or next action.
• Prefer known account context over generic personalization tactics.
• Use calendar to suppress or down-rank accounts with meetings already in flight.
• Use external_messaging, internal_messaging, and meeting_notes only when they materially change timing, urgency, contact choice, or the sequence angle.
• Keep sourced facts separate from inference.

8. Render the account action package

1. Suggested Focus
2. Monitor
3. Suppress Or Block
4. Evidence Gaps
5. Source & Run Details

| Account | Why Now | Primary Contact | Secondary Contact | Opp Recommendation | Suggested Next Step | Sequence Angle | Confidence | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |

• Classify motion internally as net_new or expansion, but do not render Motion as a column in the account action view or chat fallback.
• Include accountUrl when a CRM, document, spreadsheet, or other source-of-truth record URL is available. In Salesforce, prefer the UI record URL for the Account. The account name renders as a clickable link when this field is populated.
• Use human-readable dates in all user-visible row text, for example Jun 1 or Jun 1, 2026 instead of 2026-06-01. Machine fields such as generatedAt may remain ISO because the view formats them for display.
• Why Now must be source-grounded. If it is not well supported, the row should not be in Suggested Focus.
• Secondary Contact may be None when multithreading is not supported by evidence.
• Opp Recommendation should be concise and practical, for example work account before opp, create opp after discovery, or expand existing motion later.
• Suggested Next Step must be an immediate rep action and should be populated from nextStep or suggestedNextStep in the serialized payload. This is an assistant recommendation, not a CRM field value.
• Sequence Angle should summarize the outreach hook, not render a full sequence.
• Confidence should be a plain-language rating such as High, Medium, or Low.
• Status must be ready_now or partial in Suggested Focus; move blocked and suppressed rows to later sections.

| Account | Reason To Monitor | Trigger To Revisit | Status |
| --- | --- | --- | --- |

| Account | Suppressor Or Blocker | Evidence | Status |
| --- | --- | --- | --- |

Output Rules

• This is a prioritization and activation workflow, not a generic lead list.
• For substantive ranking runs, make the account action view the primary output and put its link first.
• Keep the account row as the primary unit of work.
• Prefer account-level prioritization over contact sprawl.
• Show evidence gaps that prevented action.
• Do not claim urgency, contact fit, or motion status without evidence.
• Do not fabricate contacts, urgency, opportunity posture, or account facts.
• Prefer smaller, more executable Suggested Focus output over larger noisy output.
• When the user requested a specific count, prefer exactly that many executable Suggested Focus rows over a smaller polished list unless suppression, blocking, or insufficient account truth leaves fewer viable candidates.
• If the user explicitly asks for email drafts in a separate execution step and a real draft is created or saved through external_messaging, include a clickable Markdown link to each created draft using the URL returned by the app. If only copy is drafted in chat, say no email draft was created.