Scoutinternal

Handling Ticket Status Inquiries, Reopened Tickets, Subpoenas, and Internal Test Tickets

Handling Ticket Status Inquiries, Reopened Tickets, Subpoenas, and Internal Test Tickets

Problem

Customers frequently contact BitGo support about the status of existing tickets, complain that tickets were prematurely marked as resolved, reply to "Ticket Resolved" notifications to reopen cases, or express frustration about lack of response. This cluster also includes internal test tickets and law-enforcement subpoena service emails that arrive through the same support queue. These contacts generally do not represent new technical issues but require proper triage to determine whether an underlying problem still needs attention or the ticket can be closed.

Diagnostics

  • Check the referenced ticket number: Search Salesforce/Freshdesk for the original case ID mentioned by the customer (e.g., #160941, #227935, #182300). Review its full history and current status.
  • Determine if an underlying issue exists: Read the original ticket thread to see if the customer's problem was actually resolved or if it was auto-closed due to inactivity.
  • Identify the ticket type:
    • Is the subject line a reply to a "Ticket Resolved" or "Ticket Closed" automated notification? (Look for subjects like "Re: Ticket Resolved", "Re: Support Ticket Resolved", "Re: Ticket Closed")
    • Is it a subpoena or law-enforcement request? (Look for subjects containing "Subpoena", "Grand Jury Subpoena Service", "Law Enforcement Subpoena Service", "U.S. Federal GJ Subpoena")
    • Is it an internal test ticket? (Look for subjects like "TEST CODE RED SUPPORT TICKET")
    • Is it a customer satisfaction survey reply? (Look for "How would you rate the support you received?")
    • Is it a duplicate or merged ticket? (Check if the case was already merged into another case)
  • Check the customer's account: Look up the customer's email in the admin tool to confirm account status, wallet existence, and whether they are associated with a known program (FTX Retail, Cred Inc., enterprise client).
  • Check for multiple tickets from the same customer: Search by customer email to see if they have filed duplicate tickets that should be merged.

Resolution

Scenario: ticket-resolved-subpoena-tickets#customer-replies-ticket-resolved

Trigger: Customer replies to a "Ticket Resolved" or "Ticket Closed" automated notification stating their issue is not actually resolved.

Signals: Re: Ticket Resolved, Re: Support Ticket Resolved, Re: Ticket Closed, not resolved, still experiencing, issue not fixed, please reopen

Steps:

  1. Open the original ticket referenced in the customer's reply (the ticket number is typically included in the subject line or Freshdesk footer, e.g., #227935).
  2. Review the full conversation history to understand the original issue and what resolution was attempted.
  3. If the original issue is identifiable and still unresolved, reopen the ticket or work within the new case. Request any missing information needed to proceed.
  4. If the original issue is unclear or the customer has not provided enough context, reply asking for clarification: "Could you please help us with the concern? This would help us further extend our assistance."
  5. If the customer does not respond after follow-up, send a status-check email. If still no response, close the ticket with a message offering to reopen if needed.

Notes: Many of these reopened tickets involve 2FA reset requests or account access issues. If the customer's underlying issue is 2FA-related, transition into the standard 2FA reset verification workflow (see scenario below). Some tickets in this cluster originate from legacy Freshdesk URLs (e.g., https://bitgo.freshdesk.com/helpdesk/tickets/227935) — these are valid historical references.

"Greetings from the BitGo support team. Could you please help us with the concern? This would help us further extend our assistance." (ticket #257877)

"We do not use bots or AI. We understand how frustrations can arise when multiple different email addresses are used for different accounts, but confusion exist on which one is used for which account." (ticket #265055)

Scenario: ticket-resolved-subpoena-tickets#2fa-reset-via-reopened-ticket

Trigger: Customer reopens a resolved ticket because they still cannot access their account, typically due to a 2FA issue.

Signals: 2FA, two-factor authentication, account frozen, cannot log in, help reset 2FA, Box C, keycard, email verification date

Steps:

  1. Confirm the customer's underlying issue is 2FA access. Request the following verification information:
    • Date of BitGo email verification (instruct customer to search for "Your BitGo Email Verification" in their inbox).
    • 3 transaction hashes either to or from their wallet. If they do not have transaction hashes, they must contact the exchange where they first received bitcoin and request the TXIDs.
    • Wallet balance in cryptocurrency (with the name of the wallet).
  2. If the customer cannot provide the above, they may alternatively provide the first 8 characters and the last 8 characters of the BitGo Public Key found on their wallet keycard ("Box C"), along with the name of the wallet.
  3. Verify the provided information against internal records using the admin tool (check account signup date, wallet balances, OTP device details).
  4. Once verified, initiate the manual 2FA reset.
  5. Confirm to the customer that the 2FA has been reset.

Notes: Customers sometimes provide transaction amounts instead of transaction hashes — follow up to clarify. If the customer has no wallets on the account (e.g., Total personal wallet count: 0), note this in the ticket. For Cred Inc. users, refer them to the Cred Settlement FAQ and Cred FAQs (Stretto) if applicable.

"If you do not have the above information, we can also accept the First 8 characters and the Last 8 Characters of the Bitgo Public Key(BOX C) from your keycard. Please provide the name of the wallet the keycard info applies to." (ticket #265055)

"We need the following information before we can proceed on your request. Date of BitGo email verification (search for 'Your BitGo Email Verification' in inbox) ... Alternatively, you may provide us the first and the last 8 characters of your BitGo Public Key found on your wallet keycard (Box C)" (ticket #315863)

Scenario: ticket-resolved-subpoena-tickets#no-response-or-unclear-request

Trigger: Customer submits a vague ticket, a status inquiry with no actionable detail, or does not respond to agent follow-up questions.

Signals: unanswered, no response, unclear request, status of ticket, haven't heard, no acknowledgment, new ticket with empty body

Steps:

  1. Reply to the customer requesting additional information or clarification about their issue.
  2. If no response is received within a reasonable period, send a follow-up: "We are following up on our last email to check for a status update."
  3. If still no response after a second follow-up, close the ticket with the standard closure message: "It has been a few days since we last heard from you. Since our recent follow up did not receive a reply, we will move forward with closing this ticket for now, but are happy to re-open and continue working with you on the issue if needed. Please don't hesitate to reach out if you need further assistance. A reply to this email will reopen the existing case and notify our team."

Notes: Some customers submit tickets with empty bodies or minimal text (e.g., "New ticket", "entrance"). Always attempt at least one clarification request before closing.

"Thank you for the email. I am not sure I fully understand this request. Can you provide additional information in the body of a reply to us?" (ticket #240738)

"We are following up on our last email to check for a status update. It has been a few days since we last heard from you. Since our recent follow up did not receive a reply, we will move forward with closing this ticket for now, but are happy to re-open and continue working with you on the issue if needed." (ticket #196989)

Scenario: ticket-resolved-subpoena-tickets#ftx-retail-legacy-tickets

Trigger: Ticket originates from an FTX Retail customer or is identified as part of the FTX Retail backlog.

Signals: FTX, FTX Retail, FTX Creditors, FTX FAQ, Cred, Cred Inc., Cred Settlement

Steps:

  1. Confirm with the appropriate internal contact (historically Michelle Liu) whether FTX Retail issues in this batch have been resolved.
  2. If confirmed resolved, close the ticket with a note: "Closing FTX Retail tickets after confirming — these issues are already resolved."
  3. For FTX Creditors who still need help, direct them to the FTX FAQ. For Cred Inc. users, direct them to the Cred Settlement FAQ and Cred FAQs (Stretto).

Notes: A large batch of FTX Retail tickets was bulk-closed after confirmation. If a customer re-contacts about an FTX-related issue that was part of this batch, verify individually before closing again.

"Nandish Closing FTX Retail tickets after confirming with Michelle Liu - these issues are already resolved" (ticket #181472)

"For FTX Creditors – while you wait, please visit our FTX FAQ. ... For Cred Inc. Users – please refer to our Cred Settlement FAQ. ... You can also review important settlement information here: Cred FAQs (Stretto)." (ticket #265055)

Scenario: ticket-resolved-subpoena-tickets#subpoena-law-enforcement

Trigger: Ticket subject contains "Subpoena", "Grand Jury Subpoena Service", "Law Enforcement Subpoena Service", or "U.S. Federal GJ Subpoena".

Signals: subpoena, grand jury, law enforcement, U.S. Federal GJ Subpoena

Steps:

  1. Do not attempt to handle the subpoena or law-enforcement request directly.
  2. Escalate immediately to the BitGo Legal / Compliance team.
  3. Do not disclose any customer information or acknowledge the existence of specific accounts in your reply to the requester.
  4. Document the escalation in the ticket notes.

Notes: Multiple subpoena tickets appear in the historical data (e.g., "Subpoena Service", "Law Enforcement Subpoena Service", "Grand Jury Subpoena Service", "U.S. Federal GJ Subpoena"). These are always handled by Legal/Compliance, never by frontline support.

Scenario: ticket-resolved-subpoena-tickets#internal-test-tickets

Trigger: Ticket is clearly an internal test (e.g., submitted by a BitGo employee with a test subject line).

Signals: TEST, CODE RED, test ticket, internal test, gregorystone@bitgo.com

Steps:

  1. Verify the ticket was submitted by an internal BitGo employee (check the sender's email domain is @bitgo.com).
  2. If it is a confirmed internal test, respond according to the test scenario as appropriate and then resolve/close the ticket.
  3. No customer follow-up is needed.

Notes: Internal test tickets are used to validate support queue routing, engineering incident response workflows, or Freshdesk configuration. They should not be confused with real customer issues.

"Thank you for the bring this to our attention. Our engineering team is aware of the issue and working diligently to resolve. We will follow up as soon as possible." (ticket #282279)

Scenario: ticket-resolved-subpoena-tickets#enterprise-wallet-policy-unlock

Trigger: Enterprise customer requests a temporary wallet policy unlock for whitelisting or transaction purposes, and the ticket is later reopened or requires follow-up.

Signals: wallet policy, unlock, whitelist, advancedWhitelist, policy unlock, taproot address, whitelisting error, policy rule in place

Steps:

  1. Confirm the customer's identity and authorization (must be an admin on the enterprise/wallet).
  2. Unlock the wallet policy for the requested duration (e.g., 7 hours) as agreed during a call or verified request.
  3. If the customer encounters a whitelisting error after the policy is unlocked, verify:
    • That the policies were properly unlocked (re-check policy state).
    • Whether the customer is attempting to whitelist an internal wallet address — if so, advise them to use the wallet ID instead of the address.
    • Whether the address type (e.g., taproot) is compatible with the current whitelist configuration. If not, escalate to engineering via JIRA.
  4. If the issue requires engineering investigation (e.g., taproot address cannot be added to an advancedWhitelist alongside an existing address), create a JIRA ticket.
  5. Follow up with the customer after engineering resolves the issue. If no response is received, send standard follow-up and close after the waiting period.

Notes: In one documented case, a customer could not whitelist a taproot address on a wallet that already had a non-taproot address whitelisted. The agent noted "needs to become a jira" — indicating this may be a platform limitation requiring engineering work.

"Apologies, looks like the policies might have not been unlocked properly. could you please try to add the whitelist address once again? Also we see you are trying to whitelist your internal wallet address. Instead of address could you please try with your 'In Trust btc cashin' wallet ID." (ticket #196989)

Scenario: ticket-resolved-subpoena-tickets#webhook-configuration-issue

Trigger: Customer reports that webhooks (e.g., for ETH, ETC, or POLYGON wallets) are not returning expected address confirmation notifications.

Signals: webhook, address_confirmation, transfer, ETH, ETC, POLYGON, "type": "transfer", address webhooks, notifications

Steps:

  1. Look up the customer's wallet and inspect the configured webhooks. Check the type field — common types are transfer and address_confirmation.
  2. If the customer expects address creation/confirmation notifications but their webhook type is "type": "transfer", advise them that they need to create a wallet webhook with type address_confirmation per the documentation: https://developers.bitgo.com/docs/webhooks-wallet
  3. Review the webhook notification history for the wallet. Confirm whether notifications are being sent (check lastAttempt, failingSince, successiveFailedAttempts).
  4. If the webhook appears correctly configured but is not delivering expected data (e.g., missing label return in notifications), escalate to the engineering team with the affected wallet IDs and coin types.
  5. Follow up with the customer once engineering provides findings.

Notes: In one case, the customer's ETH, ETC, and POLYGON wallets all had "type": "transfer" webhooks but expected address_confirmation behavior. No evidence of address_confirmation type was found in the webhook configurations or notification logs. The agent was unable to find evidence of label return in notifications and escalated to engineering.

"webhook type on this wallet is transfer and not address_confirmation" (ticket #343254)

"reached out directly to Margie for some thought partnership on this - unable to find evidence of label return in notifications - unable to find address confirmation or mention in notifications" (ticket #343254)

Related