Building a CSR-Assisted Change-Plan Flow

Overview

Sometimes the customer doesn't want to self-serve — they call, they email, they ask a human to "just move me to the bigger plan." A CSR-assisted change-plan flow lets a customer-service rep run that upgrade, downgrade, or add-on change on the customer's behalf, with the same governed rules a self-service change would follow: the timing and proration your business mandates, and only the discount your policy allows.

This guide builds the CSR side of plan changes and shows how business rules and policy keep a human-run change as safe as an automated one.

The example we'll build

Atlas, a B2B software company, wants its support team to handle plan changes without giving reps free rein on pricing. A customer asks to upgrade to Enterprise; the rep opens the account, runs the change-plan flow, applies an approved 10% loyalty discount (the most policy allows), and the upgrade takes effect immediately with proration — all recorded against the rep, not the customer.

Before you begin

• Business rules that govern change-plan behavior (under Rules & Automation → Business Rules) — at minimum, how upgrades and downgrades are timed and prorated.

• A discount / offer configured in your offers / pricing setup if reps will apply one — so the amount is capped by policy, not typed in freehand.

• Reps with a role and profile that grants the change-plan permission and scopes them to the accounts they're allowed to touch.

1. Create the CSR change-plan journey

1. Go to Content → Journeys and click + New Journey.

2. Set Type to CSR Self-Service — this is the rep-facing variant, so an agent drives the flow on the customer's behalf (the customer-facing version is a Customer Self-Service journey).

3. Build a change flow that loads the customer's existing subscription and lets the rep adjust it:

   Find/confirm account → Choose new plan / add-ons → Review (timing, proration, discount) → Confirm

   These flows amend the live subscription (a true upgrade/downgrade), not create a duplicate order — so an update_order action applies the change to the existing subscription.

2. Let business rules decide timing and proration

The rep shouldn't have to remember "upgrades are immediate, downgrades wait until end of term" — your business rules enforce it:

• A rule's Direction (upgrade vs. downgrade), Change timing (Immediate, End of term, or a Specific offset), and Proration decide when and how the change applies.

• Scope narrows which products, plans, and audiences a rule covers, and Priority breaks ties (first matching rule wins).

• Add-on handling (Dependency behavior, Co-term to base) keeps add-ons aligned with the base term.

So when the rep moves Atlas's customer to Enterprise, the matching upgrade rule applies it immediately with proration — automatically, the same as a self-service upgrade would.

3. Keep discounts within policy

This is the heart of "assisted, not unlimited." A rep can offer a discount, but not invent one:

• The discount the flow can apply resolves from your offers / pricing and policy configuration, so the rep can only extend what's approved — the policy engine is the ceiling.

• Set your maximum CSR discount once, centrally, and every rep-run change honors it. A rep trying to exceed it simply can't.

4. Split who can change versus who can cancel

Changing a plan and cancelling one are different powers, and you can grant them separately:

• The change-plan permission lets a rep upgrade/downgrade/add-on; a separate cancel-plan permission controls who can end a subscription.

• Give your front-line reps change-plan, and reserve cancel for a senior tier — set both on the rep's profile.

5. Branch for downgrades and saves

A rep-run downgrade is a churn signal too — handle it like one:

• On a downgrade, branch to a retention offer (a discount or a better-fit plan) before the downgrade commits — the same branching that powers a self-service retention flow (see the multi-branch retention journey guide).

• On an upgrade, you might branch to suggest a complementary add-on.

6. Keep the change attributable

Because a rep is acting for the customer, attribution matters for audit:

• Changes a rep makes are recorded against the rep, and when a rep works inside a customer's context, the action is attributed to the operator (not silently logged as the customer).

• Review rep activity in the audit log (user menu, bottom-left → Settings → Audit Logs).

Get creative

• Approval ladder. For discounts above the standard cap, branch to a "needs supervisor approval" step rather than blocking the rep outright.

• Guided save scripts. On a downgrade or cancel, surface the retention offers as on-screen prompts so reps say the right thing.

• One flow, two front doors. Build the customer self-service change and the CSR-assisted change as parallel journeys sharing the same rules, so both audiences get identical, governed behavior.

Tips

• Use CSR Self-Service, not Customer Self-Service. The journey type sets the audience — pick the rep-facing variant or you'll expose the flow to the wrong people.

• Let rules and policy do the governing. Don't hard-code timing or discounts into the journey; business rules set timing/proration and the offers engine caps discounts.

• Split change from cancel. Grant the two permissions separately so front-line reps can adjust plans without being able to cancel them.

FAQ

How is this different from the customer self-service change flow?

Only the journey type: CSR Self-Service is rep-driven (the agent acts on the customer's behalf), Customer Self-Service is customer-driven. They can share the same business rules and discount policy, so behavior is identical — just a different front door.

Can a rep give any discount they want?

No. The discount resolves from your central offers / policy configuration, so a rep can only apply an approved amount. The policy engine is the discount ceiling.

Who can cancel versus change?

Those are separate permissions. Grant change-plan to front-line reps and reserve cancel-plan for a senior tier via the rep's profile.