Revenue AI exception handling: retries, escalations and recovery without duplicate work

An exception is any condition that prevents a revenue workflow from reaching a trustworthy completion inside its normal path. It may be a missing field, a denied permission, a timeout, a changed record or a human decision that arrives after the draft was prepared.

Retries are only one possible response. A managed workflow needs to prove what completed, classify the failure and choose among retry, correction, hold, escalation or cancellation. Otherwise a transient issue can become a duplicate CRM task, repeated review request or customer-facing message.

Use an exception taxonomy

The error message should not decide the operating response by itself. Classify the condition by cause, current state and authority. A timeout can be transient, but an uncertain write still requires reconciliation. A permission failure is persistent until an authorized owner changes access.

Checkpoint around every side effect

Before a write, store the stable work ID, proposed change, source versions, approval and intended destination. After the write, store the destination reference and readback. If the response is uncertain, the before-checkpoint tells the operator what to look for and the after-checkpoint prevents a later run from repeating it.

• Use a stable idempotency key tied to the business action.
• Record the current workflow and source version.
• Preserve the exact approved payload or proposal.
• Store attempt time, response and destination reference.
• Verify final state independently when the system allows it.
• Mark completion only after both data and delivery are confirmed.

Read before retry

A missing or timed-out response is not proof that the mutation failed. Search the destination using stable identity and expected attributes. If the intended object or message exists, attach its reference to the checkpoint and move forward. If it does not exist, confirm that inputs and approval are still valid before trying again.

If the destination cannot answer reliably, do not invent certainty. Hold the work with the attempt evidence and route it to an operator. One ambiguous item is safer than two externally visible actions.

Separate local failure from workflow failure

A multi-step workflow should not restart because one step failed. If research and planning completed but a CRM write was denied, preserve the accepted upstream work and resolve the permission boundary. If Slack delivery failed after the Sheet update, resume delivery without rebuilding the data.

This requires explicit stage status. Prepared, review-ready, approved, attempted and confirmed-complete are different states. Collapsing them into “done” makes partial recovery unsafe.

Escalate with a decision packet

An escalation should reduce work for the owner. Include the stable ID, intended outcome, completed stages, exact blocker, current evidence, prohibited next steps and the one decision or corrective action required. Keep one open alert per underlying blocker instead of creating a new reminder every run.

Review incidents for prevention, not blame

After recovery, ask whether the exception was expected, detectable and contained. Update the scenario set, checkpoint, rule or owner when the same class could recur. Do not rewrite the workflow around a single unusual case without checking frequency and impact.

• Was the exception classified correctly?
• Did the workflow preserve completed work and avoid duplicates?
• Could the operator see the evidence and permitted next action?
• Did recovery meet the service expectation?
• Which test, rule or monitor should change before the next release?

Unknown outcomes need their own queue state

A timeout is not proof of failure. The destination may have accepted the request while its response was lost. Treat that as an unknown outcome until reconciliation can establish what happened. Blindly retrying the entire workflow can create a duplicate note, task, notification or commercial action.

The exception record should preserve the work identity, the step attempted, the intended destination, the last verified state and the evidence needed to reconcile it. Assign an owner and a next review time. Do not mark the work Done merely because the retry limit was reached.

Use a recovery decision table in the acceptance test

Choose representative failures before deployment. For each, define the safe action and what evidence must exist before that action is allowed. A policy denial should not enter the same retry path as a transient connection failure.