Keep handling support requests when the AI service fails

A support request should remain actionable for the team when automatic summarisation fails. The application needs a defined workflow without that function. Repeated model calls alone do not keep the work process running.

Separate intake from the AI step

In this fictional portal, a technical request is first saved in the case store. Its intake identifier is F-81. An acknowledgement appears only after storage is confirmed. An AI service is then supposed to create an internal summary. The original message remains readable by the responsible team.

If summarisation fails, the saved case can continue through the designated work queue. The interface shows the pending summary; it must not report a completed case. This design requires storage, permissions and the manual handling route to work independently of the failed AI step.

Connect failure types to next steps

Microsoft’s Retry pattern distinguishes transient failures from cases where retrying is not useful. Define suitable time and attempt limits for the specific service. The table describes expected responses in this example:

When access is denied, the responsible technical contact checks configuration and permissions. The application does not expand its own rights in response.

Resolve an uncertain write outcome first

A lost response can mean that storage has already succeeded. Microsoft highlights repeated effects when non-idempotent operations are executed again. Here, idempotent means that repeating the same task produces no additional business effect.

The storage route must handle repeats of the same intake identifier within the appropriate permission scope and be able to return an existing outcome. An identifier alone does not ensure this. An unknown state must not trigger a second case with a new identifier.

Define resumption and ownership

The NIST profile for generative AI discusses recovery plans, contact routes and alternative processes. Decide who takes over open cases and when automatic work may resume. The application must check a late AI text before allowing it to overwrite manual work that has since been reviewed.

Test an outage, denied access, an unknown save outcome and the service returning after manual handling. For each, check the original message, visible case state and next usable step. A reachable interface alone does not show that all open cases have resumed correctly.

Sources

• Microsoft — Retry pattern

• NIST — AI 600-1 Generative AI Profile, July 2024