Why slow pauses turn into cancellations
A pause request handled slowly often turns into a cancellation. If your subscription platform has no API Yuma can call, or runs on a custom setup, that pause has been a manual job, and the subscriber waits while it sits in the queue.
How Yuma pauses it in the interface
With Web Actions, Yuma does it in the interface, exactly as your team would: find the subscriber, pause with the right reason code and add a retention note. You record the pause once, Yuma learns the steps, and your subscription playbook calls the action when a request comes in.
If your platform has a supported integration, Yuma uses that instead. See how it handles skips, swaps, pauses and cancellations through an integration.
A few weeks away, not a cancellation
A coffee subscriber is travelling for a few weeks and asks to stop deliveries. As the playbook says, Yuma offers a pause instead of a cancellation. The customer accepts, and Yuma pauses the subscription in the brand's custom portal with the reason travel and a note for the retention team.
Benefits
01Speed
Paused while they wait
Pauses happen fast, before frustration turns into a cancellation.
02Retention
Saves the subscriber
When your playbook offers a pause first, customers who only need a break stay subscribed.
03Accuracy
Reason codes, every time
Every pause carries the right reason code, and cases your playbook doesn't cover go to your team.
04Coverage
Any subscription tool
Works on custom and legacy systems, with every run logged step by step with screenshots.
Step by step
- 01
Record a pause
Pause a subscription once in your tool while recording, or upload a written procedure. - 02
Link it to a playbook
Connect the action to your pause playbook, including when to offer a pause first. - 03
Test with a dry run
Yuma walks every step and stops before saving, so no subscription changes. - 04
Publish
The action goes live once the test run passes. - 05
Run and audit
Yuma pauses subscriptions as requests arrive, and you check each run from the ticket.
