Fast-track an application from the Telegram alert
Act on the summary card in chat, or open the deep link that claims the review for you.
Owned by Venue Manager · 12 steps · about 14 minutes
Why this exists
When a host application lands, the platform posts a summary card to the venue's Telegram chat with the headline facts and the viability score, plus inline buttons. The idea is that a decision which is obviously yes or obviously no should not require anybody to be at a laptop — a promoter waiting three days for a reply is a promoter taking their night somewhere else.
The card carries three tokenised actions and it is worth understanding what makes them safe. The accept and decline buttons are single-use tokens with a seventy-two hour life, consumed with a rowcount-guarded update so a double tap cannot double-act. The review deep link is multi-use and opens the application in the browser — and, if the application is still a new submission, it auto-claims it into under review, recording the source as telegram. That claim is the point: the queue always knows whether a human has picked something up, without anyone having to remember to press Start Review.
Fast-tracking from chat is exactly as powerful as approving from the dashboard, which means the same consequence follows: approval, in the same transaction, drafts the venue contract with riders derived from the flags the promoter set. Tapping accept in a group chat is signing up to the numbers on that application. Use the card when the answer is genuinely obvious and the deep link when it is not.
One safeguard to know: any transition to approved or rejected invalidates every unused token on that application — the accept and decline buttons, and any host edit link. A card sitting in chat from yesterday cannot re-decide something that has already been decided.
Before you start
- A venue manager or admin session for the browser half.
- An application in new_submission. The seed ships Warehouse Frequencies, scored 88.
- Telegram is a mock here — outbound cards are recorded rather than sent.
Practise with
| Persona | Password | Note | |
|---|---|---|---|
| venue_manager | manager@club.test | manager123 | shift lead: implies door_staff, plus intake, sales, guest list, marketing |
| host_promoter | host@club.test | host123 | owns the two seeded applications, Warehouse Frequencies and Analog Sunrise |
| admin | admin@club.test | admin123 | the only account that can touch money, identity and contracts |
Steps 1–8 — Venue Manager
their manual →-
1Read the card in the chat before touching a button. It carries the event name, the proposed date, the headcount and the viability score and band — enough to tell an obvious yes from an obvious no.Expected result A summary card with inline accept, decline and review buttons.Watch out for The score is advice, never a gate. A 40-point application on a dead Tuesday can be a better decision than an 80 on your busiest Saturday — the scorecard does not know your calendar.
-
2For anything less than obvious, tap the review link. It opens the application detail page and, if the application was still a new submission, silently claims it into under review with the source recorded as telegram.Expected result The full application with the status chip now reading under review.Watch out for That auto-claim is real work being recorded against you. Opening the link out of curiosity marks the application as picked up — if you are not going to review it, do not tap it.
-
3Read the scorecard panel properly: the score out of a hundred, its band, and the split between capacity points and revenue points, each out of fifty. Then read the flags — over capacity, low utilisation, below revenue floor, tier quantity mismatch.Expected result Two point bars, a band of viable, marginal or not viable, and any flags as red chips.Watch out for Bands are fixed: seventy and above is viable, forty to sixty-nine marginal, below forty not viable. The inputs line shows the venue capacity and revenue floor used — those are settings, and only an admin can change them.
-
4If the promoter has updated their numbers since submission, press Recompute so you are scoring the current figures.Expected result A fresh score and a new computed-at timestamp.Watch out for The score never blocks a transition. Recomputing is for your judgement, not for the machine's permission.
-
5To decline, press Decline and give a reason. The reason is required and it goes to the promoter in the decline email.Expected result Status rejected, the promoter emailed, the chat card edited, and every unused token invalidated.Watch out for A missing reason is a 422 decline_reason_required. Write something a stranger could act on — 'date already held' or 'headcount exceeds capacity' — because they will read it.
-
6To approve, press Approve. In the same transaction this drafts the venue contract with riders derived from the promoter's flags.Expected result Status approved and a draft contract waiting in the contracts list.Watch out for You approve; you cannot lock or countersign what approval drafted. That split is deliberate — running the calendar and binding the venue are different jobs.
-
7Leave a note whenever the decision needed context — a phone call, a past night, a condition you agreed verbally.Expected result The note in the activity timeline against your name.Watch out for Notes are the only place the reasoning survives. The status history records what happened, never why.
-
8Know the two things you will be refused. You cannot reopen a rejected application, and you cannot reject one that has already been approved or moved to contract deposit. Both are admin-only and both come back as a 403.Expected result A clean escalation rather than a confusing error.Watch out for These are late-stage reversals with contracts and possibly deposits behind them. The 403 is protecting a decision somebody else has already relied on.
Steps 9 — Host / Promoter
their manual →Is the applicant on the other end of whichever button gets tapped.
-
9As the promoter, if you were asked for more information instead, open the edit link you were emailed and answer it.Expected result Your application, editable, with no login.Watch out for That link dies the moment the application is approved or rejected. If it shows a friendly expired page, the decision has already been made.
Steps 10–12 — Admin
their manual →Owns the debug tools that replay a card button and re-send a card, and the late-stage transitions a manager is refused.
-
10As an admin, replay a recorded card button when you are testing the fast-track path or a manager reports a button that did nothing.Expected result The accept or decline runs through the real webhook path, exactly as the tap would have.Watch out for The plaintext tokens exist only inside the recorded outbound payloads — that is what makes replay possible, and why the token table stores hashes only.
-
11Re-send a summary card when the original was lost or the chat was wrong.Expected result A fresh card with fresh tokens.Watch out for Re-sending mints new tokens. The old card's buttons are now the stale ones — tell the chat, or somebody taps yesterday's card.
-
12When somebody swears no card arrived, check the recorded outbound traffic. Telegram and email are both mocks here and every call is recorded.Expected result The outbound call rows correlated to the application id.Watch out for A recorded call proves the platform tried. Whether a message actually lands depends on the install: the Telegram adapter defaults to a mock that records without sending, but this deployment runs it LIVE against a real staff channel. Check /admin/telegram for the mode before deciding a delivery failure is impossible — see the 'run-the-staff-channel-on-live-telegram' workflow.