When a recurring donor asks to change their gift, choose one path

When a donor asks to change a recurring donation amount, start with donor self-service if the requested control exists. Otherwise use the platform's documented staff action. Cancel and restart only when neither route can produce the schedule the donor requested, and confirm that tradeoff before acting.

The important rule is to use one path. A portal update, an admin edit, and a replacement subscription should not all be moving at once.

Capture the request before choosing the tool

Do not begin on the subscription screen. First, turn the donor's email, call, or message into a small change record with five facts:

• the current recurring gift or subscription identifier;
• the requested amount, frequency, payment method, pause, or cancellation;
• the date the donor wants the change to take effect;
• the channel and time of the request; and
• the staff owner responsible for verifying the result.

Keep the donor's words when timing is ambiguous. “Starting next month” may mean the next scheduled charge or the following calendar month. If a donor asks on August 20 to move from $25 to $40 “in September” but the plan charges on the first, confirm whether October 1 is the first changed charge. Resolve the date before changing a live schedule.

This record is not paperwork for its own sake. It gives your team one answer when a donor replies, finance asks why a total changed, or another staff member opens the subscription.

Choose the narrowest supported route

Use this order: donor self-service, supported staff control, then confirmed cancel-and-restart. Choose a route only when it supports the specific field the donor wants to change.

1. Send a direct self-service route

Use donor self-service when the portal exposes the requested action and the donor is willing to use it. Do not send a generic login page with a paragraph of instructions if you can send the exact portal route and one clear action.

The controls vary by platform. Fundraise Up currently documents donor updates to recurring amounts, schedules, and payment methods, along with pause controls (Fundraise Up donor portal). iMIS documents an administrator setting that can allow donors to change recurring amounts, while collection-date controls are handled separately (iMIS recurring adjustments). Check your own configuration instead of assuming a portal can make every change.

Keep the task open until the subscription shows the new future state. A sent portal link proves outreach, not completion.

2. Use a documented staff control

Use a staff edit when the donor has made a clear request and the platform explicitly supports that action for your role. Follow the vendor's current permissions, confirmation, and notification behavior.

BetterWorld, for example, documents permissioned admin controls for amount, frequency, billing date, pause, reactivation, and cancellation, plus automatic emails for changes (BetterWorld admin guide). Salesforce NPSP documents amount changes with an effective date and a resulting change-log entry (Salesforce recurring donations). Those are product-specific behaviors, not a promise about your system.

Before saving, compare the proposed next charge with the donor's request. After saving, record who changed it, when it takes effect, and which automated notice the donor should receive. If your platform has no history or notification, add your own internal note and send a plain confirmation without including payment-method details beyond the identifier already visible in the system.

3. Cancel and restart only with a named reason

Cancel-and-restart is the fallback when the existing subscription cannot accept the requested change through a supported portal or staff control. Tell the donor what will change before you cancel: the next charge date, the new checkout step, and any interruption between the old and new schedules.

Use one reason in the record, such as `amount not editable`, `payment method requires donor entry`, or `frequency change requires new plan`. Do not use “system issue.” The specific reason helps your next platform review and prevents another staff member from trying the same blocked route.

If the donor also asks to buy merchandise, pay an event fee, or make a separate one-time gift, keep that transaction in its own checkout. A recurring-gift change should alter the recurring plan, not become a container for unrelated charges.

Verify the future schedule, not the success message

A green confirmation only proves that the interface accepted an action. Close the request after comparing the before and after state:

1. The intended subscription is still the active record, or the old one is clearly closed.
2. The amount and frequency match the donor's words.
3. The effective date produces the expected next charge date.
4. The payment method is the one the donor intended, using only the identifier your platform normally displays.
5. The change history or internal note identifies the route and owner.
6. The donor received one confirmation with the new amount, frequency, and next date.

For a replacement subscription, also confirm that two active schedules will not charge on the same date. For a cancellation, confirm that no future installment remains scheduled. If any of these facts is unclear, keep the request open and escalate through the platform's support path.

Make this a software capability test

A lean team should not need a custom investigation for every recurring-gift change. During software evaluation, test a donor amount increase, a staff-assisted effective-date change, a payment-method update, a pause, and a cancellation. Inspect both the monthly-giving workflow and the donor-operations area, then verify the exact controls in a real account.

Prefer the setup where your team can route one request, see the future schedule, and show the donor what changed.