Knowledge & actions · Explore this field ↗ · Implementation · 2 min read
Design transactions for reversal
A conversational action needs the same rigor as a form—plus protection from ambiguity and duplicate turns.
See the source / a related case
Conversation does not remove the form
The fields still exist even when they are collected through natural language. Define required values, validation, defaults, dependencies, and error messages in a transaction schema. Show a structured review surface before submission. Let users edit one field without restarting. For regulated consent, preserve the exact language and version presented.
Separate proposal from execution
The system should be able to draft a change without making it. Use explicit states such as collecting, ready for review, confirmed, submitted, succeeded, failed, and unknown. Bind confirmation to a snapshot. If the price or availability changes after confirmation, return to review instead of silently substituting.
Make duplicate safety visible
Messages are retried; users resend when the interface stalls; networks fail after the server commits. Every write call needs an idempotency strategy. Receipts and case IDs should come from the system of record. A bot-generated sentence is not evidence that a refund or reservation exists.
Failure mode
The most dangerous transaction bot is not one that fails loudly. It is one that speaks as if it succeeded while downstream status is unknown. Instrument unknown outcomes, reconciliation delay, manual corrections, and duplicate prevention.
A cancellation example
A subscription cancellation conversation should first retrieve the plan and effective terms, then present the end date, retained access, refund consequence, and items that will be lost. The user edits any incorrect assumption before confirming that exact snapshot. The application sends one idempotent cancellation request and displays the billing-system receipt. If the response times out, the bot checks status before offering retry. Reversal rules are shown immediately. This may feel more formal than casual chat, but consequential service should become more structured as commitment approaches.
Primary reading
Sources and limits
These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.