Playbook, fintech app
The list is genuine, and joining it is not an application
Waiting lists on financial products are frequently real. A new account type, a card or a market opens when permission for it exists there, and that is a queue with an actual constraint behind it rather than a device for making a launch look busy. That makes this cell unusually straightforward and unusually easy to ruin, because the two things people want are a date and an assurance that they will be accepted, and neither is available.
Why this is not the general answer
The handling pattern for waiting lists holds across every trade. What follows is the part that does not.
- The constraint is often a permission in a particular market rather than a piece of unfinished work, which means the honest answer names a condition the firm does not control and cannot schedule.
- Joining a list is not applying for anything, and the difference matters here more than on any other kind of waiting list, because being let in is followed by checks that some people will not pass.
- Nobody may be told they are likely to be accepted, since eligibility on a regulated product is a decision made against criteria the assistant cannot see and must not describe.
- People join for a product they have read about somewhere and then ask about terms that are not published yet, so a large share of these messages are requests to confirm something that does not exist in fixed form.
How it arrives
- when are you launching in my country
- how do i get on the list for the new account
- i joined the waiting list months ago what is happening
- will i definitely be approved when it opens
- can you tell me my place in the queue
- what will the fees be when it launches
What has to be indexed for this to work
| How to register interest, and what registering is not | The form or the setting, and a plain sentence saying that registering is not an application and decides nothing. The second half is what prevents the message four weeks later asking whether they have been accepted. |
|---|---|
| Which markets and products are open, kept current | A published list of where each product is available now. It changes more often than almost anything else you write, which is why it belongs on your site rather than in an uploaded copy that keeps naming a market you have not opened. |
| The published eligibility conditions, where they exist | Age, residency and anything else that is fixed and publishable. Where the decision is not reducible to published conditions, say that instead of implying a rule, because an invented rule is worse than an honest not everybody. |
| Where launches are announced | The channel that carries the news and how to be told through it. Handing somebody the place the answer will appear is the only substitute available for a date, and it is what stops the same person writing every month. |
The reply
You can register interest on the page for that product, and it is worth being clear that registering is not an application: it records that you want it, and nothing more [1]. I cannot give a launch date for any market, because opening one depends on conditions we do not set, and I would not want to guess. Which markets and products are open today is on the availability page, which is the version to trust over anything written earlier [2]. I also cannot tell you whether you would be accepted, since that is decided against criteria I have no view of.
It separates registering from applying in the first sentence, because everything that goes wrong in this pair comes from that confusion. Refusing the date on the grounds that the condition is external is more credible than a vague soon, and it is also true. The eligibility refusal is stated as a category rather than as an apology, so nobody reads encouragement into it.
Where it stops
The trigger. The visitor asks to be added or moved up a list, asks where they are on one, asks whether they would be accepted, or is deciding something on the strength of an unlaunched product.
I cannot add anybody to a list, see who is on one, or say whether an application would be accepted. Leave your name and an email and the team will tell you where the product stands in your market.
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 give a launch date, a quarter, or the word soon, for a market that is not open.
- Never say somebody has been added to a list, or state a position on one.
- Never say an application is likely to be accepted, or describe the criteria it is judged against.
- Never state fees, limits or terms for a product whose terms are not published yet.
Questions
- Can it tell somebody how long they have been waiting?
- No. It cannot see a registration, a list or an account. It should say so in the same breath as explaining that registering is not an application, because the two refusals together make sense where either one alone sounds evasive.
- People ask what the fees will be when it launches. What then?
- Nothing, until they are published. Terms for a regulated product go through an approval process before anybody sees them, and a figure mentioned in chat beforehand is a communication in your firm's name that has not been through it.
- Is it worth publishing that a market is not open rather than saying nothing?
- Yes, and it is the cheapest page in this set. A clear availability list answers the question, stops the speculation, and prevents somebody spending a fortnight assuming they are about to be able to do something they cannot.
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 waiting lists in generalExpectation setting is the whole job: how the list is ordered, how contact is made, and whether a short notice cancellation can reach them.
- Why an account is restricted is never something a public widget knowsLocks, reviews and frozen cards are the highest anxiety questions on a financial app. Which parts are publishable and which are not.
- The general causes of a decline, without describing this particular oneCut off times, corridor delays and issuer declines are publishable. The specific payment in front of the customer is not.
- Explaining the recovery route without becoming any part of itReset questions look trivial until you notice the asker is unverified. What chat explains, and every step it must never perform.
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.