# Customer Support Playbooks Last reviewed: 2026-07-01 Owner: Customer support lead Approvers: Operations, compliance, security, legal/product communications These playbooks give support a safe first response and escalation path. Support does not diagnose ledger/provider internals, make compliance decisions, submit or replay payments, alter balances, or promise recovery before the responsible team confirms the outcome. ## Non-Negotiable Safety Rules - Verify the customer using the approved support identity process before discussing account-specific information. Do not use email address or caller ID alone. - Never ask for or accept a password, full card PAN, CVV, TOTP/OTP, recovery code, private key, seed phrase, access/refresh token, or provider secret. - Never paste restricted data into chat, tickets, notes, screenshots, or analytics. - Use view-only support impersonation only with a ticket reference, reason, scoped actions, expiry, and customer-safe purpose. It does not bypass authorization. - Do not reveal sanctions/AML/fraud rules, match details, SAR/STR existence, internal risk scores, security detection logic, or another customer's information. - Money corrections use approved finance/ledger workflows and maker-checker. Support never edits balances or marks external execution complete. - Record facts, exact customer wording, timestamps, transaction/card/provider references visible to support, impact, actions, and escalation. Avoid speculation. ## Intake And Priority 1. Confirm contact channel, customer identity status, preferred accessible channel, affected product, start time, transaction/reference, and customer-visible error. 2. Check approved status/incident notice and the customer-safe account timeline. 3. Classify and route the case: | Priority | Examples | Route | | --- | --- | --- | | Critical | Funds/balance visibly wrong, suspected takeover with movement, broad outage, exposed sensitive data | Incident commander plus finance/security immediately | | High | Payment unknown/double, card spend after freeze, locked customer with urgent risk, missed complaint deadline | Operations/finance/security/compliance immediately | | Medium | Delayed payment within investigation, KYC review, isolated card/FX issue | Owning queue within approved SLA | | Low | General product question, disclosure, non-urgent profile guidance | Standard support queue | 4. Create/link a backoffice case. A complaint remains a complaint even when an incident or fraud case also exists. 5. Give only confirmed status, next update time, safe self-service steps, and case reference. Do not invent an ETA. ## Login, MFA, And Suspected Account Takeover Customer-safe actions: - Ask the customer to stop approving unexpected prompts and use a known-safe device. - Revoke active sessions through the approved authenticated/support escalation process; route MFA reset through secure maker-checker identity proofing. - For suspected takeover, escalate to security/fraud and request proportionate payment/card containment through the owning team. Evidence: contact/verification method, reported timeline, devices/sessions visible to support, disputed actions, containment requests, and security case ID. Never disable MFA informally, issue recovery codes, ask the customer to read an OTP, or disclose IP/device detection details. ## Payment Pending, Failed, Missing, Or Duplicated 1. Confirm transfer reference, amount/currency, beneficiary display, initiation time, and customer-visible status without requesting full bank credentials. 2. Check notification and approved status. Distinguish accepted/pending, held for review, failed/refunded, completed, and unknown; do not translate unknown into failed or completed. 3. For overdue/unknown/duplicate status, route to payments operations with transfer, settlement, provider, and reconciliation references available to support. 4. For wrong visible balance, also page finance and use the reconciliation-break playbook. Do not create a manual credit as a temporary fix. 5. Communicate confirmed result, refund/value-date information, fees, and next update after operations approval. Use `docs/runbooks/settlement-break.md` for settlement issues and `docs/runbooks/reconciliation-break.md` for balance/report differences. ## Card Decline, Freeze, Unknown Transaction, Or Dispute - Decline: confirm card status, last four digits, time, amount/currency, and merchant descriptor. Do not request PAN/CVV. Explain only customer-safe decline reasons. - Lost/stolen or unknown spend: guide authenticated customer to freeze/cancel; escalate active fraud immediately and record disputed authorization references. - Spend after freeze/cancel or duplicate clearing: high priority to card operations and finance; preserve processor event and lifecycle timestamps. - Dispute: create/use the supported dispute workflow, provide approved evidence requirements and deadlines, and avoid guaranteeing chargeback success. ## Balance Or Ledger Discrepancy Treat any credible wrong available/reserved balance as high priority and broad or spendable error as critical. 1. Record screenshot only through approved secure upload, plus account/wallet, currency, expected/visible amount, time, and related movements. 2. Page finance operations; link a reconciliation case and incident where required. 3. Tell the customer the balance is being investigated and whether any confirmed temporary product restriction applies. 4. Do not calculate or apply a correction, advise repeated retries, or label a journal/provider discrepancy as resolved. ## KYC Or Account Review - Explain required customer actions and accepted document categories from approved policy. Do not advise how to evade provider checks or share match/risk details. - Use secure evidence channels only. Never accept identity documents in an ordinary chat or personal mailbox. - Route pending beyond SLA, accessibility difficulty, provider technical failure, or disputed identity outcome to compliance/KYC operations. - Use neutral wording for reviews: support cannot confirm or deny AML, sanctions, PEP, adverse-media, or regulatory-report activity. ## FX Rate Or Fee Complaint 1. Capture quote/conversion ID, displayed rate, fee/spread, quote expiry, source and destination amounts, and customer timestamp. 2. Compare the stored quote/receipt and disclosure version; do not recalculate from a current market rate. 3. Route stale/wrong execution or missing disclosure to FX operations/finance and create a complaint case when dissatisfaction is expressed. 4. Any adjustment needs finance approval and a linked ledger workflow. ## Crypto Or Stablecoin Issue - Confirm asset, exact network, custody/transaction reference, address display, and customer-visible confirmations. Never ask for private keys or seed phrases. - Warn the customer not to resend while status is unknown. - Wrong network/address, withdrawal unknown, reorg, custody outage, address risk, or depeg routes immediately to crypto operations/risk/compliance as applicable. - Do not promise transaction reversal or finality; only the approved custody/chain evidence determines status. ## Service Or Provider Outage 1. Link the active incident and use its approved customer message/version. 2. State affected services, known-safe workaround, customer action, and next update time. Do not name a provider or root cause until approved. 3. Tag contacts by incident/product for affected-customer analysis. 4. Do not encourage repeated payment/login/card attempts during degraded mode. 5. Send resolved message only after the incident owner confirms technical recovery and financial reconciliation. ## Privacy Or Security Report - Potential data exposure, phishing, vulnerability, misdirected statement, or unauthorized access routes immediately to security/privacy with the original report preserved. - Do not ask the reporter to send additional sensitive data or exploit details in public channels. Use the vulnerability disclosure/security channel. - Data-subject access/deletion/correction requests use the privacy workflow; support verifies and routes, but does not export/delete data directly. - Do not promise breach status or notification timing before security/privacy/legal assessment. ## Complaints And Vulnerable Customers - Record dissatisfaction as a `customer_complaint` with received time, channel, issue, requested outcome, jurisdiction and applicable deadline. - Identify accessibility, language, financial hardship, coercion, bereavement, or other vulnerability sensitively and offer approved accommodations. - Acknowledge and update using legal-approved market templates. Give external escalation rights in the final response where required. - Never close a complaint merely because a linked technical issue is fixed; response and remediation evidence must be complete. ## Communication Templates Initial acknowledgement: > We have recorded your report under case [reference]. We are checking the confirmed > account and processing records. Please do not repeat the action while its status > is uncertain. We will update you by [time/channel]. Under investigation: > Your case is still being investigated by our [payments/card/security] team. We > have not yet confirmed the final outcome. Your next update is due by [time]. Resolved incident: > Service has been restored and the checks for your case are complete. [Confirmed > outcome and customer action.] Contact us under [reference] if this does not match > what you see. Templates require legal/product approval and localization before live use. Remove internal team names or details when the incident communication owner requires it. ## Shift Handover And Closure Handover includes case/incident IDs, verified facts, customer impact, last message, next promised update, owner, SLA, blockers, and restricted-case links only for authorized staff. Close after customer-safe outcome/remedy, communications, escalations, evidence, root-cause link, and follow-up are complete. Sample closed cases for quality, data minimization, policy adherence, and fair outcomes.