Playbook, fintech app
The customer is standing at a checkout, not sitting at a desk
An outage on a money app is not a page that will not load. It is somebody at a till with a queue behind them and a card that has just been refused, and the cause may be an upstream payment network the firm does not operate and cannot see. The assistant reads documents and holds no signal from any system, so it knows less about this than the customer does, and the only useful reply admits that in the first line and then says something practical.
Why this is not the general answer
The handling pattern for service outages holds across every trade. What follows is the part that does not.
- The person asking is mid transaction rather than mid task, so the valuable content is what to do in the next thirty seconds rather than an explanation of what has gone wrong.
- The failure may belong to a payment network the firm neither runs nor monitors, which means even the team may not be able to say whose it is, let alone a widget reading a help page.
- Money can be in flight during an incident, so the reassuring instinct to suggest trying again is the one instruction that turns a single problem into two payments.
- A single declined card looks exactly like a widespread failure from the customer's side, and the assistant cannot tell those apart, so it must not describe anything as isolated or as normal.
How it arrives
- my card just got declined in a shop is something down
- is anyone else having payments fail right now
- the app will not load and i need to pay for something
- are transfers delayed today
- i tried to pay twice and both failed has it taken the money
- where do you post updates when something is wrong
What has to be indexed for this to work
| The status page, handed over rather than summarised | The address and which components appear on it separately, including whether card payments and transfers are listed apart from the app itself. The assistant should send somebody there rather than describe it, because anything it describes was read on a schedule. |
|---|---|
| What a customer can do while payments are failing | The practical alternatives you are willing to publish, and a plain instruction not to repeat a payment that may still be in flight. This is the only part of the answer that helps somebody standing at a checkout. |
| Where updates are posted, and how to subscribe | The channel carrying incident notices and the route to be told without asking. During an incident the same question arrives from everybody at once, and every subscription is a message you do not receive next time. |
| What happens to a payment caught in an incident | Whether an amount can show as taken and then reverse, how long that takes, and what to do if it does not. This is what people are frightened of, and it is entirely publishable in general terms. |
The reply
I have no view of any live system, so I cannot tell you whether payments are affected at the moment. The status page lists card payments and transfers separately from the app itself and shows the current position, and you can subscribe there to be told about the next one [1]. If a payment has failed, it is worth not repeating it straight away, because an amount can show as taken and then reverse, and paying twice is harder to unpick than paying once [2]. If money has left your account and you need somebody to trace it, leave your name, the email on the account, the date and the amount.
The limitation is stated first because every sentence after it would otherwise read as a reassurance the assistant is not entitled to give. The instruction not to retry is the most valuable line in the reply and it is justified rather than asserted. Pointing at the separate components matters because a customer whose card failed does not care whether the app is loading.
Where it stops
The trigger. The visitor asks whether the service is down now, when it will be fixed, or reports that an amount has left an account during a failure.
I cannot see the state of any system or say when something will be resolved. Please check the status page for the current position, and if an amount has left your account, leave your name, the account email, the date and the amount so somebody can trace it.
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 payments are working normally, or that anything is unaffected, since nothing here observes any system.
- Never name the cause of a failure or say which company it belongs to.
- Never tell somebody to try the payment again while an amount may still be in flight.
- Never estimate when something will be resolved, or say that it is nearly fixed.
Questions
- Could we index the status page so it answers this properly?
- You can, and it will still be reading a copy taken minutes ago with a citation making it look authoritative. During an incident that is precisely the wrong shape of answer. Handing somebody the page is faster for them and honest about what the assistant actually knows.
- Will it keep answering while our payments are failing?
- Yes, because it runs on your site and reads documents rather than systems. That is useful as long as it is configured to say clearly that it has no view of the service, which is the wording this cell exists to get right.
- What should the fallback message say during an incident?
- The status page and the fraud number, in that order, both written into the fallback itself rather than composed. The messages arriving during an incident are typed fast and worded badly, and they are the least likely to match anything you have indexed.
Keep reading
- Everything for a fintech appFees, limits and identity checks are safe ground. Balances, transactions and anything reading as a personal recommendation are not.
- Handling service outages in generalThe assistant knows nothing about an incident unless your material says so. A status page it can read is the fix, and reassurance is the trap.
- Onboarding here is a check somebody else runs, not a configurationAccepted documents, what a proof of address must show, and why a rejected photo is most of onboarding on a regulated money app.
- A frozen screen is support, a frozen payment is something else entirelyCrashes, camera steps and reinstalls are answerable. The moment a payment is involved it stops being a troubleshooting question.
- At two in the morning the only useful answer is a telephone numberWhich routes run around the clock and which do not, and why a quiet weekend is settlement rather than an unanswered message.
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.