Change a plan, manage renewal or cancel

Open the existing subscription#

Before opening the portal, record the current plan, subscription status, billing interval and renewal date. This gives you a baseline if the hosted page offers several changes or a scheduled transition. Read the complete confirmation screen, including any immediate payment, future price and effective date. Do not rely on the label of an earlier button to infer the final choice. If the required change is not exposed for your billing account, use support with the workspace and intended change. Creating a new public checkout can create an unrelated account or transaction and is not the supported substitute for a subscription change.

Review the capabilities you depend on#

Make a concrete impact list for the downgrade rather than checking price alone. Identify Scale write Actions, custom identity, avatar or removed branding; Business or Scale team access; any second website; and retention settings above the destination plan's maximum. Decide how customers will continue if a capability becomes unavailable. A normal support-contact fallback should be present in Knowledge. Review endpoints and pending operations before the effective change: an old card displayed in a customer's browser does not grant future execution permission after entitlement changes. Use the actual portal timing to schedule this work; there is no universal proration rule to assume.

Follow the current billing period#

With yearly billing, distinguish the annual payment renewal from the next monthly conversation allowance boundary. A monthly pool refreshing does not mean another annual invoice was issued; an annual invoice paid does not mean all future monthly capacity is available at once. Check the current plan and dates in the account after the provider processes the change. Retried or delayed events are reconciled against their subscription rather than being treated as a new free allowance each time. If the visible state differs from the confirmation, keep both references and ask support to reconcile the specific change instead of confirming it again.

Handle a failed subscription payment#

A failed recurring invoice can move access to a limited past-due grace path: three days with a thirty-unit rescue allowance. It is distinct from a top-up payment and depends on the current subscription state.

The grace path is intentionally limited. It gives the business a short opportunity to repair payment without treating failed renewal as unlimited continuing service. Updating the method or completing authentication must happen in the legitimate payment flow; a support screenshot does not settle the invoice. Existing usage and any rescue capacity are reconciled when the corresponding paid invoice recovers the period, rather than providing a reason to deliberately use unpaid support as a bonus pool. If a long delay crosses into another billing period, provide the invoice reference and dates. Do not assume an old payment event automatically replaces the current term.

Prepare for termination#

A scheduled end-of-period cancellation means the subscription is due to stop at its confirmed effective date; it is different from immediate recorded termination. Check the portal confirmation and the account's cancellation message before planning a shutdown. Preserve necessary operational records through your authorised process before their own retention deadlines. An existing transcript can expire before workspace deletion is scheduled, so the twelve-day cleanup timetable is not an extra guarantee of readable history. If you need to withdraw a mistaken cancellation, contact support promptly and review the legitimate billing option. Expired transcripts cannot be restored merely because payment resumes.

Keep related decisions separate#

Use a short ownership checklist. Billing controls the subscription and purchase authorisation. Websites controls domain installations and site-specific Knowledge. Actions controls connected operations. Privacy controls the selected transcript period. An update in one area can affect the customer experience but does not silently perform all the other administrative tasks. For example, removing a retired shop from Websites revokes its credentials but is not a request to stop payment for the workspace's remaining shop. Turning automatic top-ups Off can stop future new purchases while the plan still renews. Confirm the exact intended state in each relevant area.

Prepare an operational downgrade before its effective date#

List the actual operations that will no longer be eligible under the destination plan, then decide their replacement experience. Moving from Scale to Business can leave public answering and eligible reads while confirmed writes become unavailable. Moving to Core changes more than pool size, including connected operations, multi-site needs and team workflows. Check each affected website and business process rather than relying on a general message that the plan was changed. A fallback should explain the supported contact route without claiming an automated request completed.

Review outstanding external work separately. A delivery-address change already sent to a provider does not vanish because the workspace plan changes. If its outcome is unknown, reconcile that operation before attempting another. Pausing a definition can stop future use but is not an external rollback. Keep the hosted confirmation's effective date in the change record, tell the support team which promises need updating, and perform the relevant safe tests after the transition. If the public copy still advertises an unavailable write, correct that promise too. Commercial eligibility, provider state and website messaging should describe the same operational scope.

Plan closure around several deadlines#

A closure has more than one clock. The billing confirmation sets when the subscription is scheduled to end. Recorded termination can schedule workspace cleanup after twelve days. Individual transcripts can expire sooner under their existing retention dates, while an external support case or delivered email has its own business-controlled lifecycle. Write those milestones in a dated shutdown plan and assign a person to each required follow-up. Do not tell staff that all conversation history is guaranteed until the workspace cleanup date.

Before the confirmed end, remove promises that depend on continuing automated support and prepare the ordinary business contact path. Retire the public publishing snippets when the installation should stop appearing, and account for page/CDN caches. Preserve only the operational records your business is authorised to keep in its proper case system. Cancellation is not a request to erase every independent accounting obligation or external email. After termination, verify the intended service state and record the appropriate contact for any data question. The shutdown should be a deliberate business transition rather than a visitor discovering that a stale launcher can no longer admit questions.

Check a recovered subscription without assuming data recovery#

If a subscription is restored through the supported verified-payment process, first establish its effective plan, access and current usage period. A valid restoration can clear an obsolete workspace-termination schedule; it does not reconstruct transcripts or payloads already purged through normal retention. Distinguish recovering service access from recovering historic content. Report the prior termination reference and new payment reference if support needs to verify that the old scheduled cleanup no longer applies. A browser success redirect cannot perform that reconciliation.

Then review what should return to public operation. Confirm the website remains connected, the current installation credential is published, Knowledge is usable and any required Action still has its permitted configuration and test. Retired templates or intentionally removed websites do not automatically become correct merely because billing is active again. Check the top-up preference and reusable payment method separately from the restored subscription. Finally, test one controlled supported question and any essential connected operation. Record what was recovered, what needs fresh setup and which old records remain unavailable, so staff do not make unsupported promises about the history.

Example: retire one site or close the workspace#

Suppose a business retires one of two storefronts but keeps its main site. It should remove the retired site's publishing path and website record, review shared Knowledge, then separately decide whether the remaining site still needs the same plan. If it schedules a downgrade, staff should check Actions, website capacity and history settings before that date. If it instead cancels the whole workspace, record the effective termination and prepare any necessary business follow-up. The same physical action of removing a script can appear in both examples, but the commercial and data-lifecycle consequences are different and must be deliberately chosen.

Verify the outcome and keep safe evidence#

After the effective change, refresh Billing and confirm the new plan, status, renewal information and top-up preference. Check the active usage period separately. Review at least one affected feature: a read versus write Action, retained conversation view or public widget identity. Record what is unavailable and the intended fallback. If a payment requires attention, resolve its existing invoice rather than restarting checkout. If the account was terminated and later restored through verified payment, confirm that the old deletion schedule no longer applies with support where needed. That restoration does not recreate content already removed by its normal retention process.