LearnGrok
Prompts
PromptIntermediateRunning Bots safely

Chargeback evidence pack for dispute review

Build a review-ready chargeback evidence pack from order records and customer messages, for support teams preparing specialist cases.

5 min read

Use these prompts to turn scattered case records into a file a specialist can review quickly. They are for support teams preparing disputed-payment cases, not for deciding liability or making the final submission.

Start with the intake prompt. It tells you what is present, what conflicts, and what must be found before anyone writes a case summary. Then build the chronology and inventory. Use the handover summary only when those two documents are stable.

Key point

Build from records, not recollection

Keep each factual statement tied to a dated source document. A neat summary cannot repair a missing or contradictory record.

Work through the case in order

  1. Collect the source records

    Gather the order confirmation, transaction record, fulfilment events, delivery record, refund or return activity, customer messages, and internal notes. Paste the material in date order where possible. Keep the original wording of customer messages and event statuses.

    Remove information that is not needed for the review, such as unrelated account notes. Do not remove a date, order number, event identifier, or the name of the system that produced a record. Those fields let the reviewer trace a statement back to its source.

    If you are using file uploads or platform features to provide records, their availability can vary. Check the relevant setup guidance in the xAI documentation overview before changing your workflow.

  2. Run Case intake and evidence triage

    Use the intake output as the control sheet for the case. Check that its Case identifiers match the transaction and order record. If it lists more than one transaction, split the work into separate packs unless your internal process says otherwise.

    The useful part is usually Evidence gaps. Turn each gap into an owner and a request. For example, a dispatch event without a delivery event is not proof of delivery. A customer saying an item did not arrive is a statement, not a delivery record. Keep both, and label them correctly.

Watch out

Do not turn system status into a stronger claim

Label created, dispatched, out for delivery, and delivered are different events. Include the exact carrier wording and timestamp.

  1. Make the chronology before writing prose

    Run Evidence chronology once the main records are present. Read the rows from top to bottom. This exposes the gaps that a folder of screenshots hides: a refund recorded before a customer contact, a delivery date after an alleged cancellation, or two versions of the same event.

    Do not force uncertain records into a sequence. Use not stated for a missing timezone and low confidence for an undated note. A reviewer can work with uncertainty that is labelled. They cannot safely work with uncertainty disguised as fact.

  2. Build the inventory and request missing records

    Run Evidence inventory and gap log after the chronology. This separates documents that support a specific fact from documents that merely provide background. Mark incomplete screenshots and internal notes carefully. They can help the reviewer understand the case, but they may not be suitable for inclusion in the final evidence set.

    When the pack is blocked, use Missing evidence request rather than sending a vague message such as “please send proof”. Ask for the exact event, identifier, date range, or status field. Record a negative response too. “No signature record exists” closes a gap more clearly than an unanswered request.

Note

Keep a source reference in every file name

Use a consistent internal pattern such as order-record_2026-08-04, carrier-event_2026-08-06, or customer-message_2026-08-07. Do not rename a record so its date or origin becomes unclear.

Check the pack before handover

Use the table below to review common failures. Do this before generating the specialist summary.

If you see this Treat it as What to do
A delivery status with no timestamp Incomplete delivery evidence Request the full carrier event history or mark the date as unknown
A customer message contradicting a system record A material conflict Include both sources and quote the relevant wording
A refund mentioned in notes but absent from payment records Unverified internal claim Request the payment or refund transaction record
Two order numbers in one conversation Possible mixed case Confirm which order the dispute concerns and split the pack if needed

Check

A reviewer should be able to trace every key fact

For each statement about payment, fulfilment, delivery, cancellation, return, or refund, check that the pack names a source document and date. If it cannot, move it to Outstanding evidence.

The output is wrong if it fills a gap with a plausible assumption. Watch for phrases such as “therefore”, “clearly”, “must have”, or “likely” where the source does not establish the point. Also check for silent changes to dates, currencies, order numbers, and customer wording. These errors often appear when material contains duplicate records or copied internal notes.

Prepare the handover

Run Specialist handover summary last. Read the Neutral account of events against the chronology, not against memory. The summary should describe what each record says and identify conflicts. It should not argue the case or make a decision reserved for the specialist or manager.

Attach or retain the source documents named in Evidence included. If the summary refers to “proof of delivery” but the inventory calls it an incomplete delivery screenshot, correct the summary. The document names, dates, and limitations must match across the pack.

When the output does not work

If the output is too general, paste fewer records and start with the chronology or inventory prompt. If facts are mixed between orders, run separate prompts for each order. If a prompt invents a field or overlooks a conflict, add the missing source record and ask it to rebuild only that document.

Do not patch a doubtful summary by rewriting its conclusion. Go back to the intake, chronology, or evidence gap log, fix the source trail, then generate the handover again. If key records remain unavailable or the case includes a material contradiction, route it to the specialist or manager with the gap clearly stated.

Copy-ready prompts

5 prompts. Open one to read it, or take the whole pack.

1Case intake and evidence triageUse this first when a new payment dispute reaches the queue and the records are spread across several systems.
Create a document called `Dispute intake and evidence triage` from the case materials below.

Case materials:
- Dispute reference: [reference]
- Order record: [paste order record]
- Payment and refund record: [paste payment record]
- Delivery or fulfilment events: [paste carrier tracking, proof of delivery, or service-delivery events]
- Customer correspondence: [paste messages in date order]
- Previous support actions: [paste internal notes]
- Dispute reason stated by the customer or payment provider: [paste reason]

Return the answer in this exact format:
1. `Case identifiers`: dispute reference, order number, customer identifier, transaction date, amount, currency, payment method, and dispute reason. Write `not provided` for any absent field.
2. `Materials received`: a table with columns `Item`, `Source`, `Date range`, `What it may evidence`, and `Quality concern`.
3. `Initial timeline`: dated events only, in chronological order. Label each event as `customer statement`, `merchant record`, `carrier record`, or `internal note`.
4. `Evidence gaps`: a numbered list. For each gap, state the missing document or field, why it matters, and the team or system most likely to hold it.
5. `Conflicts requiring review`: list every mismatch between sources. Quote the conflicting values or dates.
6. `Routing recommendation`: choose one of `ready for evidence pack`, `needs more records`, or `specialist review needed`. Give a one-sentence operational reason.

Do not decide whether the dispute should be won, lost, accepted, or challenged. Do not infer missing dates, delivery status, customer intent, or authentication details. If a source is unclear, preserve its wording in quotation marks and mark it `unclear`.
2Evidence chronologyUse this after intake when the reviewer needs one timeline rather than separate order, delivery, and conversation records.
Create a document called `Dispute evidence chronology` using the materials below.

- Dispute reference: [reference]
- Order and payment events: [paste records]
- Fulfilment and delivery events: [paste records]
- Customer correspondence: [paste messages]
- Refund, replacement, cancellation, or return events: [paste records]
- Internal support notes: [paste notes]

Return a table with these columns, in this order: `Date and time`, `Timezone`, `Event`, `Source document`, `Source type`, `Exact supporting detail`, `Relevance to dispute`, `Confidence`.

Use `merchant record`, `carrier record`, `customer statement`, or `internal note` in `Source type`. Use `high`, `medium`, or `low` in `Confidence`, based only on whether the source gives a clear date and direct evidence.

After the table, add:
1. `Sequence issues`: events with no reliable date, duplicate events, or events that appear out of order.
2. `Conflicting accounts`: a list of disagreements between customer statements and operational records. Include the source and exact wording or value for each side.
3. `Missing timeline evidence`: records needed to establish an important event, such as dispatch, delivery, cancellation, refund, return receipt, or customer contact.

Do not merge events that merely appear similar. Do not convert an estimated delivery date into a confirmed delivery event. If timezones are absent, write `not stated`.
3Evidence inventory and gap logUse this when you have collected documents and need to show the specialist exactly what supports each factual point.
Create a document called `Dispute evidence inventory and gap log` from the case materials below.

- Dispute reference: [reference]
- Dispute reason: [reason]
- Order record: [paste]
- Payment record: [paste]
- Delivery, collection, or service-completion record: [paste]
- Customer messages: [paste]
- Refund, replacement, cancellation, or return records: [paste]
- Internal notes and prior actions: [paste]

Return two tables.

First table title: `Available evidence`. Use columns: `Evidence item`, `Document or system source`, `Relevant date`, `Fact supported`, `Direct quote or record value`, `Reliability note`, `Pack status`. Set `Pack status` to `include`, `include with caveat`, or `do not include`.

Second table title: `Evidence gaps`. Use columns: `Missing item`, `Fact it would verify`, `Why current records are insufficient`, `Likely owner`, `Request wording`.

Then add `Evidence handling notes` with up to five bullets. Flag duplicate files, redacted or incomplete screenshots, records with conflicting dates, and internal notes that are not suitable as external evidence.

Treat only the pasted material as evidence. Do not claim that a policy, device data, identity check, delivery signature, or customer admission exists unless it is supplied. Where a record supports more than one fact, create one row per fact.
4Specialist handover summaryUse this when the evidence is assembled and a specialist or manager needs a short, neutral case brief before submission.
Create a document called `Dispute specialist handover summary` from the materials below.

- Dispute reference: [reference]
- Dispute reason and deadline, if known: [paste]
- Completed evidence chronology: [paste]
- Evidence inventory and gap log: [paste]
- Order, payment, fulfilment, refund, and correspondence records: [paste]

Return the following sections in this exact order:
1. `Case at a glance`: order number, transaction date, amount and currency, dispute reason, fulfilment method, and current case status. Write `not provided` where needed.
2. `Neutral account of events`: 150 to 250 words, in date order. Attribute disputed statements to their source.
3. `Evidence included`: bullet list. Each bullet must name the document, the date, and the fact it supports.
4. `Material conflicts`: bullet list of facts that disagree across sources, with both source references.
5. `Outstanding evidence`: numbered list, ordered by importance. State the exact record requested and its likely owner.
6. `Reviewer decisions needed`: numbered list of operational questions for the specialist or manager.
7. `Submission readiness`: choose `ready for specialist review`, `blocked by missing evidence`, or `requires record correction`, followed by a concise reason.

Write neutrally. Do not state that fraud occurred, that the customer is truthful or untruthful, or that the case should be submitted, conceded, or rejected. If a conclusion depends on an absent document, describe it as an open question.
5Missing evidence requestUse this when the pack is blocked and you need clear requests for warehouse, delivery, payments, or support colleagues.
Create a document called `Dispute missing evidence request log` from the case details below.

- Dispute reference: [reference]
- Order number: [order number]
- Dispute reason: [reason]
- Evidence already held: [paste inventory]
- Missing or unclear records: [paste gap log]
- Teams or system owners available: [list]
- Submission deadline, if known: [date or not known]

Return:
1. A table with columns `Priority`, `Requested record`, `Exact fields needed`, `Why it is needed`, `Owner`, `Request channel`, `Requested by date`, `Status`.
2. A set of ready-to-send internal request messages. Give one message per owner. Each message must include the dispute reference, order number, exact records requested, and a request to confirm if no record exists.
3. `Escalation trigger`: list the conditions that should move the case to a specialist or manager, such as conflicting payment records, missing transaction identifiers, or a delivery event that cannot be verified.

Use `high`, `medium`, or `low` for priority. Do not invent deadlines, owners, or system names. If no owner is supplied, set `Owner` to `unassigned` and include an internal message addressed to `Case owner`.

Last checked against xAI’s own pages on 2026-08-21. Grok changes quickly; anything version-specific should be confirmed upstream before you rely on it.

More in Running Bots safely

Found something out of date?

Grok changes quickly and this page is a snapshot. If something here is wrong, or you know a better resource, send it over.

Suggest a link →

Advertise on LearnGrok

$420.69one-time, for a 30-day run

Square works best. PNG, JPEG or WebP, up to 2 MB.

Stripe on the next step. Live once approved.