Scoutinternal

Internal Test Tickets and Non-Customer Inquiries (Whitelist Settings, CWRF, System Testing)

Internal Test Tickets and Non-Customer Inquiries (Whitelist Settings, CWRF, System Testing)

Problem

A large volume of tickets in the support queue are internal test messages created by BitGo staff to validate ticketing system configurations (e.g., Freshdesk/Salesforce routing, email alias testing), CWRF (Client Withdrawal Request Form) test submissions, or placeholder "white-list setting" entries. These tickets contain no actionable customer issue and should be identified, triaged quickly, and closed without customer-facing outreach. A smaller subset involves genuine customer inquiries about missing whitelisted addresses on their wallets, which must be distinguished from the noise.

Diagnostics

  • Check the ticket subject line. Internal test tickets typically have subjects such as "test", "test ignore", "TEST IGNORE PLEASE", "TESTING TESTING roger over under", "Test by [agent name]", "Sarah Steph Testing", "Test 3 - Freshdsk testing", "Test for FD", "testing new support alias", "test service", or "another test".
  • Check the sender email address. Internal tests are sent from @bitgo.com addresses (e.g., to support@bitgo.com). If both the sender and recipient are BitGo-internal, the ticket is almost certainly a system test.
  • Check for CWRF test references. Subjects containing "CWRF" followed by a code ending in _test (e.g., "CWRF RUNIDRW210322A_test", "CWRF RAVAJST220322A_test", "CWRF RAVADRW220322A_test") are withdrawal-request-form test submissions, not live client requests.
  • Check for "White-List setting" placeholder tickets. Multiple tickets exist with the exact subject "White-List setting" and contain no problem description or diagnostic thread. These are placeholder or configuration entries, not customer issues.
  • Distinguish from genuine whitelist inquiries. A real customer ticket about missing whitelisted addresses will include a description of the problem (e.g., "Where did all my white listings go"), come from an external email address, and may reference specific wallets or enterprises. Ask for the wallet ID to begin investigation.
  • Check for unsolicited vendor outreach. Subjects like "Software QA and Testing Partner - Introduction KiwiQA Services" or "penetration testing" from external vendors are spam/solicitation, not support issues.

Resolution

Scenario: test-testing-ignore-setting#internal-test-ticket

Trigger: The ticket was created by a BitGo staff member to test ticketing system routing, email aliases, or Freshdesk/Salesforce integration, and contains no real customer issue.

Signals: test, testing, ignore, test ignore, TEST IGNORE PLEASE, Freshdsk testing, Test for FD, testing new support alias, another test, test service, test msg, Test - I will handle this

Steps:

  1. Confirm the ticket sender is an internal @bitgo.com address (e.g., sent to support@bitgo.com from a BitGo employee).
  2. Confirm the ticket body contains no actionable customer request — typically empty, contains only filler text ("Hi I need help", "Yippy", "stuff broke"), or is explicitly marked "ignore."
  3. Resolve/close the ticket immediately with no customer-facing reply.
  4. If unsure whether the ticket is genuinely internal, check with the named agent in the subject or thread before closing.

Notes: These tickets recur periodically when the support team validates new email aliases, Freshdesk configurations, or SFDC integrations. They are safe to close without action. Do not send templated responses (e.g., "Thank you for reaching out to BitGo Support") to internal test tickets, as this creates unnecessary noise.

"Yippy" — resolved immediately with no customer action. (ticket #254784)

"Test by Steph — Hi I need help" — sent from stephaniemao@bitgo.com to support@bitgo.com as a system routing test. (ticket #51079)

"test please ignore" (ticket #11126)

Scenario: test-testing-ignore-setting#cwrf-test-submission

Trigger: The ticket subject contains "CWRF" followed by an identifier ending in "_test", indicating a test Client Withdrawal Request Form submission rather than a live withdrawal.

Signals: CWRF, _test, RUNIDRW210322A_test, RAVAJST220322A_test, RAVADRW220322A_test, withdrawal request form test

Steps:

  1. Identify the CWRF reference code in the subject line. If it ends with _test, it is a test submission.
  2. Confirm with the operations or custody team if there is any doubt about whether the CWRF is live.
  3. Resolve/close the ticket with no further action. Do not process any withdrawal.

Notes: Multiple CWRF test tickets may appear as both the original submission and follow-up "RE:" replies (e.g., "RE: CWRF RUNIDRW210322A_test"). Close all related threads.

Scenario: test-testing-ignore-setting#whitelist-placeholder

Trigger: The ticket subject is exactly "White-List setting" and the ticket body is empty or contains no customer description of a problem.

Signals: White-List setting, whitelist, white-list, white list setting

Steps:

  1. Check the ticket body and diagnostic thread for any customer-provided context.
  2. If the body is empty and there is no customer contact information or wallet ID, treat as a placeholder/configuration entry.
  3. Resolve/close the ticket with no customer-facing reply.

Notes: There are multiple tickets with the identical subject "White-List setting" (across different Salesforce case numbers) that appear to be system-generated placeholders. Do not confuse these with genuine customer requests about whitelisting issues.

Scenario: test-testing-ignore-setting#genuine-missing-whitelist

Trigger: A customer (external email address) reports that whitelisted addresses are missing or have disappeared from their wallet.

Signals: white listings, whitelisted addresses missing, where did my whitelists go, whitelist disappeared

Steps:

  1. Ask the customer for the wallet ID where they are not seeing whitelisted addresses.
  2. Verify in the admin tools which enterprise(s) the customer's email is associated with, and how many users are on each enterprise.
  3. Check whether other users on the enterprise may have modified the whitelist or wallet policies.
  4. Ask the customer to confirm they recognize all users added to their enterprise(s): "Can you confirm you have added these additional users and 1) know those users, or 2) you own those other email addresses?"
  5. Reassure the customer that BitGo has no ability to access their account — both password and 2FA are controlled solely by the customer.
  6. If the whitelist was removed by an authorized user, guide the customer to re-add addresses. If unauthorized access is suspected, escalate to the security/compliance team.

Notes: BitGo cannot log in to customer accounts. Both password and 2FA are customer-controlled. If the customer does not respond to follow-up questions, send a follow-up email: "We are following up to check if you are still experiencing this issue or if your issue has been resolved."

"We have no ability to let someone into your account as we have no access to your password nor do we have any access to your 2FA. Both of these are needed for someone to login to your account and both of these items are controlled by yourself." (ticket #270014)

"We show this email address is part of two Enterprises. We also show there a multiple users on both of these enterprises. Can you confirm you have added these additional users and 1) know those users, or 2) you own those other email addresses?" (ticket #270014)

Scenario: test-testing-ignore-setting#vendor-solicitation

Trigger: The ticket is unsolicited outreach from an external vendor offering QA, penetration testing, or other software services.

Signals: Software QA, Testing Partner, penetration testing, KiwiQA, vendor introduction, solicitation

Steps:

  1. Confirm the ticket is vendor marketing or solicitation, not a customer request.
  2. Resolve/close the ticket immediately with no reply.
  3. If the vendor email appears repeatedly, consider adding a spam filter rule.

Notes: These are not customer issues. Do not forward to engineering or other teams unless specifically requested.

Related