Playbook, SaaS company
The card expired, and the notice went to somebody who has left
A failed payment on a team product does not inconvenience one person, it degrades a workspace that forty people are working in. The message usually arrives from somebody who never saw the card, does not know whose it was, and has just been told they can no longer save anything. What they need is the date the next thing happens, and that is publishable.
Why this is not the general answer
The handling pattern for failed payments holds across every trade. What follows is the part that does not.
- The consequence is shared: one declined card puts a whole workspace into a restricted state, so the person asking is often a colleague of whoever owns the payment method rather than the payer.
- Dunning notices go to the billing contact set when the account was opened, which on a subscription two years old is frequently a mailbox that was closed when somebody changed jobs, so the first anybody hears of it is a banner inside the product.
- An annual renewal declines differently from a monthly charge, because the amount is large enough to trip the card issuer's own checks and the approval sits with a finance team who have never opened the product.
- Every stage of the retry window is a fixed rule with a date attached, so being exact about when access changes is worth more here than any amount of sympathy.
How it arrives
- our card failed and the workspace is read only
- how long before you suspend us after a failed payment
- the annual renewal was declined can you retry it
- who gets the billing emails on our account
- we changed the card but it is still failing
- can you give us a few days to sort out payment
What has to be indexed for this to work
| The dunning schedule, written as dates rather than as a promise | How many attempts, spaced how far apart, what notification goes out at each, the day the workspace is restricted and the day it stops being reachable. This is a sequence of fixed rules and almost nobody publishes it, which is why the same message arrives every month. |
|---|---|
| What a restricted workspace can still do | Whether members can read, whether exports still run, whether scheduled jobs stop, and what other people see while it lasts. The anxiety underneath the question is whether work in progress is about to become unreachable, and a list of what still functions answers it directly. |
| Who is allowed to change the payment method, and on which screen | The role required and the exact path. On most team products only a billing administrator can do it, and the reason the payment is failing is often that the billing administrator is the person who left, so name the route for transferring that role too. |
| How a restricted workspace is restored | Whether a successful payment lifts the restriction immediately or on the next cycle, whether the missed period is charged for, and whether anything is lost on the way through. Publish it, because the alternative is a customer who pays and then writes again an hour later. |
The reply
When a payment fails we retry on the schedule set out in the billing terms, and the workspace moves to read only at the point described there rather than immediately [1]. Exports keep working while it is in that state. The payment method is changed under billing settings by a member with the billing administrator role, and if that person has left the account, the same page covers moving the role to somebody else [2]. I cannot see your payment, retry it or extend anything, so leave your name, the email the account is under and the workspace name and the team will pick it up.
It leads with the timetable, because the real question is how long there is before something worse happens. Naming the role and the screen resolves a good share of these outright, and the sentence about the administrator having left is there because that is the actual situation more often than the wording admits. The refusal names three specific things it cannot do rather than gesturing at a general limit.
Where it stops
The trigger. The visitor asks for a payment to be retried, a suspension date to be moved, access restored, or says the card has already been updated and it is still failing.
Retrying a payment and lifting a restriction both need somebody who can open the account, and I can do neither. Leave your name, the email the subscription is under, the workspace name and roughly when the charge was attempted, and it goes to the team with all of that attached.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never say a payment has succeeded, been retried or that access has been restored, because nothing in this conversation touches billing.
- Never grant an extension, a grace period or a hold on a suspension date, since only somebody on the team can agree to that.
- Never explain why a particular card was declined, because that reason sits with the card issuer and is not visible on your side at all.
- Never say data is safe, or gone, at a date the published schedule does not state.
Questions
- Can it tell somebody whether the retry has already happened?
- No. It holds no view of payment state and should not reason its way towards one. It can lay out the retry schedule and the restriction date, which is what most people are actually counting, then take the details so somebody can look at the real attempts.
- Is publishing the dunning timetable risky?
- It is the opposite. A customer who knows there are further attempts stops panicking, and a customer who knows the restriction date acts before it. What you should not publish is a timetable more generous than the one you enforce, because it will be quoted back at you on the day it matters.
- Most of these people are not the payer. Does that change the wording?
- It changes what the message has to collect. The person typing often cannot tell you the card, so ask for the workspace name and the account email instead, and say plainly that the payment method is changed by a specific role, otherwise they spend the afternoon looking for a screen they cannot reach.
Keep reading
- Everything for a SaaS companyOne widget serves prospects, trialists and paying customers. What it can answer about plans and limits, and what has to reach a person.
- Handling failed payments in generalThe reason usually sits with the card issuer and is invisible to you. The useless reply, the useful one, and why card details never belong in a chat.
- Reset my password is often the wrong question on a team accountIf sign in is federated there is no password to reset. What the assistant can explain, and why it can never send a link itself.
- Nobody still at the company can administer the accountOrphaned admin rights, expired invites and the wrong workspace. Access questions on a team product, and where the assistant has to stop.
- Three different people send this message and only one of them owns the dataDeactivating a member is not deleting them. Backups, subprocessors and who is asking decide the answer, and none of it happens in chat.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.