Validating Saves against your billing system
Brightback calculates Saves as any customer who does not complete a cancel from the Brightback Page within 30 days of first landing on the Brightback Page. But what if a customer cancels another way? What if they land on the Brightback page to cancel, then simply let their renewal date expire, or remove their credit card information? If you're connected to one of our billing integrations, currently supporting Stripe and Recurly, you can validate Brightback saves against that customer's account in your billing system.
Save Validation works by cross-checking your billing system for every Save to identify if a customer still has an active, non-canceled subscription 30 days after their initial deflection. With Save Validation, Brightback only reports on valid saves in Brightback Reports, and show the Validation Status for each Customer that hits your Brightback Page in the Customers Reports.
Save Validation is a three step process:
- Mapping the subscription to an exit session (i.e. when a customer lands on your Brightback Page)
- Deriving the validation status
- Updating the session outcome (Saved, Canceled)
Exit session to subscription mapping
Brightback uses the Billing_ID field provided in the exit session via the Brightback.JS or Salesforce Integration to match up when your customer visits the Cancel Page to the subscription in your billing system.
Deriving validation status
We compare both the status and key dates on the subscription with the exit session to determine if the customer was really saved. The table below details each possible status with the description of what happened in each instance, and the outcome we present.
SAVES | |||
Status | Description | |
Outcome |
Valid Save | The subscription is still active and has not been set to cancel when the save event occurs. | Saved | |
Invalid Save | The subscription was canceled between the session and the save event, meaning that the save was not valid. | Canceled | |
Expired Pre-Brightback | The subscription was expired before the session and therefore they were not a paying customer when the session occurred. | Unknown | |
Canceled Pre-Brightback | The subscription was set to cancel before the session but did not expire until after it and thus was still a paying customer when they visited Brightback. | Canceled | |
Activated Post-Brightback | Subscriptions that are activated after the Brightback Exit Session, either through a winback campaign or some other means. | Unknown | |
No Match | When we cannot match an Exit_Session to a Subscription record. | Unknown |
Cancels | |||
Status | Description | Outcome | |
Valid Cancel | The subscription is still active when the exit session occurs. | Canceled | |
Canceled Pre-Brightback | The subscription was set to cancel before the session but did not expire until after it and thus was still a paying customer when they visited Brightback. | Canceled | |
Expired Pre-Brightback | The subscription was expired before the session and therefore they were not a paying customer when the session occurred. | Unknown | |
No Match | When we cannot match an Exit_Session to a Subscription record. | Canceled |
Updating the session outcome
We use the results of the Status field to determine the true outcome of each Brightback exit session, and update the Brightback database to report invalid saves as Cancels. We also update the expired Pre-Brightback cancels to Unknown and remove the cancel value for these accounts since we can only confirm that they were a past customer.
Validation for Watch List customers
In addition to validating saves, we also check against your billing system for customers on the Watch List. All of the validation status and outcomes that apply to Saves apply to our cross-check for Watch List customers.