How to build an opportunity follow-up agent

In 60 seconds: Define “no next step” with fields the system can verify: an open opportunity in an included stage, an active owner, a known latest activity, and no future action with a type, date, and owner. Read from the CRM, ERP, or an accountable validated export; an unowned spreadsheet cannot support the pilot. Start the agent in recommendation mode: it detects a case, shows evidence, suggests an action, and prepares an internal reminder while a person decides. Give it separate tools to read opportunities, check calendar or Teams availability, and write an approved next step. For two weeks, measure recovered contacts, false alarms, and time to action. Fix ownership, status, and follow-up policy before automating when those foundations are missing.

An alert can find a forgotten opportunity. An agent has a broader job: it gathers permitted context, explains why a case deserves attention, proposes an action that fits the stage, and writes the human decision back to the official record.

This playbook follows the business case in recovering forgotten sales, which explains why follow-up can be a useful first agent. It also builds on the Microsoft flow for stale opportunities with Power Automate and Teams. Here, the focus is the agent build: objective, system of record, permissions, tools, flow, exceptions, and evaluation.

The agent does not replace the CRM, decide commercial terms, or attribute a sale to its own intervention. Its output is narrower and testable: an open opportunity ends with a valid next step, an assigned exception, or a recorded resolution.

Define the objective as a state change

Use a transition that appears in data:

eligible opportunity with no future action
  -> evidence-backed recommendation
  -> human decision
  -> recorded next step or exception

An opportunity has “no next step” when it meets every eligibility condition and fails the action-coverage check. The minimum definition needs these fields:

Field	Verifiable rule
opportunity_id	Stable, unique identifier in the system of record
status	Still open; won, lost, and cancelled records are excluded
stage	Included in the pilot scope
owner_id	Maps to an active identity authorized to act
last_activity_at	Comes from a recorded, classified activity
next_step_type	Describes an action allowed by sales policy
next_step_at	Has a future date in a defined time zone
next_step_owner_id	Identifies the person responsible for the action
snooze_until and snooze_reason	Explain a current pause when one exists

Flag a case when next_step_type, next_step_at, or next_step_owner_id is empty, or when the date is overdue. Then apply the threshold approved for its stage and exclude valid pauses, recent activities, closed opportunities, and segments outside the pilot.

“Latest activity” also needs a definition. A logged call, completed meeting, or prospect reply may restart the clock. Opening a record, editing a tag, or running a technical sync should not. Sales must approve the event catalog and stage thresholds; the agent applies that policy.

Keep an accountable system of record

The CRM is often the primary source because it keeps the stage, owner, activities, and next step together. In some companies, the ERP controls the quote and commercial status. A periodic export can support a pilot when it has a schema, cutoff time, validation, and a named person responsible for corrections.

Source	Can support the pilot when	Blocking sign
CRM	Statuses, activities, and owners follow a shared policy	Stages mean different things to different people
ERP	Opportunity, quote, and owner have stable IDs and reliable dates	The next step exists only in free text or another system
Validated export	Origin, cutoff, quality checks, and an owner are documented	Nobody can explain or correct a row
Operational Excel file	It is a controlled table with IDs, permissions, and an owner	It is an unowned manual copy

An unowned Excel file is not a system of record. It can help expose missing fields, but the agent would amplify its delays, duplicates, and stale statuses. Agree which system wins during a conflict and where resolutions will be written before automating.

Give the agent only the fields it needs. Teams does not need a phone number, email address, full conversation, or sensitive notes to say that opportunity OPP-1042 needs review. A link to the record preserves access under the source system’s permissions.

Assign control and permissions per action

The framework for five levels of agent control treats autonomy as an action-level decision. A sensible starting matrix for this pilot is:

Action	Starting level	Required control
Read opportunities in the segment	Read	Team-scoped view, minimum fields, and access logs
Mark the absence of a next step	Deterministic rule	Policy version, cutoff time, and a readable reason
Prioritize and suggest an action	Recommend	Linked evidence, visible limitation, and a correction path
Prepare an internal reminder	Draft	Authorized recipient, minimum content, and no automatic send
Write the next step	Approved execution	Exact approved payload, current-state check, and result log
Contact the prospect	Outside the pilot	Consent, channel, template, stop rules, and separate approval

Use a dedicated technical identity with least privilege. Separate read and write access, then restrict writes to next-step fields, alert resolution, and an audit reference. The agent does not need permission to change amount, discount, stage, probability, or opportunity owner.

Bind approval to the exact payload: opportunity, action type, date, responsible person, and reason. If the record changes between recommendation and execution, the tool reads the current version and asks for another decision. An external stop control must be able to suspend new writes without relying on the model.

Give the agent small, explicit tools

Avoid a generic database connection. Each tool needs a narrow schema, its own permissions, a timeout, and a structured response.

1. list_follow_up_candidates(cutoff, segment, policy_version) queries the authorized view and returns IDs, stage, owner, dates, next-step status, and evidence references. It does not return full conversations.
2. get_opportunity_context(opportunity_id) reads an opportunity again before recommendation or write. It returns version, status, permitted latest activity, exclusions, and existing next steps.
3. get_owner_availability(owner_id, window) checks working availability in a calendar or useful Teams presence. It returns windows or absence without exposing meeting titles, participants, or content.
4. prepare_internal_reminder(opportunity_id, owner_id, reason, proposed_step) creates a draft or approval-pending card. It does not send external communication.
5. write_next_step(opportunity_id, expected_version, step_type, due_at, owner_id, approval_id) validates fields, version, and authorization, writes to the CRM or ERP, and returns the canonical record.
6. record_follow_up_outcome(alert_id, outcome, reason_code) closes the loop with a result, false alarm, pause, or exception. It uses defined codes and allows a short sanitized note.

Availability helps the agent suggest a realistic date. It does not authorize a booking or reveal another person’s calendar. When Teams hosts the approval, the decision must return through a controlled API; a reaction or free-form message is not sufficient authorization.

Build the happy path around a human stop

Run the flow at the start of the workday or on the schedule approved by sales:

1. The scheduler sets the cutoff time, segment, and policy version.
2. The read tool gets open opportunities within scope.
3. Rules exclude closed, paused, recently active records and records with a valid future next step.
4. The agent reads each candidate again, summarizes permitted facts, and proposes an action from an approved catalog. Each proposal includes the detection reason and supporting fields.
5. Owner availability limits suggested dates. If it cannot be read, the proposal leaves the date for review.
6. The system groups proposals by owner and prepares a Teams digest or CRM queue.
7. A person confirms, corrects, pauses, sends to a management queue, or dismisses the case as a false alarm.
8. The tool reads the opportunity again. If its version is current, it writes the approved next step and records the decision; if the version changed, it stops and shows the conflict.

The recommendation should state its basis in plain language: “quote sent, six days with no recorded activity, and no future action.” It must not infer that the prospect lost interest, promise a delivery date, or draft an offer outside policy.

Treat exceptions as flow outcomes

A visible exception is preferable to an invented recommendation. Each case needs a reason code, opportunity ID, state read, required action, resolution owner, and entry time.

Exception	Agent response	Destination
Stage, latest activity, or a reliable date is missing	Does not prioritize or propose; lists missing fields	Data-quality owner
owner_id is empty, inactive, or absent	Does not send a personal reminder or reassign by itself	Sales-management queue
Opportunity is already closed	Cancels the proposal and records a stale case	Reconciliation and query correction
Activity appeared after the cutoff	Stops the write and shows the new version	Original owner, only if action is still needed
A valid next step already exists	Deduplicates and closes the alert as resolved	Evaluation record
Calendar or Teams is unavailable	Keeps the recommendation without an automatic date	Integration operations queue
CRM or ERP rejects the write	Does not report success; keeps the error and idempotency key	Integration operator

Retries help with timeouts after checking whether a write occurred. A missing field, inactive identity, or version conflict needs a decision rather than the same call again.

Evaluate rules, recommendations, and tools separately

Build a sanitized set of recent cases that includes valid future steps, overdue dates, pauses, late activities, absent owners, and closures after cutoff. Test three layers:

• the rule finds the right candidates and excludes ineligible records;
• the recommendation uses available evidence and an action allowed for the stage;
• the tools reject invalid permissions, fields, versions, or approvals.

Record false positives and omissions by reason. Check that proposals do not copy PII into Teams, a later change invalidates approval, and repeating the same write does not create two next steps. Test the global stop control and the procedure for correcting a field written in error.

Run a two-week pilot

Choose one team, one stage, and one follow-up policy. Before day one, capture a comparable baseline and document how each metric is counted. The guide to what to automate first helps keep the scope small.

Use shadow mode during the first week to compare the agent’s queue with the team’s review. Once rules and permissions work, move to recommendation and approved writes. The second week shows everyday use, corrections, and some real exceptions. It cannot establish a permanent commercial lift.

Metric	Pilot definition
Recovered contacts	Eligible opportunities found by the agent that lead to a recorded contact after human approval
Next-step coverage	Share of eligible opportunities that end with a valid type, date, and owner
False alarms	Alerts dismissed because activity, closure, pause, or a next step was not represented correctly in the query
Time to action	Time from detection to a recorded next step; report approval and actual contact separately
Human corrections	Changes to the suggested type, date, owner, or priority
Operational exceptions	Cases blocked by data, identity, permissions, versions, or integration failures

Report counts and rates with their denominators. A later contact does not prove that the agent caused a sale, and a closed opportunity is not an attributable recovery rate. At the end of the pilot, decide whether the queue is more reliable and actionable, which rules need adjustment, and which control level should remain.

Separate the agent from a Power Automate flow

Use Power Automate when a scheduled query, a set of conditions, and a template produce a stable output. It is a practical choice for reading a Microsoft source, applying stage thresholds, deduplicating, and sending an owner digest. The focused guide to Power Automate and Teams alerts covers that route.

The agent earns its place when the output requires permitted context from several tools, an explanation of priority, a recommendation from a catalog, and honest handling of incomplete information. Eligibility, permissions, and write controls remain deterministic. The model handles the ambiguous portion without replacing those barriers.

A hybrid architecture is often enough: Power Automate schedules the review and delivers the digest; an agent service prepares recommendations for the validated queue; the CRM stores state, approval, and outcome. If the rules-only flow already solves the problem, an agent adds operating cost and another failure surface.

When not to build it

Do not start the pilot when nobody can define the stages, data has no owner, activities are not recorded, or opportunities lack stable identifiers. Wait when the team has not agreed on what counts as a next step or cannot work the resulting queue.

Low volume and a reliable manual review may not justify an integration. A single source with fixed conditions probably needs the Power Automate flow linked above. When every next step requires a negotiation about price, availability, or a special commitment, keep the decision and communication with the sales owner.

Fix policy, fields, and ownership first. The agent can then turn a measurable omission into visible work without inventing context or making a commercial decision it does not own.