Full article
Prize draw problems usually show up at the end, during adjudication, when the room goes quiet and someone asks why 400 entries look like cousins of the same address. By then, the choice is poor: let suspect entries through and dilute the prize pool, or exclude a block of people and risk catching genuine entrants in the same net. We learned that the hard way on a 2023 campaign when the draw slipped by two days for manual cleaning. I thought front-end validation was enough. I was wrong. It caught typos, not coordinated behaviour.
The useful question is not whether an email address is technically valid. It is whether the sign-up looks trustworthy enough to pass now, slow down for review, or stop. For UK competitions, that means setting a hold threshold for suspicious email clusters before the prize draw, with named owners, review dates, and acceptance criteria. If your plan has no owners and dates, it is not a plan. Fix it.
Decision context
This note is aimed at teams running high-volume UK competitions where list quality, deliverability, and draw integrity all matter at the same time. In our case, the operating assumption is a summer campaign with more than 250,000 entries and a prize draw scheduled for 15 August 2026. At that volume, one noisy source can distort the picture quickly. We have seen that before: a 2024 promotion picked up roughly 3,000 entries in one hour from a competition blog referral, and a material share of those later showed the hallmarks of bot-led activity.
There is a wider context here as well. ONS quarterly personal well-being and local authority datasets show that public mood and behaviour shift over time and by place, which is another reason not to overreact to every spike as fraud. A sudden increase in entries can be legitimate. The point is to distinguish a genuine surge from a manufactured cluster. Binary checks do not do that. A proper email judgement engine looks at the pattern around the address, not just the syntax of it.
Yesterday, after stand up, ticket KOS-771 was blocked by a dependency on final review rules. A quick call with Sarah Jones cleared it. New date set: 28 June 2026 for threshold configuration sign-off. That is the level of specificity this needs.
What should trigger a hold, not a hard stop
For competitions, a hold threshold is the useful middle ground between waving everything through and blocking too much. EVE is built for graded decisions: pass, hold, or stop. Low-risk entries should complete immediately. Very high-risk entries can be stopped with a clear reason. The middle band is where most operational value sits, because that is where false positives usually hide.
A suspicious email cluster should move to hold when at least two signals appear together within a defined time window. Examples include a burst of similarly structured local parts from the same domain, repeated sign-ups from a narrow IP range, or a run of addresses linked to newly created or low-reputation domains. The acceptance criteria need to be plain: the review queue should be explainable, reversible, and auditable. If an operator cannot say why an entry was held in one sentence, the rule is not ready.
As a starting point, a mid-risk threshold of 70 to 89 is workable for manual review, with 90 and above stopped pending policy rules. That is a starting point, not a law of physics. Between 09:30 and 10:15 last Tuesday, I rewrote the acceptance criteria for the cluster-review story, and tests only passed once a family-shared Wi-Fi edge case was covered. That is exactly why a hold band exists. It keeps the path to green open for genuine entrants.
Options and trade-offs
There are three realistic operating models here, and only one of them gives you enough control without creating unnecessary fallout.
| Option | What it means | Operational upside | Main risk | Checkpoint |
|---|---|---|---|---|
| Status quo | Keep front-end valid or invalid checks only | Fast journey, no extra review work | Fraud is discovered late, often during adjudication | Track manual exclusions and draw delays weekly |
| Aggressive blocking | Auto-reject new domains, high-velocity IPs, or pattern matches | Reduces obvious bad traffic quickly | High false-positive rate and avoidable entrant complaints | Measure blocked-entry appeals and approval reversals |
| Graded hold threshold | Pass low risk, hold mid risk, stop high risk | Better fraud control with lower customer harm | Needs queue ownership, SLA discipline, and tuning | Review hold rate, approval rate, and queue age daily |
The status quo is tidy until it is not. It pushes uncertainty downstream to the draw, where every decision costs more time and carries more reputational heat. Aggressive blocking looks decisive, but it is often a bit too clever for its own good. Shared networks, student housing, public Wi-Fi, and new but legitimate domains all get caught. That is bad ops and worse customer handling.
The graded model is the practical option. It treats email judgement as a decisioning problem rather than a formatting check. It also aligns with how strong campaign operations should run: clear thresholds, exception handling, and a change log when rules move.
Risk and mitigation
Setting a hold threshold adds work, so the controls need to be explicit. Below is the working delivery assurance view.
| Risk | Owner | Mitigation | Date | Acceptance criteria |
|---|---|---|---|---|
| Review queue becomes a bottleneck and delays legitimate entry confirmation | Sarah Jones, CRM Lead | Set a 4-hour review SLA for business hours, with overflow triage rules for weekends | 28 June 2026 | 90% of held entries reviewed within SLA in week one |
| Threshold is too sensitive and floods the queue | Mark Allen, Growth Lead | Start with hold band 70-89, review daily for first 7 days, tune once outcome data is stable | 8 July 2026 | Hold rate stays within agreed operating band and approval reversals are logged |
| Threshold is too loose and suspect entries pass through | L. Khan, Data Quality | Audit approved held entries against post-campaign fraud markers and suppression lists | 12 July 2026 first audit | Exception report issued with rule changes versioned |
| Poor data handling damages sender reputation | L. Khan, Data Quality | Keep held entries out of the main marketing list until approved, with suppression status recorded | Go-live 1 July 2026 | No held entry synced to primary send list before decision |
The measurable signals matter more than the sales message. Watch four numbers from day one: hold rate, approval rate from hold, median queue age, and downstream hard-bounce or complaint rate from approved entries. If those numbers drift, you have evidence for a rule change. If you do not track them, you are tuning by vibes, which is how teams get into trouble.
I am not fully convinced a 4-hour SLA will hold during peak weekend spikes. Bit tight on time, if I am honest. So the mitigation is simple: publish the weekend triage rule before launch, and staff to it. Better a realistic SLA with a clear fallback than a neat target no one can meet.
Recommended path
The recommendation is to implement a graded hold threshold in EVE before the next prize draw window, with configuration frozen by 28 June 2026, operational readiness checked on 1 July 2026, and the first tuning review on 8 July 2026. Mark Allen owns threshold setup. Sarah Jones owns queue handling and reviewer guidance. L. Khan owns suppression, auditability, and the change log. Sorted.
The initial policy should be conservative: pass low-risk entries instantly, hold the mid-risk band for review, and stop only where the evidence is strong enough to justify it. Every held decision should include the trigger signals, the review outcome, and the rule version used. That gives fraud, CRM, and compliance teams one shared source of truth. It also makes post-campaign adjudication faster because the reasoning is already there, not reconstructed in a hurry three days before the draw.
There is a useful precedent in high-volume campaign delivery: systems beat heroics. Holograph's campaign work has shown that modular, auditable operations scale better than one-off manual fixes, whether that is 812 assets on a launch or a promotion that overshoots target entry volumes. The same logic applies here. A hold threshold is not flashy. It is just good operational design.
What success looks like before the draw
Success is not zero risk. That promise would be nonsense. Success is a controlled process with evidence that the team can act on. Before the 15 August 2026 draw, you should be able to answer five questions quickly: what percentage of entries were held, how many were later approved, how long reviews took, which rules changed, and whether approved entries protected deliverability better than the old setup.
That last point matters. A competition can hit its entry target and still quietly damage future CRM performance if poor-quality addresses flow straight into the main list. The better outcome is steadier acquisition quality and fewer avoidable list hygiene issues. In plain terms: fewer bad addresses reaching your send domain, fewer awkward adjudication meetings, and a draw process that holds up under scrutiny.
If your current competition flow still relies on valid or invalid checks alone, it is worth reviewing before the next promotion goes live. Holograph can help you set an EVE hold threshold that is explainable, measurable, and workable for the team actually running the queue. If you want to pressure-test the rules, compare options, or map owners and dates into a launch plan, contact Holograph and we will walk through it with you properly. Cheers.
