Sales Pipeline Pulse

A worked example of an advanced workflow: a Claude-managed scheduled agent that, once a week, reads the HubSpot CRM to summarize sales pipeline health — total open pipeline value grouped by stage, deals that have gone stalled, deals closing this period, and a forecast summary — then posts the report to Slack as a canvas with a one-line digest. There are no servers and no code to deploy: the agent is a saved prompt plus a schedule plus two MCP connectors, running in Claude's cloud.

What it builds

The finished workflow runs unattended on a weekly Monday morning cron. Each run it reads pipeline and stage definitions from HubSpot, lists all open deals grouped by stage with their total value, flags deals that have had no recorded activity in 14 or more days, surfaces deals whose close date falls in the next 30 days, and produces a forecast summary. The combined report is published to Slack as a canvas with a one-line summary — turning pipeline data that lives buried in the CRM into a standing Monday morning leadership question that gets answered automatically. The routine is entirely read-only on HubSpot; the only write is delivering the report via the Slack connector.

Prerequisites

Before building, your Claude account needs all of the following:

Known gotchas

These are the things that cost real time the first time through. Account for them up front and the build genuinely takes minutes.

• Re-check HubSpot tool names against the gateway catalog before building. The tool names in this guide (hubspot_list_deals, hubspot_list_pipelines, hubspot_list_companies) follow the gateway's <vendor>_<action>_<entity> naming convention and are the expected names — but always call gateway__search_tools with query "hubspot" and use whatever names the catalog actually returns. Setting wrong tool names in permitted_tools means the routine runs with no effective tools.
• Read pipeline stage labels from hubspot_list_pipelines — do not hardcode stage names. HubSpot pipeline stage names vary by org configuration and can be renamed at any time. The routine prompt instructs the agent to call hubspot_list_pipelines first and use the returned labels rather than assuming stage names. Hardcoding stage names in the routine prompt will produce an incorrect report the moment a stage is renamed in HubSpot.
• Large CRMs need open-deal filtering to stay under the timeout. A CRM with many historical deals (closed-won, closed-lost, archived) can produce a payload too large to process in a single routine run. The routine prompt instructs the agent to filter hubspot_list_deals to open deals only. Confirm the correct filter parameter name from the actual tool signature.
• permitted_tools must be populated per connector. A routine with a connector attached but an empty permitted_tools list runs with no tools and silently does nothing — no error, no output. List the exact tool names the routine needs, using the confirmed names from the gateway catalog.
• A routine reaches only its attached connectors. The routine sandbox blocks arbitrary network egress, so notifications must go through the Slack connector's tools, not an outbound webhook. Attach every connector the workflow touches.
• Faster-than-hourly cadences are rejected. The routine scheduler will not accept a cron more frequent than hourly. A weekly cron is well within bounds. Cron expressions are interpreted as UTC: Monday 08:00 America/New_York = 0 12 * * 1 in UTC (or 0 13 * * 1 during EDT offset months — confirm your preferred offset).
• If Slack does not appear in the /schedule connector list, read its connector_uuid and url from an existing routine that already uses Slack (RemoteTrigger list → get → mcp_connections).
• Prefer list payloads over per-record gets. Deal data needed for the pipeline summary, stalled-deal detection, and close-date filtering should all be available from hubspot_list_deals without a per-deal fetch call. Per-record calls across a large open pipeline risk the 60-second tool timeout.

The one-shot build prompt

With the connectors above in place, paste this to Claude. It confirms the gateway and HubSpot reachability, assesses payload size, creates the routine with both connectors and populated permitted_tools, and verifies it end to end.

Build me a scheduled Sales Pipeline Pulse agent. Do all of this end to end:

1. Confirm the WYRE MCP Gateway works and HubSpot is reachable: call
   hubspot_list_pipelines and check it returns your pipeline definitions.
   Verify the exact tool names against the gateway catalog first
   (gateway__search_tools with query "hubspot") — the names used in this guide
   follow the gateway's <vendor>_<action>_<entity> convention but confirm them
   before creating the routine.
2. Confirm a Slack connector is connected. Note the destination channel name
   and ID (e.g. #sw-dev). If Slack does not show in the /schedule connector
   list, read its connector_uuid and url from an existing routine that already
   uses Slack (RemoteTrigger list -> get -> mcp_connections).
3. Assess payload size. Call hubspot_list_deals filtered to open deals to gauge
   how many records are active. If your pipeline has a large number of open
   deals, the routine prompt already filters to open deals — but confirm the
   filter parameter name from the actual tool signature rather than assuming it
   matches this guide's description.
4. Create a Claude-managed scheduled routine named "Sales Pipeline Pulse":
   - Schedule: weekly, cron "0 12 * * 1" (Monday 08:00 America/New_York =
     12:00 UTC). Faster-than-hourly cadences are rejected.
   - Attach TWO connectors, each with permitted_tools populated:
       * WYRE MCP Gateway: hubspot_list_deals, hubspot_list_pipelines,
         hubspot_list_companies  (confirm actual names from the catalog)
       * Slack: slack_create_canvas, slack_send_message
     An empty permitted_tools list = the routine runs with no tools.
   - Routine prompt: every run, list pipeline and stage definitions, list open
     deals grouped by stage with total value, flag stalled deals (no activity
     in 14 days), list deals closing this period, summarize forecast vs target,
     publish a Slack canvas, and post a one-line summary linking the canvas.
     Use the exact routine prompt below.
5. Trigger a manual run and verify: a canvas titled "Sales Pipeline — <date>"
   was created, a one-line summary landed in the destination channel, and the
   report content matches live HubSpot data (spot-check one pipeline stage).

The resulting routine prompt

This is the lean prompt the build process installs into the scheduled routine itself. Substitute your own destination channel. Adjust the stalled-deal threshold (default: 14 days) to match your team's sales cadence.

You are the Sales Pipeline Pulse reporter. You run weekly. Keep it lean.

Use ONLY: hubspot_list_deals, hubspot_list_pipelines, hubspot_list_companies,
slack_create_canvas, slack_send_message.

Note: confirm tool names against gateway__search_tools before the first run —
the names above follow the gateway naming convention and are expected to be correct,
but the catalog is the authoritative source.

Today's date: use the current date at runtime to calculate close-date windows
and stale-activity thresholds.

--- PIPELINE DEFINITIONS ---

1. Call hubspot_list_pipelines to get all pipeline and stage definitions.
   Read each stage's label and display order. Do NOT hardcode stage names —
   use what the pipeline definition returns. This ensures the report stays
   accurate if stages are renamed in HubSpot.

--- OPEN DEALS BY STAGE ---

2. Call hubspot_list_deals filtered to open (non-closed-won, non-closed-lost)
   deals. For each deal read: deal name, pipeline stage, amount, close date,
   and last-activity date (or last-modified date if last-activity is not
   available).

3. Group open deals by pipeline stage (use the stage labels from step 1).
   For each stage report:
   - Number of deals in stage
   - Total pipeline value (sum of deal amounts in that stage)
   - List each deal: name, amount, close date

   If a deal has no amount set, count it as $0 and note it as "no amount set".

--- STALLED DEALS ---

4. A deal is STALLED if its last-activity date (or last-modified date) is more
   than 14 days before today's date. List each stalled deal: name, stage,
   amount, and days since last activity. Group stalled deals by stage.

--- CLOSING THIS PERIOD ---

5. List deals whose close date falls within the next 30 days from today.
   For each: name, stage, amount, and exact close date. Sum the total expected
   value closing this period.

--- FORECAST vs TARGET ---

6. Report the following summary figures:
   - Total open pipeline value (all open deals, all stages)
   - Total value closing this period (next 30 days, from step 5)
   - Count and value of stalled deals
   If a pipeline target or quota figure is not available from HubSpot tools,
   omit the "vs target" comparison and note: "Pipeline target not available
   from CRM data — set a target in HubSpot or add it to this routine prompt."

--- REPORT ---

7. slack_create_canvas titled "Sales Pipeline — <today's date>" with the full
   report structured as:
     SECTION A — Pipeline by Stage (stage name, deal count, total value,
       individual deals)
     SECTION B — Stalled Deals (deals with no activity in 14+ days)
     SECTION C — Closing This Period (deals closing within 30 days)
     SECTION D — Summary (total open pipeline, closing-period value, stalled
       count/value, forecast note)
   Then slack_send_message to #sw-dev: a one-line summary ("Pipeline: $X open
   across N deals, $Y closing in 30 days, N stalled — see canvas") linking
   the canvas.

8. If a deal's associated company name cannot be resolved via
   hubspot_list_companies, use the company ID as a fallback rather than
   failing the run.

9. If any deals cannot be read, list them in a "could not read" section
   instead of skipping them silently.

How it works

A weekly cadence, by design

Pipeline health is a standing weekly leadership question: what moved, what stalled, what is closing this period. A Monday morning run means the report is waiting before the first revenue-team standup of the week. Running weekly also keeps API load light — one HubSpot sweep per week, not one per hour — which matters for a CRM where a single deals list can return a large payload.

Stage-grouped pipeline value and stalled-deal detection

The routine groups open deals by pipeline stage rather than listing them flat, because the question a sales leader asks is not "how many deals do we have" but "where are they and what are they worth." Each stage section shows deal count and total value so the reader can scan the pipeline shape at a glance. The stalled-deal section surfaces deals whose last recorded activity predates a configurable threshold (default 14 days) — a signal that a deal may need a nudge before it slips the quarter. Both signals come from the same hubspot_list_deals payload; no additional fetches are needed.

Forecast vs target

The summary section reports total open pipeline and the value closing within 30 days as a lightweight forecast view. If a pipeline target or quota figure is not surfaced by the HubSpot tools, the routine notes that explicitly rather than inventing a comparison — the report stays accurate even when forecast targets live outside what the API exposes. Teams that do track targets in HubSpot can extend the routine prompt to read that field.

Extending it

The natural first pairing is with the client-relationship-manager account-health routine: the pipeline pulse tells you what is in the funnel; the account-health routine tells you whether existing clients are engaged. Together they give a combined commercial picture — new revenue in progress and retention health — in two Monday morning Slack canvases.

A second extension is feeding at-risk deals or stalled renewals into the broader renewal portfolio: if a stalled deal is also a renewal opportunity, linking it to the renewal-risk-analyzer workflow lets the team see renewal risk and pipeline stall as a single signal rather than two separate reports.

For delivery variations — posting to a different channel, using a DM to the account owner rather than a shared channel, or adding a thread reply with deal-owner mentions — see the delivery adapters guide.

Questions or a workflow you'd like documented? Open an issue in the msp-claude-plugins repository.