How to Write a Tender for an Online Voting Tool
When a hospital medical council, a professional order, a works council or a federation needs to elect its representatives online, the project usually starts with a tender. Writing a good request for quotation (RFQ) is half the work: a precise specification attracts serious offers, makes them comparable, and protects the integrity of the election that follows. A vague one invites underqualified bidders and surprises after the contract is signed.
Below is a practical checklist for procurement teams drafting the technical and contractual specifications for an online voting platform.
1. Describe the election, not just the software
Before any technical clause, state the facts that drive everything else: how many voters, how many separate ballots or colleges, whether seats are tied to languages or categories, the voting period, and the expected turnout peak. A platform that handles 200 voters in one college is not the same as one handling 8,000 across multiple colleges with quorum rules. Bidders cannot price or design correctly without these numbers.
2. Make secrecy and integrity non-negotiable
The ballot must be secret and the count must be honest — and the tool must be able to prove both. Ask explicitly for:
- Vote secrecy: no link between a voter's identity and their choice, by design.
- End-to-end verifiability: each voter can confirm their vote was recorded and counted, without revealing how they voted.
- Auditability: an independent observer can verify the result from cryptographic evidence after the election.
These are not optional features. They are the difference between an online survey and a legitimate election.
3. Require GDPR and data-residency clarity
The voter list is personal data. Ask where data is hosted, who has access, how long it is retained, and how it is deleted after the election. Request a description of the legal basis, a data processing agreement, and — for public institutions — confirmation that hosting meets your residency requirements.
4. Specify accessibility and languages
Professional electorates are diverse. Require multilingual ballots and interfaces matching your population, compatibility with screen readers, and a voting flow that works on a phone as well as a desktop. State the languages explicitly so they are quoted, not assumed.
5. Ask about support during the live period
An election happens once, on a fixed schedule, with no second chance. Ask for the support model during the voting window: response times, a named contact, and what happens if a voter cannot log in on the last morning. A great platform with no one answering the phone on election day is a risk.
6. Define what "done" looks like
Specify the deliverables you expect: a test election, a signed result report, the cryptographic audit material, and the destruction of personal data afterwards. Tie payment to these, not just to "access to the platform".
7. Set evaluation criteria that reward the right things
Finally, publish how you will score offers. If price is the only criterion, you will get the cheapest tool, not the safest election. Weight security, verifiability, references for comparable professional elections, and support quality alongside price.
A tender written this way does more than buy software. It defines, in advance, what a trustworthy election looks like for your organisation — and lets every bidder, including ONLZ, show exactly how they meet it.
