Click-and-collect alerts
Setting this up takes about a minute. The slow part is not the software — it is deciding what to call yourself, because the handle ends up on a poster and cannot be changed afterwards.
What this actually looks like
A bakery, a butcher, a bookshop and a bike shop all have the same afternoon problem: the order is ready and the customer is not there. One channel, one line per order number, and the collection counter stops being a queue of people asking whether their thing is done.
How you would set it up
- Create a channel for the shop and print its QR code on the order confirmation and at the till.
- Send the order number and the collection deadline. Nothing else needs to be in it.
- Wire it to your shop system when you are ready — one POST to the API sends the same line automatically.
One handle, printed once, permanent
A channel lives at drop.top followed by its handle, and that address never changes. It cannot be edited after creation, because it ends up on a poster in a school entrance, on a festival gate and inside a QR code somebody has already laminated. The page behind it explains what the channel is, what it asks a phone for, and how to subscribe — so a stranger reading a poster can decide before installing anything. We generate the QR code for you, server-side, and it is never sent to a third-party image service.
Draft, schedule, send — and what cancelling cannot undo
Composing and sending are deliberately different permissions, so the person or script that writes an alert can be forbidden from publishing it. A scheduled alert becomes visible at its time without anything having to run at that minute, which means a server that was briefly down delivers late rather than never. Cancelling is honest about its limits: it stops an alert reaching phones that have not fetched it yet and does nothing at all to the phones that already have it. An alert cannot be unsent.
Three numbers, and the one we will not print
You get: how many devices could be reached at the moment you sent, how many phones reported opening the alert, and how many acknowledged it. What you do not get is a delivery rate, because there is no per-device delivery record anywhere in this product — that absence is exactly what makes sending to four million people cost the same as sending to four. Reads and acknowledgements are self-reports from handsets that chose to send one, and they are labelled as such rather than dressed up as receipts.
Questions, answered plainly
Can I change my handle later?
No, and that is on purpose. It gets printed on posters and encoded into QR codes, and a handle that could change is a handle that turns somebody’s laminated sign into a dead link. Choose it the way you would choose a street name.
Can I unsend an alert?
No. Cancelling stops it reaching phones that have not fetched it yet, and does nothing to the ones that already have it. Compose as a draft and read it back before you send; that habit is worth more than any undo button we could offer.
Why is there no delivery rate?
Because there is no per-device delivery record anywhere in the product, and that is a deliberate design decision rather than a gap. A phone’s inbox is a query over sent alerts, which is what makes the cost independent of audience size. We would rather show three numbers we can stand behind than a fourth we invented.
Do subscribers need an account?
No. They install the app, subscribe to a handle, and that is the whole of it. Only the person running the channel signs up for anything.
Say it once. Every subscribed phone gets it.
Free up to 100 subscribers, no card to start, and the handle is yours permanently.
Start a channel