Renewal Pipeline Orchestration

Run scheduled 90/60/30-day renewal sweeps across the book of business, turning upcoming policy expirations into outreach and per-policy board tasks while keeping a durable memory of retention outcomes.

When to use

On a recurring cron (daily or weekly) to catch every policy crossing the 90, 60, or 30 day-to-renewal threshold.
When a producer or account manager asks "what's renewing this month" and needs a task board built, not just a list.
After a renewal outcome (renewed, lapsed, marketed elsewhere) to record retention history for future sweeps.
When outreach needs to go out to policyholders ahead of an AMS (agency management system) renewal deadline.

Tools

http-get
create-task
schedule-task
send-email
update-memory

Playbook

Confirm the sweep is running on a recurring cadence via schedule-task (e.g. daily at 06:00) so 90/60/30-day windows are never missed between runs.
Pull the active book of business from the agency management system with http-get (e.g. GET https://api.amsvendor.com/v1/policies?status=active&expires_before=90d). Auth is injected by the org's Integration row for this host — never ask for, echo, or hardcode credentials. On 401/403 or missing Integration, stop and message a human via send-message naming the service and scopes.
Bucket the returned policies by days-to-renewal (90, 60, 30) and skip any policy already flagged as bound-to-renew or cancelled in the response.
For each policy entering the 90-day window, create a per-policy board task with create-task describing the policyholder, policy number, line of business, and expiration date, and assign it to the account manager of record.
For each policy entering the 60-day window with no recorded producer response, draft and send a renewal reminder to the policyholder with send-email, keeping the tone informational — never quote premiums, limits, or coverage terms.
For each policy entering the 30-day window still unresolved, escalate the board task priority with create-task (a follow-up task tagged "urgent") and note the approaching hard deadline.
After each sweep, record retention signals with update-memory — e.g. which policies moved stages, which policyholders were unresponsive, and any prior-year renewal outcome, so the next sweep can compare trends.
If a policyholder replies asking about coverage changes, limits, carrier options, or whether coverage is bound, do not answer — create a board task via create-task tagged for a licensed agent and stop.
If the sweep discovers a request for a COI (certificate of insurance) for a non-standard holder, or any endorsement request, create a human-gated board task via create-task instead of acting on it.

Failure modes

The AMS API paginates or rate-limits results, causing a sweep to silently miss policies past the first page — always check for a next-page cursor before concluding the sweep is complete.
A policyholder email bounces or the address is stale, leaving a 30-day-window policy with no outreach sent — flag this as a board task rather than retrying silently.
Duplicate board tasks get created when a policy appears in both the 60-day and 30-day sweep before the prior task is closed — check update-memory history for an open task on that policy number before creating a new one.
Coverage, limits, carrier, or claims-fault questions arriving inside a "renewal" reply get treated as routine outreach instead of being escalated to a licensed agent.

Done when

Every policy in the 90/60/30-day windows has a corresponding board task with current status and an assigned owner.
Retention memory is updated with this sweep's outcomes, and any coverage, binding, COI, endorsement, or claims question has been routed to a human via a board task, never answered directly.