Recommended next action

Problem Context

• The user is already inside a work object such as a case, conversation, claim, sales record, incident, renewal, lead, approval, or task.
• The system has signals such as customer intent, status changes, similar cases, policy rules, playbooks, churn risk, SLA risk, missing fields, conversation history, or model output.
• The suggested action can have consequences such as sending a message, changing status, applying an offer, opening a workflow, escalating, requesting information, or resolving a case.
• A bad recommendation can cause wrong work, duplicate work, privacy leakage, compliance violations, customer harm, or loss of trust.

Selection Rules

• Choose recommended next action when the system proposes a concrete action that is immediately relevant to the current work object and user role.
• Use recommendations when the surface suggests multiple discoverable items or content options rather than one actionable workflow step.
• Use task list when the steps are known required tasks with persistent completion status rather than inferred or contextual suggestions.
• Use review queue when the user needs to triage many actionable records rather than decide the next step for one current record.
• Use approval workflow when a routed approve or reject decision is required by policy instead of recommended by context.
• Use assignment when the decision is who owns the work rather than what action should happen next.
• Use handoff summary when transfer context and ownership are primary; include next action inside the handoff rather than replacing the summary.
• Show the trigger, evidence, reason, confidence or rule basis, eligibility, consequence, and scope before the user accepts the action.
• Require review or confirmation when the action sends external communication, changes money, closes work, updates legal status, changes permissions, or affects another person.
• Suppress or block suggestions when prerequisites, consent, permissions, freshness, policy, duplicate work, or user role make the action unsafe.
• Let users defer, dismiss, mark already done, give a reason, or choose another action without corrupting required workflow state.

Required States

• No recommendation state with normal workflow controls still available.
• Recommended action state with action title, reason, evidence, trigger, consequence, and accept or review path.
• Review-before-apply state for messages, status changes, offers, escalations, and high-impact actions.
• Accepted, deferred, dismissed, already-done, feedback-submitted, and replacement-suggestion states.
• Low-confidence, rule-based, AI-generated, human-curated, and playbook-driven recommendation states.
• Blocked by permission, missing prerequisite, stale data, duplicate work, policy conflict, consent conflict, and already-completed states.
• Mobile or narrow-screen state where the reason, consequence, and controls remain visible before accept.

Interaction Contract

• Accepting or reviewing the recommendation opens the proposed action with context preserved and does not silently commit high-impact changes.
• Dismissing a recommendation removes only the suggestion and records feedback within the stated scope; it does not delete the underlying record or required tasks.
• Deferring keeps the action explainable and returns it at the chosen time or state change without hiding alternatives.
• When the recommendation reason changes, the visible reason and eligibility update before the action can be accepted.
• Blocked suggestions cannot be accepted until the missing permission, prerequisite, consent, or freshness issue is resolved.
• Feedback, dismissal, accept, and failure outcomes are announced through a stable status region and logged for audit where the action has operational consequence.
• Users can always access the ordinary workflow path if no suggestion is safe or useful.

Implementation Checklist

• Define the action model with action ID, source, trigger, evidence, score or rule, owner, role eligibility, consequence, prerequisites, freshness, and audit needs.
• Separate suggested action state from required task state, assignment state, approval state, broad recommendations, notifications, and primary action buttons.
• Provide reason and evidence copy that maps to real signals such as customer intent, similar case, SLA risk, missing field, policy rule, or playbook step.
• Gate high-impact actions behind review, confirmation, or draft editing and show what object, person, amount, channel, or status will change.
• Add controls for accept, review, defer, dismiss, already done, feedback reason, and fallback action.
• Revalidate permissions, prerequisites, consent, duplicate work, and stale data immediately before applying the action.
• Test low confidence, stale recommendation, missing permission, policy conflict, already handled, replacement suggestion, mobile wrapping, keyboard flow, and failure recovery.

Common Generated-UI Mistakes

• Calling a static primary button a recommended next action without context-sensitive logic or reason.
• Hiding why the action was suggested, what evidence was used, or what will change.
• Mixing required tasks, optional suggestions, assignments, approvals, and queue rows in one undifferentiated list.
• Letting dismiss hide a required task or delete the underlying work item.
• Applying high-impact actions instantly without review, confirmation, or undo where appropriate.
• Showing stale, permission-blocked, duplicate, consent-conflicting, or already-completed suggestions as active actions.
• Presenting low-confidence AI output as the only safe path.

Critique Questions

• What exact signal, rule, model, or playbook caused this action to be recommended now?
• Can the user see what will happen if they accept the action before it commits?
• Is this optional guidance, a required task, an approval, an assignment, or a queue item?
• What permissions, prerequisites, consent, freshness checks, and duplicate-work checks gate the action?
• Can users dismiss, defer, mark already done, or give feedback without damaging workflow state?
• What ordinary workflow path remains available when the recommendation is wrong or absent?