---
title: "How to build an opportunity follow-up agent"
description: "A playbook for finding opportunities with no next step, recommending evidence-based actions, keeping people in control, and measuring a two-week pilot."
author: "Carlos García"
published: 2026-09-19
updated: 2026-09-19
language: en
human_url: "https://kiia.cloud/blog/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](/blog/first-ai-agent-recover-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](/blog/stale-opportunities-teams-alerts-power-automate/). 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:

```text
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](/blog/copilot-or-autopilot-ai-agent-autonomy/) 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](/blog/what-to-automate-first-in-a-business/) 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](/blog/stale-opportunities-teams-alerts-power-automate/) 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.

## Frequently asked questions

### What does it mean for an opportunity to have no next step?

It means the opportunity is still open and within the pilot scope, but it has no valid future action with a type, date, and owner, or that action is overdue. The rule should also check stage, latest activity, pauses, and exclusions before creating an alert.

### When should we use an agent, and when is Power Automate enough?

Power Automate is usually enough when one source, one schedule, and deterministic rules always produce the same alert. An agent adds value when it must gather authorized context, explain a priority, propose a next step, and handle exceptions within explicit permissions and controls.

### Should the agent contact prospects autonomously?

Not during the pilot. The agent can detect, explain, recommend, and prepare an internal reminder. A person chooses the next step and approves any external communication. Execution should expand only for repeatable actions with tested eligibility, volume, stop, and audit rules.