Create urgency at a moment you choose
Entry numbers for almost every race follow the same shape: a spike when registration opens, another as the deadline closes in, and a long flat stretch in between. It is that middle stretch that makes most organizers nervous enough to announce a price cut.
The problem with cutting the price for everyone is that you also discount the runners who were going to enter anyway — and the ones who already paid full price will, quite reasonably, feel short-changed. Once the questions start arriving on your page, you are left choosing between refunding the difference to everyone and living with the resentment.
Then the race ends and the question you cannot answer is how many extra entries all that discounting actually bought, because nothing in the data separates the runners who signed up because of the promotion from the ones who always intended to.
Build a code in your event dashboard: free entry, a percentage off or a fixed amount, which distances it applies to, when it expires and how many uses you are releasing. Every condition is enforced by the system, not an agreement you have to police yourself.
The code field sits in the entry flow, and the moment it is applied the original price is shown struck through next to what they actually pay. If the code has expired, run out or does not apply to that distance, the reason appears right there — rather than after they have finished entering and started arguing about it.
The code list shows uses against the number released for every code, and you can open any code to see which entries used it. If one gets shared more widely than you intended, switch it off mid-campaign — entries already made are untouched.
Set a price ladder by date for each distance in advance and the system picks the right price from the entry date — no getting up at midnight to change prices, and no risk of forgetting to close early-bird. The entry page shows the whole ladder with past tiers struck through, so runners can see for themselves that waiting costs more. The urgency is built in without you having to announce anything.
Set a fixed bundle — one marathon plus one mini at a single price, say — or a flexible rule that kicks in from a given number of entries, then share one link for the team captain to pass around. Anyone who opens it finds that price waiting, with no code to remember. You get entries in groups without quoting prices to each one in chat.
Set a registration window that only opens the form for people holding a code; everyone else cannot enter yet. It is a natural way to give last year’s runners or club members first pick — a reward that costs you nothing off the price — and it lets you test the whole flow with a small group before the public opening.
Rather than one code good for 50 uses — which is hard to control once it reaches a LINE group — issue a batch that shares a prefix, SPONSOR01 through SPONSOR50, each valid once. You can see how many of the places you gave away were actually taken, which is a number worth having when you renegotiate next year, and if one leaks you lose only that one.
Tie a code to the distances that still have room and it simply will not work on the ones already filling up. You can steer entries where you need them without discounting the whole race, and if you send the link with the code attached, the entry page shows only that distance — so nobody picks the wrong one.
Issue a single-use code for the amount you agreed. If the answer is a free entry, set the discount equal to the fee: the total comes to zero and the system confirms the entry automatically with nothing to pay. One code closes the matter — no bank transfer, no editing entries by hand — and there is a record of which entry it was used on.
Not yet — the system counts total uses of a code rather than tying it to a user account, so a single code with 50 uses could be spent by one entrant in one go. The approach that works today is a batch of single-use codes handed out individually, which gives you tighter control and lets you see exactly which ones have been redeemed.
For now, tell the team and we will generate them: you set the conditions once on a template code and the system produces a batch with a shared prefix and unique endings. If you already have a list of codes, send us the Excel file and we will import it. Creating them one at a time is something you can always do yourself.
The field only appears when the registration window is set to accept both open entries and codes. If it is set to open entries only, runners will not see it — that setting is the first thing to check, and the team can confirm it for you if you are unsure.
Not on the same entry — a runner uses one or the other, and if a group rate is selected the code field does not appear. That is deliberate: stacked discounts land below the price you intended. If a particular group should pay less, a second group rate keeps the numbers under your control.
The code list shows uses against the total released for each code, and you can open any of them to see the entries behind it. The money side lives in the downloadable sales file, which has per-entry columns for the code and the discount so you can total it in Excel. There is no ready-made summary page for discount totals yet.
Not currently, so distribution stays with you — your page, a LINE group, or a sponsor passing them on. The upside is that you choose the channel and the timing, and if you want to know which channel worked, issue a separate code per channel and compare how many were redeemed.