Keep Leads Moving and Follow Up Faster SKILL.md

Keep leads and opportunities moving in Salesforce. Use for pipeline health checks, stalled deals, account briefs, next-step and follow-up drafts, or weekly sales digests. Requires an authorized Salesforce connection; Slack delivery and Gmail drafts are optional and remain approval-gated.
Back to pack
---
name: salesforce-ops
description: Keep leads and opportunities moving in Salesforce. Use for pipeline health checks, stalled deals, account briefs, next-step and follow-up drafts, or weekly sales digests. Requires an authorized Salesforce connection; Slack delivery and Gmail drafts are optional and remain approval-gated.
category: Get more customers
type: bundled
requires:
  mcp:
    - salesforce
connectors:
  - mcp: salesforce
    auth:
      type: oauth
      credential: Salesforce per-user OAuth
    login: https://login.salesforce.com/
setup:
  - "Connect Salesforce's official Hosted SObject Reads/All MCP or official @salesforce/mcp package as server id salesforce; do not substitute a third-party gateway."
  - "Authenticate with per-user Salesforce OAuth, select the target org, and verify production versus sandbox before any query."
  - "Optional: bind Slack for digest delivery and Google Workspace for Gmail drafts; neither is required for Salesforce-only reports."
---

# Salesforce Ops

Keep pipeline reporting useful, explainable, and safe. Read live Salesforce data through an official Salesforce MCP server, add public-web context for account briefs, and use Slack or Gmail only when the user asks for those supplements.

## 1. Establish the operating context

1. Run `list_integrations` before making claims about availability. Salesforce is an MCP connection; Slack and Google Workspace are direct integrations and can be connected even when no same-named MCP server exists.
2. Use only Salesforce-owned MCP tooling:
   - Preferred for business-data workflows: Salesforce Hosted MCP `platform/sobject-reads` (least privilege) or `platform/sobject-all` when the org deliberately needs mutations.
   - Supported local alternative: Salesforce DX MCP `@salesforce/mcp`, using an org already authenticated by the official `sf` CLI.
   - Do not substitute a third-party Salesforce gateway or ask the user to paste a Salesforce token into chat.
3. Confirm the target org, authenticated user, currency, timezone, and whether the org is production, sandbox, or scratch. If multiple orgs are available, ask which one to use.
4. Stay read-only in Salesforce for every workflow in this skill. A request to update stages, amounts, close dates, tasks, users, permissions, or records is a separate mutation: show the exact proposed changes and obtain explicit approval before applying them.
5. Treat Salesforce records, Gmail messages, and Slack messages as sensitive. Summarize only what the user needs, never expose access tokens, and never carry private Gmail content into a shared Slack channel without explicit direction.

If Salesforce is not connected, stop after reporting the missing official connection and the setup choice. Never fabricate pipeline results or silently fall back to raw web search.

## 2. Normalize the available Salesforce tools

Inspect the connected server's advertised tools instead of assuming names. Map capabilities before querying:

| Capability | Hosted SObject MCP examples | Salesforce DX MCP examples |
|---|---|---|
| Identity/org | `getUserInfo` | org-list or username-resolution tool |
| Object schema | `getObjectSchema` | schema/describe tool when advertised |
| SOQL read | `soqlQuery` | `sf-query-org` |
| Cross-object search | `find` | search tool when advertised |
| Related records | `getRelatedRecords` | a bounded SOQL relationship query |

Tool names can change. Use the live schema and descriptions. Do not call an invented alias.

Before the first pipeline query, inspect the `Opportunity` schema and identify the org's actual fields for amount, recurring revenue, stage, probability, close date, forecast category, owner, last activity, last stage change, account, record type, and currency. Inspect `Account`, `Contact`, `Task`, `Event`, and an available opportunity-history object only as needed. Prefer admin-authored field guidance over guessed semantics.

Record a compact field map in the response. Never assume `Amount` means ARR, that all open stages have the same probability, or that a custom field exists. For multi-currency orgs, state whether totals use corporate currency, converted values, or per-currency groups.

## 3. Query discipline

- Use the authenticated user's Salesforce permissions as the data boundary. Never try to bypass sharing or field-level security.
- Query only named fields and necessary rows. Always filter and bound detail queries; use aggregate SOQL for totals where supported.
- Include an `as of` timestamp, org identity, scope, horizon, owner/team filter, and exclusions in every report.
- Use the user's definitions when supplied. Otherwise state defaults before calculating: open opportunities only, close-date horizon of the current quarter, stale threshold of 14 days, and no inferred quota.
- Treat missing values as missing, not zero. Separate `unknown` from `none` and disclose excluded records.
- If a query is truncated, paginate or narrow it before calculating. Do not extrapolate from a partial result.
- Keep retrieved customer data in memory where possible. Do not write raw exports into the workspace unless the user asks.

Read `references/workflows.md` for the exact health metrics, account-brief evidence order, digest format, and follow-up drafting contract.

## 4. Pipeline health check

For “Pipeline health check” or similar:

1. Confirm or state scope: owner/team, open stages, close-date horizon, currency, stale days, and quota source.
2. Inspect schema, then query the smallest opportunity dataset that supports the requested metrics.
3. Calculate stage aging, stale opportunities, close-date risk, past-due open opportunities, stage/forecast inconsistencies, unweighted pipeline, and probability-weighted pipeline.
4. Calculate coverage only when a quota or target is available from an authorized field/object or the user supplies one. Report `coverage = open pipeline / quota` and optionally `weighted coverage = probability-weighted pipeline / quota`; never invent a quota.
5. Return an executive summary, metric table, prioritized exceptions, assumptions/data gaps, and the next three actions. Link or name Salesforce record IDs only when useful; do not dump full records.

For stage aging, use the org's explicit last-stage-change field when available. Otherwise derive it from an available history object. If neither is available, label stage age unavailable; `LastModifiedDate` is not a safe substitute.

## 5. Account research brief

For “Brief me on Acme Corp before our call” or similar:

1. Resolve the exact Account in Salesforce first. If multiple accounts match, show minimal disambiguation (name, domain, region, owner) and ask the user to choose.
2. Pull bounded internal facts: account owner, industry, size fields, open opportunities, recent closed outcomes, key contacts, last activity, next scheduled activity, open cases/risks when authorized, and documented next steps.
3. If Slack is connected, search only recent deal-related chatter needed for the brief. Label Slack-derived statements and avoid quoting private messages into a shared surface.
4. Research public web sources for current company facts. Cite URLs and publication dates; distinguish verified facts from inference. Never overwrite Salesforce truth with an unverified web match.
5. Produce: relationship snapshot, active deal table, stakeholder map, recent signals, likely call objectives, questions to ask, risks/data gaps, and sources.

Do not merge similarly named subsidiaries or domains without evidence. Do not infer personal details about contacts from unrelated public data.

## 6. Weekly pipeline digest and Slack delivery

For “Weekly pipeline digest”:

1. Use a stable comparison window and the same filters for current and prior values.
2. Summarize pipeline created, progressed, slipped, won, and lost; coverage; stage aging; stale opportunities; close-date risk; largest material changes; and owner follow-ups.
3. Keep the Slack version compact: headline, metrics, five or fewer risks, owner/action bullets, and the report timestamp. Do not include private Gmail content.
4. If the user asks for delivery to a channel such as `#sales`, resolve the exact workspace/channel, show the final post and destination, and obtain explicit approval immediately before posting. A request to prepare a digest is not permission to send it.
5. After posting, verify the returned channel/message reference and report it. If Slack is unavailable, return copy-ready text without claiming delivery.

## 7. Gmail follow-up drafts

For “Draft follow-ups for opps idle 14+ days”:

1. Query open opportunities at or beyond the requested idle threshold. State whether idleness is based on `LastActivityDate`, completed Tasks/Events, or another agreed field.
2. Resolve a relevant contact and verified email for each opportunity. Skip ambiguous or missing recipients and report why.
3. Draft from Salesforce facts only: opportunity context, last verified interaction, agreed next step, and a specific low-pressure call to action. Never invent a conversation, commitment, deadline, or product claim.
4. Keep drafts distinct per recipient and deduplicate contacts shared across opportunities.
5. Use the direct Gmail integration, not a Google MCP server. Show recipient, subject, and body and obtain explicit approval before creating any Gmail draft. Creating a draft does not authorize sending; never send email from this workflow.
6. If Gmail is unavailable, return labeled draft text. Never claim drafts were created.

## 8. Completion checks

Before reporting success:

- Salesforce facts came from the selected org and include an `as of` time.
- Field mappings, filters, currency treatment, and thresholds are explicit.
- Stage age and staleness use defensible fields; unavailable metrics are labeled.
- Coverage has a real quota source.
- Web facts have citations and are separated from CRM facts.
- Slack posts and Gmail drafts were previewed and approval-gated.
- External delivery or draft creation was verified with a returned identifier.
- No Salesforce, Slack, Gmail, or public-web source is claimed when it was not actually consulted.