How to Use Claude's Tasks and Dispatch Features to Keep Sales Opportunities Current

The short answer: Claude's scheduled Tasks can re-check an open pipeline on a recurring basis without anyone starting the conversation, and its multi-agent Dispatch pattern can work through many opportunities in parallel rather than one long serial pass. That combination is genuinely useful for pipeline hygiene — provided the agent proposes changes and a human approves the writes.

Every sales manager knows the number in the forecast is partly fiction, and knows roughly why. Deals sit in "Negotiation" three weeks after the last contact. Next steps are blank on a third of open opportunities. Close dates slipped past without anyone moving them. Nobody is being lazy — pipeline hygiene is the work that never has a deadline, so it loses every week to work that does.

The usual response is a Monday reminder and a quarterly clean-up sprint. It does not hold, because the decay is continuous and the intervention is periodic.

This is the one topic in this series built around Claude's own agentic features rather than a chat-plus-API integration, because pipeline hygiene needs exactly what those features provide: something that runs when nobody has opened a chat window, and something that can look at ninety opportunities without taking ninety turns.

Why Pipeline Hygiene Decays Faster Than Reps Can Fix It Manually

A CRM record goes stale in ordinary ways. A call happens and the notes go into a notebook. A prospect says "circle back after our budget review in March" and nobody moves the close date, because in the moment it feels like an admin task rather than a forecasting fact. An opportunity owner leaves and their deals get bulk-reassigned to a manager who has never spoken to any of them.

Each is a two-minute fix. There are eighty of them, they arrive continuously, and none is urgent on the day it happens. That explains why the standard fixes fail: a required-field rule makes reps type something rather than something true, and a quarterly clean-up sprint fixes the backlog on the day it runs and then decays for the next eighty-nine.

What helps is a small, boring pass that happens often — every day or two, across everything open — producing a short list of "these ten look wrong, here is why". No glamour, lots of repetition: exactly the profile that suits an unattended agent.

What Claude's Tasks and Dispatch Actually Do

Two capabilities matter here, and it is worth being precise about them, because the value depends on which one you are using and the marketing language around agentic AI blurs them together. Availability differs by plan and both are evolving quickly — check Anthropic's current documentation for what your plan includes before designing around either.

Scheduled Tasks — recurring, unattended runs rather than a one-off prompt

A Task is an instruction that runs on a schedule without anyone starting the conversation. That sounds minor and is the whole point: the reason pipeline hygiene fails is not that nobody knows how to check a stale deal, it is that nobody remembers to, on a Tuesday, when four other things are on fire.

What changes when the run is unattended is the risk profile, not the capability. A prompt you run yourself is one you read the output of. A prompt that runs at 07:00 whether or not anyone is watching needs to be written for the case where nobody reads it carefully — which means narrow scope, conservative defaults, and output that lands somewhere a person will actually see, such as an email or a Slack channel rather than a log nobody opens.

Dispatch — parallel sub-agents across many opportunities at once

The second capability is orchestration: a coordinating agent that spins up sub-agents to work on separate pieces at the same time, then collects the results. For pipeline review that maps cleanly — one sub-agent per opportunity, or per segment of the pipeline, each reading the record's history and forming a view, all running concurrently rather than one after another.

The practical benefit is not only speed. A sub-agent that handles one opportunity has that opportunity's full context and nothing else, which produces sharper judgements than a single pass trying to hold ninety deals in mind at once. The trade-off is that each sub-agent sees only its own deal, so anything requiring cross-pipeline comparison — "which three deals actually matter this quarter" — belongs in the coordinating step, not the sub-agents.

Cost is a real consideration. Ninety parallel sub-agents consume roughly ninety agents' worth of tokens, multiplied by twenty working days a month. Scope it deliberately: open opportunities above a value threshold, or untouched for more than fourteen days, rather than everything in the system every night.

A Practical Workflow — From a Stale Pipeline to a Daily Refreshed One

Build it in this order, and do not skip the read-only stage.

Start read-only and stay there for two weeks. Give the agent CRM read access and no write permission at all. Have the scheduled Task run each morning, dispatch sub-agents across open opportunities, and produce one digest: which deals look stale, what specifically looks wrong, and what it would change. Send it to the sales manager by email.

Two weeks of that tells you what you need to know before granting any write access — whether the flags are right. If a third of them are wrong, the prompt needs work or the CRM data is worse than you thought, and finding that out in a read-only digest costs nothing.

Write the criteria down explicitly. "Stale" is not self-evident and the model should not be inventing a definition. Specify it: no activity logged in 21 days, close date in the past, stage unchanged for more than twice the average for that stage, next-step field empty on a deal above a value threshold. Explicit criteria produce consistent output run to run, which is what makes the digest trustworthy enough to act on.

Give it the history, not just the fields. The value of a language model here is reading the notes, emails and call summaries attached to a record and noticing that the last conversation ended with "we've paused this until Q3" while the stage still says "Contracting". A field-level rule cannot see that. This is also the point where you should decide, deliberately, how much conversation content the agent is allowed to read.

Promote to writes narrowly, if at all. When the digest has been reliable for a fortnight, consider letting the agent write — but keep the surface small. Updating an "AI flagged" field, adding a note, or creating a task for the owner is very different from changing a stage or a close date. Reserve the fields that feed the forecast for humans, permanently. The rule that holds up: the agent may write anything that prompts a person, and nothing that reports a number.

Route the output to a person with authority. A digest going to a shared inbox nobody owns is a job that quietly stops mattering. Send it to the sales manager, as a named five-minute item in an existing meeting.

Claude Tasks Plus Dispatch vs a Native CRM Workflow Rule vs a Zapier or API Integration

• Claude Tasks with Dispatch is the only one of the three that reads unstructured content — call notes, email threads, meeting summaries — and forms a judgement about whether the record matches what actually happened. That is the whole point, and it is also the whole risk: judgement can be wrong, and a wrong judgement written to a live record is worse than a missing update. Best when the signal you need lives in prose.
• A native CRM workflow rule (Salesforce Flow, HubSpot workflows) is deterministic, free with the licence you already pay for, auditable, and completely reliable within its limits. It will tell you a deal has had no activity in 21 days. It will never tell you that the last email said the buyer's project was shelved. For anything expressible as a field condition, use this — it is strictly better than an AI agent doing the same job.
• A Zapier or direct API integration sits in between: good at moving data between systems on a trigger, weak at judgement, and it introduces a maintenance surface that outlives whoever built it. Reasonable as the plumbing layer *underneath* an AI review — the thing that gets a digest into Slack, or writes an approved flag back — rather than as the reviewer.

Most teams that get value from this run all three: CRM rules for the deterministic checks, an AI pass for the judgement calls, and simple automation as the delivery pipe between them.

Where This Goes Wrong

Auto-writing plausible guesses to real records. The failure that damages trust fastest is an agent updating a close date based on a misread note, a rep noticing, and the whole team deciding the tool is unreliable. One visible bad write costs more credibility than fifty good ones earn. This is the entire argument for propose-then-approve.

Over-broad CRM permissions. The path of least resistance is an integration user with full read-write access to every object, created in five minutes and never revisited. Scope it to the objects and fields the job needs, and remember the agent reads everything that user can — including opportunities, contacts and notes for parts of the business that never agreed to this.

No audit trail. When someone asks in three months why a deal's stage changed, "an AI did it" is not an answer anyone accepts. Every automated change should be attributable: a dedicated integration user rather than a human's credentials, a note recording what changed and why, and a retained copy of the digest that proposed it.

Silent failure. A scheduled Task that stops running rarely announces itself. The pipeline drifts back and nobody notices for a month, because the absence of a digest looks like a quiet week. Alert on the job not running, not only on it erroring.

Reps quietly gaming it. If the digest becomes a scorecard used against people, the response is not better hygiene but better-looking records. Frame it as the manager's prompt list, not a compliance report.

Getting This Right — CRM Access Scope, Human Sign-Off Before Writes, and When to Bring in IT

An unattended agent with standing access to your CRM is a different security object from a chat session, and it should be scoped by someone who thinks about that for a living. Three decisions matter more than the rest.

Scope the access, not the intent. Read-only to begin with, on the specific objects and fields the job needs, through a dedicated integration identity with its own credentials. What matters is what the agent *could* touch, not what today's prompt asks it to — prompts change, permissions persist.

Decide what the agent is allowed to read. Opportunity records contain named individuals at customer organisations, contract terms, pricing, and sometimes commercially sensitive detail about a prospect's internal situation. Sending that to any external service is a data-handling decision your PDPO, PDPA, PIPL or GDPR position may have something to say about, depending on where your customers are. That question belongs to whoever owns data governance, before the first scheduled run, not after.

Keep humans on the writes. Not as a temporary safety measure to be relaxed later — as the design. The agent's job is to produce a short, accurate list of things a person should look at. A human deciding is not a bottleneck; it is the control that makes the whole arrangement defensible.

Designing that scope, choosing which parts of the pipeline the agent sees, and writing the review criteria so the output stays useful is AI+ Support work — an AI readiness and use-case discovery exercise, and this is one of the clearer use cases in a sales organisation. The governance side — how much standing, unattended, cross-system access an AI agent should hold, who reviews it, and how it is logged — is exactly the standing decision our managed services practice advises on, alongside the security governance and virtual-CTO work it sits within. The identity, credential and integration-user hygiene underneath is ordinary managed IT support. If you want a narrower first step, our write-up on AI-assisted lead scoring in HubSpot covers the single-event version of this, and we are happy to talk through which fits.

Frequently Asked Questions

Can a scheduled Task write to our CRM without anyone reviewing it first?

Technically yes, if you grant write access. It is a bad idea for anything feeding the forecast. Start read-only, keep it read-only for at least a fortnight, and when you do allow writes, restrict them to fields that prompt a human rather than fields that report a number.

What CRM permissions does this actually need — read-only or write?

Read-only covers the useful version: reading records and their history to produce a digest. Write access is only required if you want the agent to update records directly, which most teams should not do at the start. Scope by object and field either way, through a dedicated integration user.

How is this different from HubSpot's or Salesforce's own AI features?

Native CRM AI is built into the platform, sees your data without an external integration, and is generally strongest on scoring and forecasting from structured signals. The pattern here is different in kind: an agent you configure, that reads the unstructured history and reports specific discrepancies on a schedule you set. They are complementary, and if your CRM's built-in features already cover the job, that is the simpler answer.

What happens if Dispatch misreads a deal and updates the wrong stage?

If you have followed the propose-then-approve pattern, nothing — the misread appears in a digest, a human disagrees, and the record is untouched. If you granted direct write access, you get a wrong stage on a live record and a forecast that is quietly wrong. That asymmetry is the reason for the pattern.

Can we limit which opportunities it touches?

Yes, and you should, for cost as much as safety. Filter by value threshold, pipeline, owner, or days since last activity. A daily run across the fifty deals that matter is more useful and much cheaper than a nightly sweep of everything ever created.

How much does running this daily actually cost?

It scales with how many opportunities you review and how much history each sub-agent reads, multiplied by the run frequency. Costs move, so price your own scope rather than trusting a figure from an article — but the arithmetic to do first is deals × runs per month, and that is usually what pushes teams towards a filtered daily run instead of a full nightly one.

Does this replace the weekly pipeline review?

No — it changes what the review is about. Instead of spending the first twenty minutes discovering which records are wrong, the meeting starts with that list already produced, and the time goes to the deals rather than the data.