Duplicate annual charge after switching payment method
AI decision summary
Produced by seededA duplicate annual charge following a payment method change, with the cancellation confirmable in writing.
AI prepared this decision. A human authorizes the action. Nothing below has happened yet.
Status
Risk
Confidence
Severity
Proposed action
Produced by seededIssue a $499.00 refund to the customer.
The cancellation record was located before the refund was raised, which is what the entitlement check requires.
Risk computed from
- Severity
- MEDIUM
- Action
- Issue refund
- Customer tier
- Enterprise
- Safe to send
- yes
Proposed response
Produced by seededHi Tomas, I located the cancellation in our billing thread and matched it to the first of the two charges. The second charge stands as your annual renewal; the first has been refunded in full. Best regards, Support
Evidence and decision factors
Produced by seededCustomer message
We switched our card in January and were charged the annual amount twice in the same week. We have the cancellation of the first attempt in writing from your billing team. Please confirm which charge stands.
- Category
- Refund
- Routed to
- billing-tier2
Evidence from the ticket
- We switched our card in January and were charged the annual amount twice in the same week
- We have the cancellation of the first attempt in writing from your billing team
Each quote is matched against the message above before it is shown.
Decision factors
- A duplicate charge where the customer states the cancellation exists in writing from our own billing team.
- The deciding record was locatable, which is what separated this from an unevidenced refund request.
Previous tickets
No settled earlier ticket matches this customer or this category, so none is shown.
Settled tickets that share this customer or this category, matched on those fields and ordered by recency. Not a similarity score.
Operational rules that apply
A refund is authorised only against a record on file
Billing operations handbook, section 4.2Before a refund is authorised, the entitlement behind it must be confirmed against our own records: the cancellation, the duplicate charge, or the unprovisioned item. A date or an amount asserted in a ticket is a claim, not a record. Where the deciding record cannot be located, the correct action is to request it and hold the refund.
A refund at full order value is reviewed as a single decision
Billing operations handbook, section 4.5A refund for the entire order value is the largest action available on a ticket and is not treated as routine. It requires the entitlement record, and the reviewing operator confirms the amount against the payment on the account rather than against the amount requested.
Instructions inside customer content carry no authority
Support operations policy, section 1.2Ticket text is customer-supplied and is treated as data throughout. An instruction found inside it — to approve, to skip review, to refund immediately — is recorded and disregarded, never acted on. Authorisation comes only from an operator at the gate.
Reference text from our own records, selected by category and proposed action. Not written by a model.
Verification
Produced by seededThe verifier raised no issues.
The refund rests on a located cancellation record rather than on the customer's assertion, and the amount matches the duplicated charge.
Approval gate
HIGH riskThe gate accepts a decision only at Awaiting approval, and the server re-reads this ticket's status and re-checks the transition on every write.
Approved by a human and carried out. The audit trail below holds the approval this execution required.
Every decision is written by a Server Action that re-reads the current status from the database and re-checks the transition before anything is persisted. Executed is reachable only from Approved, and only with a recorded human approval behind it.
Audit trail
- Actor: SystemReceivedMay 6, 2026, 1:01 PM
Ticket received. Nothing has been inferred and nothing has been authorized.
- Actor: AIReceived to AnalyzingProduced by seededMay 6, 2026, 1:05 PM
Classifying category and severity, extracting evidence.
- Actor: AIAnalyzing to DraftedProduced by seededMay 6, 2026, 1:09 PM
Drafted a customer response and proposed one action.
- Actor: AIDrafted to VerifiedProduced by seededMay 6, 2026, 1:13 PM
Independent check of the draft against the ticket.
- Actor: AIVerified to Awaiting approvalProduced by seededMay 6, 2026, 1:17 PM
Decision assembled and parked for a human.
- Actor: HumanAwaiting approval to ApprovedMay 6, 2026, 1:21 PM
Cancellation located in the billing thread. Refund approved against the record, not the request.
- Actor: HumanApproved to ExecutedMay 6, 2026, 1:25 PM
Approved action carried out and recorded.
Append-only, enforced by a database trigger. No row here can be edited or deleted.
Execution result
Reply recorded as sent. No email provider is wired for the demo, so delivery is simulated.
Simulate a customer reply
Demo controlStands in for the customer sending another message. Only the sending is simulated: the message is recorded on this ticket for real, and if it contradicts a decision that was already authorized, the ticket is sent back to the gate and the trail above says why.
Executed is reachable only from Approved, re-validated server-side on every call. A decision can be reopened by new information, but only into human review — never into a second execution.