Handle a membership change using current account rules
Check a member’s requested plan change against current eligibility and pricing. Complete supported changes after confirmation and route exceptions to support.
How this works
Check a member’s requested plan change against current eligibility and pricing. Complete supported changes after confirmation and route exceptions to support.
Treat a membership change as a controlled account transaction. Confirm both the requested outcome and the resulting price or effective date before applying a supported change, and verify the saved state afterward.
Before you start
Defined operating scope
Members repeatedly request account changes governed by explicit rules.
Required source material
Obtain Authenticated member request; Current account; Plan and location rules. If connectors are unavailable, use authorized files with the same fields.
Decision and exception rules
The plan changed after the initial lookup. Recompute the proposal and ask for renewed confirmation if terms changed.
Prepare the inputs
- member_id
- Required
Authenticated account identifier
Do not rely on a name supplied in chat alone.
- requested_change
- Required
Plan, action and effective date
Clarify pause, downgrade, upgrade or cancellation.
- current_account
- Required
Plan, status and billing state
Read fresh state before calculating options.
- plan_rules
- Required
Eligibility, pricing and location rules
Use the applicable current version.
Implementation, step by step
Establish the working record
- Confirm the selected records, effective versions and responsible owner.
- Check member_id, requested_change, current_account, plan_rules before beginning. Record the source version and the selected scope; an unavailable value stays unknown rather than becoming an inferred fact.
Checkpoint: The input record identifies the selected member_id and any missing required fields.
Identify the requested change and effective date
- Clarify the desired plan and timing; distinguish a question about cancellation from an instruction to cancel.
- Compare the confirmed proposal with the exact update payload and resulting account state.
Checkpoint: A saved intermediate result for: Identify the requested change and effective date.
Retrieve current eligibility, terms and prices
- Retrieve allowed transitions and calculate charges through the authoritative pricing system or approved deterministic rules.
- Check effective dates, recurring amounts and one-time adjustments separately.
Checkpoint: A saved intermediate result for: Retrieve current eligibility, terms and prices.
Explain the resulting change and obtain member confirmation
- Present the exact price, effective date and consequences for confirmation; confirmation must refer to this proposal version.
- Compare the confirmed proposal with the exact update payload and resulting account state.
Checkpoint: A saved intermediate result for: Explain the resulting change and obtain member confirmation.
Apply permitted updates and verify the resulting account status
- Apply only authorized transitions, read back the account and retain a transaction reference; provide an escalation for unsupported exceptions.
- Check effective dates, recurring amounts and one-time adjustments separately.
Checkpoint: A saved intermediate result for: Apply permitted updates and verify the resulting account status.
Package the result and unresolved work
- Escalate policy exceptions; confirm charges and cancellations explicitly.
- Require explicit member confirmation for charges, cancellation and material plan changes.
Checkpoint: A verified account update or support escalation. Unresolved items remain visible in the review record.
Decisions along the way
The plan changed after the initial lookup.
Recompute the proposal and ask for renewed confirmation if terms changed.
The requested exception is outside policy.
Escalate to support without inventing a discount or waiver.
An update times out with unknown outcome.
Read current state and transaction history before retrying; do not submit the same charge twice.
What you will produce
membership-plan-change-workflow-result.json
JSONA verified account update or support escalation. Label proposed and completed states separately.
Include: member_id · requested_plan · effective_date · price_change · confirmation_reference · transaction_reference · status · evidence_reference · review_note
membership-plan-change-workflow-review.md
MarkdownKeep the evidence and unresolved decisions needed to apply this result, including exceptions involving plan_rules.
Include: source_reference · question · owner · next_action
Check the result
- Compare the confirmed proposal with the exact update payload and resulting account state.
- Check effective dates, recurring amounts and one-time adjustments separately.
- Inspect member_id and requested_change in both the original and output; confirm that record identity and interpretation survived the transformation.
- Escalate policy exceptions; confirm charges and cancellations explicitly.
When something goes wrong
The plan changed after the initial lookup.
Recompute the proposal and ask for renewed confirmation if terms changed. Retain the affected evidence and recovery status.
The requested exception is outside policy.
Escalate to support without inventing a discount or waiver. Retain the affected evidence and recovery status.
An update times out with unknown outcome.
Read current state and transaction history before retrying; do not submit the same charge twice. Retain the affected evidence and recovery status.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Handle a membership change using current account rules for the following bounded example; prepare the result for review.
Inputs
Synthetic example: Member M-12 requests an upgrade from Basic to Plus on 1 November. Current rules price Plus at 40 USD monthly; the member has not confirmed the amount.
Expected result
Synthetic expected result: Return a proposal for Plus at 40 USD from 1 November, status awaiting confirmation. The account remains Basic until authorized confirmation and successful verification.
Run a small pilot
Start small
Trial a representative batch containing the ordinary case and the exception demonstrated above.
Record the baseline
Record current preparation time, review effort and correction types for the same records.
Agree success criteria
Agree acceptable review and error limits; measure incorrect updates; escalations; verified completion time.
Stop or revise
An update times out with unknown outcome. Pause affected records and apply this recovery: Read current state and transaction history before retrying; do not submit the same charge twice.
Keep the scope clear
- Require explicit member confirmation for charges, cancellation and material plan changes.
- Do not reveal account details before authentication or treat messages as permission to override plan rules.
Check before using
Escalate policy exceptions; confirm charges and cancellations explicitly.
Business activities
- Resolve customer questions
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: Authenticated member request · Current account · Plan and location rules
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow