Waitlist

.md

Collect email addresses before you open, see what each signup got and bought, and decide what people get for signing up early.

Waitlist in your admin sidebar, under Marketing, is everyone who asked to hear when you go live, with the discount code they were given. Signups arrive through the waitlist API from your own marketing site, so the list fills up before the platform is public. Your team can also add somebody by hand.

You need the view_waitlist permission to open the list and export it, and manage_waitlist to add people, correct a signup, mark people as notified, resend a confirmation, take somebody off the list or erase them. Somebody with only the first sees everything, with the fields switched off and a line saying why. What a signup bought also needs view_payments, and the Activity tab view_activity_logs.

The list

The screen opens on the list alone, across its whole width, newest first, and shows nobody in full until you pick a row.

Each row is one email address with the name they gave, the discount code they got with whether it is personal or shared and whether it was used, where they came from (your website or your team), when they joined, when they were last mailed, and where they stand. As the list gets narrower the less important columns leave first.

A signup stands in one of four places:

StatusMeaning
WaitingOn the list, and has not heard from you since the confirmation
NotifiedYou told them about your launch
Signed upThey created an account with this address
UnsubscribedThey asked to be taken off

The line under the name counts every signup, and the waiting, notified and signed up ones. Each count is also a filter: click it to see only those. While the waitlist is closed the line says so.

Search finds a signup by email address, name, discount code, its ID, or the ID of the trader it became. The filter menu sorts the list (newest, oldest, email address or name) and narrows it by status, by whether they got a code, and by where they came from. Search, filters, sort and page live in the address, so a link shows the same list.

The menu beside the search holds the list as a whole:

  • Export as CSV downloads exactly the list on screen, filters included, so a search on one campaign exports only that campaign. Every export is written to the activity log.
  • Mark waiting as notified is for after your launch mail went out from your own mail tool: everybody in the list who is still waiting is marked as notified at once. It asks first and mails nobody.
  • Waitlist settings opens the settings.

J and K move through the list and Enter opens the lit signup. Right click a row to open it, resend the confirmation, copy the address, code, ID or link, take the person off the list or erase them.

A signup

A signup opens beside the list, which folds into a column, and has its own address, so a link from a coupon or the command palette opens on it. The cross or Escape folds the list back to the same filters and page.

The head shows their initials, the name or the address, where the signup stands, and under a name the address (click to copy). A line under it names the trader they became and when they were notified or left. When the confirmation cannot be sent, because it is switched off in the settings or its email template is switched off, the head says so and Send the confirmation again is switched off with it. The more menu opens the trader and the coupon, copies, takes the person off the list and erases them. A row of facts shows when they joined, their code, when they were last mailed and where they came from.

Overview

  • Details: the email address, the name and whether they were told about your launch, saved with the save dock at the bottom. Correct a typo here and the next mail goes to the right address. Only what you changed is sent. Once somebody became a trader or left, the address and the status stay as a record, and only the name can still be corrected.
  • Discount code: the code with a copy button, whether it is their own or the shared one, the discount, where the coupon stands, how often it was used and when it expires. It opens the coupon. When the coupon was deleted the code shows struck through.
  • Bought with the code: the purchases the code was used on, with the challenge, what was paid and what the code took off, each opening its payment. For a shared code only this person's own purchases show. A signup without a code has no such block.
  • Where they came from: your website or your team, the API key that sent the signup (opening the key), and anything your website sent along with it. Somebody your team added brings nothing more than the fact in the head, so the block is left out for them.
  • Timeline: when they joined, were last mailed, were notified, became a trader or left.

Activity

Every change your team saved to the signup, each shown as the old and the new value, with a link to the same lines in the activity log.

Adding somebody by hand

Add signup opens an empty signup in the inspector, and the save dock adds it. Use it for somebody who asked you in person, at an event or by mail. They get the same code a signup from your website gets, and the confirmation email unless you switch it off for this one person. Adding works while the waitlist is closed to your website. The column beside the form says exactly what they will get, and warns when the shared code does not work right now.

An address can be on your waitlist once. Adding it again, or correcting a signup to an address that is already there, is refused.

Taking somebody off, and erasing

Take off the waitlist marks the signup unsubscribed. They stop getting waitlist email and an unused personal code stops working. The row stays on purpose: deleting it would let the same address sign up again for a second code, and would lose the fact that they asked not to be contacted.

Erase for good is for somebody who asks to be forgotten. The address, the name and a personal code nobody used are deleted. The activity log entries about the signup lose the address, the name and what your website sent along, and name the signup by its ID from then on. A code that was used stays as the record of the purchase. It asks first and cannot be undone.

Settings

Waitlist settings decides what happens the moment somebody leaves their email address. It is its own entry in the sidebar, and the list links to it as well. You need view_waitlist_settings to open it and manage_waitlist_settings to change it, and the save dock saves whatever you changed in one go.

Collecting signups

While this is off, the API refuses new signups with waitlist_disabled. Everyone already on the list stays on it, and your team can still add people by hand. This is the switch to flip once you have launched and the waitlist has served its purpose.

Confirmation email

Sent immediately after a signup. Switch it off and people are added silently, which only makes sense if you are collecting addresses for something you will send yourself later.

The wording lives under Email templates, as two separate templates: one for when there is a code and one for when there is not. The settings show the subject of the one that applies to your setup and link straight to it.

Discount code

Three choices:

No code. Only the confirmation.

One shared code. Pick one of your coupons that anybody may use. Everybody gets that same code, and you keep managing its discount, usage limit and expiry under Coupons like any other. A coupon made for one trader cannot be picked. Good when you want a simple, quotable "use LAUNCH10".

A personal code. Every signup gets their own coupon, minted the second they sign up. You set the discount (a percentage up to 100, or an amount in your currency), how many days it stays valid, and an optional prefix so the codes read as LAUNCH-K4M9XR2P. Each one works once, and it locks to the person who signed up as soon as they create an account with the same email address. Good when you do not want the code passed around.

The column beside the settings shows what a new signup gets in money: the cheapest and the dearest challenge you sell with the price struck through and the price they pay, the minimum purchase, whether the code covers only some challenges, and until when a code made today works. Under it, your waitlist in figures: everyone on it, those still waiting (the same count as the list), the last thirty days, those who became traders, the last signup and how many API keys can add signups. Before you save it warns about:

  • no API key that can add signups, so your website cannot reach the list
  • a confirmation whose email template is switched off
  • a code with the confirmation email off, since the code only travels in it
  • a shared coupon that is scheduled, switched off, used up or expired, that has fewer uses left than people still on the list (waiting or notified), or that takes nothing off any challenge you sell
  • a personal code without a discount, or one that makes a challenge free

An unfinished setup does not turn people away

A signup never fails because of the reward. If the coupon behind a shared code was deleted, signups still succeed and simply carry no code. Someone who left their email address should not get an error because a settings screen was half filled in.

Connecting your website

Create a key under API keys with the waitlist:write scope and post to POST /v1/waitlist/signups from your server, never from the browser. The response carries the discount code, so your page can show it right away instead of making people wait for the email.

In the older designs

Propper - OG and Tactical keep their earlier list of signups and their earlier settings page. The list there has search, a status filter, the export, and per row resending the confirmation and taking somebody off. Opening a signup by its own address shows that list searched for its email address. Adding somebody by hand, correcting a signup, marking people as notified, erasing, the purchases, the timeline and the Activity tab, the summary and the warnings in the settings are only in the standard design.

What the standard design sets still holds in the older ones. Resending a confirmation is refused with the reason, in every design, when the email or its template is switched off, and the export contains the same columns.