Scoutinternal

Enterprise Account Closure, Freezing, and Payment Plan Downgrade (Churn Processing)

Enterprise Account Closure, Freezing, and Payment Plan Downgrade (Churn Processing)

Problem

When a BitGo enterprise customer account is closed or frozen — whether due to voluntary termination, non-payment, or non-compliance — internal teams (Sales, AR, Customer Success) send a standardized "Status change" email to support@bitgo.com requesting that the enterprise's payment plan be changed to "basic" in bgadmin and, for non-payment cases, that the enterprise and all related enterprise IDs be frozen immediately. These requests arrive as automated or semi-automated notifications triggered by Salesforce opportunity status changes and must be actioned promptly by the support team.

Diagnostics

  • Identify the request type: Determine whether the status change is to Closed (requires payment plan change to "basic" and possible freeze) or Frozen (requires freeze only, with potential plan change later).
  • Check for Enterprise ID: Confirm the requesting email includes a valid Enterprise ID. Some automated emails arrive with the Enterprise ID field blank. If missing, reply to the requester asking them to provide it. Do not guess.
  • Look up the enterprise in bgadmin: Open bgadmin and search by the provided Enterprise ID. Verify the enterprise name matches the request.
  • Check current Payment Plan: Note the current payment plan value (e.g., bento-in-salesforce, a custom plan name like nexo, bitay, hardyaka, etc.). This will change to basic.
  • Check current Freeze status: Determine whether the enterprise is already frozen. If a Freeze field shows "Active till …", the account is already frozen — no need to re-freeze.
  • Identify Churn Reason: The churn reason dictates whether freezing is required:
    • Non-Payment or Non-Compliant: Freeze immediately in addition to changing the plan to "basic".
    • Voluntary Termination: Change plan to "basic". Freezing is generally not required unless explicitly requested.
  • Check for related Enterprise IDs: The request says "all related enterprise ID's." Check bgadmin or ask the requester whether there are additional enterprise IDs associated with the same account (e.g., separate enterprises for hardware, trust, or wrapped-asset services). All related IDs should receive the same treatment.
  • Confirm the Salesforce link: The request typically includes a Salesforce link in the format https://bitgo.lightning.force.com/lightning/r/Opportunity/<ID>/view. This can be used to cross-reference the account status if needed.
  • End-user contact about non-payment freeze: If a customer (rather than an internal team member) contacts support because their account is frozen due to non-payment, do not unfreeze the account directly. Direct the customer to ar@bitgo.com to resolve the billing issue with the Accounts Receivable team.

Resolution

Scenario: closed-ids-enterprise-related#voluntary-termination-closed

Trigger: The "Status change" email specifies Churn Reason as "Voluntary Termination" and the account status is "Closed."

Signals: Closed, Voluntary Termination, payment plan, basic, bgadmin, churn, enterprise

Steps:

  1. Open bgadmin and locate the enterprise using the provided Enterprise ID.
  2. Verify the enterprise name matches the account name in the request.
  3. Change the payment plan to "basic".
  4. Check if related enterprise IDs are mentioned or discoverable in bgadmin. If so, change each related enterprise's payment plan to "basic" as well.
  5. Do not freeze the enterprise unless explicitly requested. For voluntary terminations, freezing is not required.
  6. Reply to the requester confirming the plan change, including the Enterprise name, ID, and updated Payment Plan value.
  7. Resolve the ticket.

Notes: If the enterprise was already on the "basic" plan, confirm this to the requester and resolve. Some automated Salesforce emails are sent for accounts that were already processed in a prior ticket — check history before actioning.

"Hi Mais, Since this is a voluntary termination, you need not freeze the enterprise. Thanks for checking!" "Hi Wei, Changing pricing plan to basic is good enough."

Scenario: closed-ids-enterprise-related#non-payment-closed

Trigger: The "Status change" email specifies Churn Reason as "Non-Payment" (or "Non-Compliant") and the account status is "Closed."

Signals: Closed, Non-Payment, Non-Compliant, freeze, frozen, basic, bgadmin, enterprise, nonpayment

Steps:

  1. Open bgadmin and locate the enterprise using the provided Enterprise ID.
  2. Change the payment plan to "basic".
  3. Check the current freeze status. If the enterprise is not already frozen, freeze it immediately.
  4. Identify all related enterprise IDs (e.g., separate hardware or trust enterprises for the same client). Change each related enterprise's plan to "basic" and freeze them as well.
  5. Reply to the requester confirming: Enterprise name, ID, updated Payment Plan ("basic"), and Freeze status (including the "Active till" timestamp).
  6. Resolve the ticket.

Notes: - If the enterprise is already frozen from a prior request, note this in your reply (e.g., "already frozen since [date]") and only update the payment plan. The freeze timestamp is typically set far in the future (e.g., year 2063 or 2125).

  • If a customer contacts support directly because their account is frozen due to non-payment, do not unfreeze the account. Direct them to ar@bitgo.com to resolve the billing issue with the Accounts Receivable team.

"Hi Sreeja, Upon checking, this enterprise have already been frozen 2 months ago as per request in this ticket - https://bitgo.freshdesk.com/a/tickets/228242 The pricing plan has just been changed to basic" "We would like to inform you that your request regarding the payment plan update has been successfully completed. The account has been updated to the 'basic' payment plan, and the enterprise is frozen."

Scenario: closed-ids-enterprise-related#freeze-only

Trigger: The "Status change" email specifies the account status as "Frozen" (not yet "Closed"), requesting only a freeze via bgadmin.

Signals: Frozen, freeze, bgadmin, Non-Payment, enterprise, account frozen

Steps:

  1. Open bgadmin and locate the enterprise using the provided Enterprise ID.
  2. Check the current freeze status. If not already frozen, freeze the enterprise immediately.
  3. Do not change the payment plan unless the requester explicitly asks for it. The "Frozen" status is an interim step; the CSM will confirm official churn within 30 days.
  4. If the account is a Trust account (BitGo Entity = "BitGo Trust Company Inc"), be aware that the Trust Operations team (trustoperations@bitgo.com) is typically CC'd and may need to coordinate further actions.
  5. Reply to the requester confirming the freeze, including Enterprise name, ID, Payment Plan (unchanged), and Freeze status.
  6. Resolve the ticket.

Notes: Some freeze requests note: "(FYI Trust Team - Please be ready work with the CSM and your respective teams if this is a Trust account. The CSM will confirm the official churn within 30 days following this account being frozen)." No additional action is needed from support beyond the freeze itself.

"The account is frozen as requested: Enterprise: Knooz UAB - Trust ID: 646537a1a707420007e1bfe2273bf376 ... Freeze: Active till 2125-01-19T23:03:13+05:30" "This has been done, Enterprise frozen."

Scenario: closed-ids-enterprise-related#missing-enterprise-id

Trigger: The automated "Status change" email arrives with the Enterprise ID field blank.

Signals: Enterprise ID missing, blank, no Enterprise ID, cannot identify

Steps:

  1. Do not attempt to guess the Enterprise ID from the account name alone.
  2. Reply to the requester requesting the Enterprise ID. Example: "I am not able to positively identify this Enterprise and see there is no Enterprise ID included. Can I please get the Enterprise ID we will be affecting?"
  3. Once the Enterprise ID is provided, proceed with the appropriate scenario above (Voluntary Termination, Non-Payment, or Freeze).
  4. In your resolution reply, remind the requester: "Moving forward, please include the Enterprise ID that needs affecting."

Notes: Some missing-ID emails are from backfilling historical churn in Salesforce. The requester may reply that the account was already processed, in which case resolve the ticket with no further action.

"Moving forward, please include the Enterprise ID that needs affecting." "My apologies for these messages to Support. I've been backfilling some churn opportunities in Salesforce for accounts that have already been closed. I thought I had deactivated these alerts to Support during the upload, but it looks like it still sent. This account has already been closed."

Scenario: closed-ids-enterprise-related#temporary-reinstatement

Trigger: A previously closed/churned enterprise needs temporary reinstatement so the client can withdraw remaining funds.

Signals: reinstate, temporary, 48 hours, accidental deposit, withdraw, revert, high paygo fees

Steps:

  1. Confirm the request comes from an authorized internal team member (AR, CSM, or Sales) with a clear justification (e.g., client received an accidental deposit and needs to withdraw).
  2. In bgadmin, change the payment plan from "basic" to a named plan specified by the requester (or a temporary plan).
  3. Note the agreed-upon reinstatement window (e.g., 48 hours).
  4. Monitor the account. Once the requester or CSM confirms the withdrawal is complete, revert the payment plan to "basic".
  5. Verify wallet balances are zero or negligible before reverting.
  6. Reply confirming the revert is complete.

Notes: This is an exceptional workflow. Always get explicit confirmation from the requesting team before reverting. There is no automated timer in the system to revert plans — the requester or agent must track the deadline manually.

"Galaxy accidentally got a deposit of 123 BTC and they need to withdraw, but due to the high paygo fees, per @Chris Cook's request, kindly help to reinstate this enterprise for 48 hours for them to transfer out the funds. Once the withdrawal is done, we can switch them back to basic." "Reverted back to basic. Their BTC wallet is empty."

Scenario: closed-ids-enterprise-related#hide-duplicate-enterprise

Trigger: An internal team member requests deletion or hiding of a duplicate/unused enterprise so the client no longer sees it in the UI.

Signals: delete enterprise, duplicate, inactive enterprise, remove from UI, hide enterprise

Steps:

  1. Note: It is not possible to delete Enterprises in bgadmin.
  2. As a workaround, change the primary contact on the unused enterprise to a generic address. This allows you to remove the client's user from the enterprise, so it no longer appears in their UI.
  3. Confirm with the requester which enterprise is the duplicate and which user(s) should be removed.
  4. Ask whether the payment plan should also be changed to "basic" (if applicable).
  5. Once confirmed, update the primary contact, remove the user, and reply confirming completion.

Notes: This workaround was confirmed in practice. The enterprise still exists in bgadmin but will no longer be visible to the removed user in the BitGo UI.

"Unfortunately, it is not possible to delete Enterprises." "We can move forward with changing the primary contact to a generic address which should allow us to remove the user and have the Enterprise no longer show."

Scenario: closed-ids-enterprise-related#end-user-claims-funds-at-closed-client

Trigger: An end user of a third-party platform (e.g., a yield service or exchange) contacts BitGo asking to recover funds held by the third party's enterprise account.

Signals: bankruptcy, funds recovery, third-party platform, end user, Haru, partner

Steps:

  1. BitGo cannot disclose information about clients or potential clients due to security and privacy policies.
  2. BitGo cannot assist with recovery of funds from another business's enterprise account, even if those funds belong to the end user.
  3. Inform the end user that the third-party platform maintains its own accounting and customer records. BitGo customers maintain all keys to their wallets and passwords to decrypt those keys.
  4. Advise the end user to wait for the outcome of any litigation or due process, and to contact their local securities regulator (e.g., SEC) or a lawyer for guidance.
  5. Do not provide any account details, wallet information, or transaction history related to the third-party enterprise.

Notes: This scenario applies to any third-party platform bankruptcy or insolvency situation. BitGo's role is custodial infrastructure; it does not have visibility into how the platform's funds map to individual end users.

"Haruinvest is not a part of Bitgo and maintains their own accounting and customer records. Customers on our platform maintain all keys to their wallets and all passwords needed to decrypt these keys. We have no view into their accounting of how much funds you had with them nor where you funds would be located. We are legally unable to assist you with recovery of funds from another business's account even if some of those funds belong to you."

Related

  • ethereum-fees-and-gas-tank — Enterprise-level fee addresses may still need funding even on "basic" plans if residual balances exist
  • admin-approval-policies — Enterprise policies may remain in place after a plan change to "basic"; verify if policy cleanup is needed
  • none identified for enterprise deletion (confirmed not possible)