When should this procedure trigger?

Retrieve the current subscription record from Subscription record lookup and confirm the plan name, purchase platform, current status, start date, renewal date, pause status, trial status, and whether auto-renew is enabled. This is the source of truth for what support is actually allowed to change.
Pull the recent billing timeline from Subscription billing timeline so you can verify the latest successful charge, any pending renewal, prior refund activity, and whether a chargeback or payment dispute already exists. Always compare the customer's story to the billing record instead of trusting memory or assumption.
IF
A.
Apply tag no-subscription-found so downstream teams can identify account-mismatch requests quickly.
B.
Move the conversation to Review while you confirm whether the customer meant a different account or workspace.
ELSE
A.
Apply tag subscription-verified to indicate that a modifiable subscription state was confirmed.
B.
Move the request to In Progress so lifecycle options can be evaluated with the verified account context.
Review the governing policy in Subscription change policy to confirm platform-specific rules, pause limits, non-refundable cases, notice periods, and statutory exceptions before making a promise. Support should never promise a refund or immediate stop in billing just because the customer sounds upset.
IF
A.
Apply informational tag policy-only so reporting distinguishes policy-explanation contacts from true change requests.
B.
Move the case to Resolved after answering the question and summarizing the applicable rules.
ELSE
A.
Apply action tag change-requested to indicate the customer expects an actual account change.
IF
A.
Call Subscription lifecycle manager to update the subscription state with the agreed effective date and to persist the allowed resume deadline.
B.
Send confirmation through Pause or resume confirmation template including the effective date, billing impact during the pause, and exactly how the customer can resume service.
C.
Apply lifecycle tag subscription-updated so future contacts show that the subscription state was intentionally adjusted.
ELSE
A.
Attach policy reference from Subscription pause exceptions to explain why the pause or resume cannot be completed in the current state.
B.
Apply blocker tag pause-not-eligible and keep the request in review until the customer chooses an alternative path.
IF
A.
Submit the cancellation through Subscription cancellation service with the correct effective date so access remains available until the confirmed end of term unless the policy says otherwise.
B.
Send the end-of-term confirmation using Cancellation confirmation template and include renewal date, final access date, and reactivation expectations.
C.
Move the case to Resolved once the cancellation reference number is recorded.
ELSE
A.
Apply exception tag cancel-exception when the platform or subscription state prevents support from cancelling directly.
B.
Provide the correct self-serve or platform instructions from Platform cancellation guide so the customer knows the exact channel where cancellation must be completed.
IF
A.
Issue the refund request through Refund decision service with the exact charge identifier and refund reason captured from the conversation.
B.
Send refund expectations using Refund confirmation template including the refunded amount, expected processing window, and what happens to subscription access after the refund.
C.
Write the financial event to Subscription finance audit log so billing, finance, and support reporting remain aligned.
ELSE
A.
Apply refund review tag refund-review when the request falls outside policy or needs manual judgment.
B.
Escalate the financial review context to Billing escalation queue so a human can inspect edge cases such as duplicate charges, partial service outages, or regional consumer-rights exceptions.
Log the final decision, selected path, policy basis, effective dates, and any promised follow-up in Subscription case log so later agents can see exactly what was checked and what action was or was not completed.
Publish the procedure outcome to Subscription lifecycle audit stream with subscription state before and after the interaction, the acting policy, and whether the customer needs further review.
If account ownership, refund eligibility, regulatory exception handling, or platform limitations still require human judgment, run Escalate to inbox and include the requested action, verified subscription state, policy blocker, and any promised customer deadline.
When the subscription outcome is clearly communicated, the correct branch has been completed, all system updates are logged, and no further human review is needed, run End to conclude the procedure with a clean end state.