Ticket types that fit
Paid, free or donation. Quantity limits, sales windows, minimum and maximum per order, hidden tickets behind an access code, and your own rule for what happens when a type sells out.
Piletikohver is an Estonian ticketing platform you can set up in an afternoon. Create the event, put tickets on sale and check people in at the door with an ordinary phone. No app to install, no technician to hire.
Tallinna Tehnoloogiakolledž — Techno TLN, four schools merged into one campus with more than six thousand students — ran the ticketing for its 2026 opening day on Piletikohver. The tickets were free and closed: a guest list decided who could get one, and one address got one ticket. At the door, checks ran on QR codes, and anyone missing from the list got a ticket printed on the spot.
The demo event below is built from that same setup: the same ticket types and the same logic, without anyone’s data and without the school’s name on it.
The demo event is a real record on this platform, not a picture. Open it and click the booking form all the way through: ticket types, per-order limits, a discount code, custom questions and the confirmation. On a demo event no order is created, no ticket is issued and no email goes out — the form tells you so exactly where a real event would send the ticket.
The sample numbers in the reports below are from that same night.
This is what an event looks like in Piletikohver: three weeks before the doors open until the morning report. Every step below exists in the app — none of them is a roadmap item.
3 weeks out
Title, time, the venue picked off the map, a cover image. Three ticket types: student, staff and invited guest — all free, because the event belongs to the house itself. The guest type stays off public sale; the organiser issues those. One ticket per email address.
The cover image sets the page backdrop and suggests the accent colour.
2 weeks out
The guest list goes up as a CSV — close to two thousand addresses, and only those can claim a ticket. A shareable link and QR code, an Estonian and English page, a map with directions. The same booking form goes onto your own website with one line — nobody gets sent elsewhere.
Search engines get it right away: sitemap, hreflang and Event structured data are handled.
During the sale
When more buyers arrive than the form can hold, a waiting room forms: the visitor sees their place in the queue and an estimated wait, not an error. Browsing the page and picking tickets stay free — you only join the queue on “Continue”.
Measured on the server: 500 clients at once → exactly 50 let in, 450 queued, nothing oversold.
At the door
Door staff sign in with an email and a short code and see only that event. The scanner runs in the browser: phone camera, a USB reader or a code typed by hand. A repeat entry shows how many times that ticket has been used; an already-used ticket raises a warning.
If the network drops, the backup scanner works from the list on the device and syncs later — with the original scan time.
In the morning
Who came, who did not, which quarter of an hour was busiest, how many of each ticket type went and who on the list never claimed one. Four CSV files for reporting and for the post-mortem.
The attendance report uses the real scan time, not the moment of syncing.
Everything below is a working feature, not a roadmap item. Each one is a setting you can switch on yourself.
Paid, free or donation. Quantity limits, sales windows, minimum and maximum per order, hidden tickets behind an access code, and your own rule for what happens when a type sells out.
Custom questions in three groups: for the buyer, for each attendee and for the order. Ready-made fields for name, phone, ID code and organisation, plus twelve generic field types.
The scanner opens in the browser and works with the phone camera, a USB or Bluetooth reader, or a manually typed code. Double use raises a warning and a check-in can be undone.
Download the ticket list to the device and check people in even when the venue has no internet. Check-ins sync later and the report shows the real scanning time.
Build the seating plan row by row and take individual seats off sale. The visitor picks a seat from the map and it appears on the ticket and the PDF. One seat is sold exactly once.
Percentage or fixed amount, validity period, limits on uses and ticket types. Gift cards carry a balance and can be spent across several purchases.
Change the subject and the text, add an image and your brand colour, send yourself a test. The ticket travels as a QR code and a PDF attachment, optionally one email per attendee.
Event page, checkout, ticket and email in Estonian and English. The buyer's language is stored with the order, so the ticket arrives in the language the purchase was made in.
One line of code puts the ticket form on your own page without sending visitors elsewhere. The event page can also be shared as a link or a QR code.
A daily sales chart, a breakdown by ticket type, a searchable attendee list and CSV export. The report colours are checked for colour blindness.
Owner, manager and door staff. Door staff see only the scanner and the attendee list — not prices, revenue or buyer contacts.
Upload a CSV of invited addresses — six thousand rows at a time is fine — and only they can buy. You see who has bought and who has not, and you can export the list back to CSV. You can cap how many tickets one address may buy, with exceptions per guest.
Cover image, your own accent colour, customisable texts and the venue on a map with directions. The background tone is derived from the cover image automatically.
Everything below is the app’s own view — the same charts an organiser sees in the admin. The numbers come from the demo event so the view is full. Sales, visits and attendance are three different questions and they get three different views; two scales never share one axis.
Sample data from one techno night — the charts are the app’s real components.
Tickets issued
1638
27% of capacity
Orders
1421
Attended
1519
92.7% of tickets issued
Checking out at once · max
50 / 50
measured peak / configured limit
Tickets issued per day, and the split by ticket type.
Vii kursor tulba kohale, et näha täpset arvu
Last 30 days. Counted on the server, without cookies or tracking scripts.
Views
18940
Visitors
9120
unique
Picked a ticket
1640
18% of visitors
Conversion
15.6%
visitor to order
On a closed event the list decides who gets a ticket. The organiser sees, per address, whether the ticket was claimed, and can export the list three ways as CSV.
On the list
1900
Claimed a ticket
1526
80% on the list
Not claimed
374
Outside the list
112
issued by the organiser
Doors opened 21:30, last entry 01:52. Six scanners on one queue.
Attended
1519
92.7% of tickets issued
No-shows
119
Busiest 15 min
214
22:45–23:00
| Ticket type | Issued | Attended | Rate | Entries |
|---|---|---|---|---|
| Õpilane | 1240 | 1150 | 93% | 1190 |
| Töötaja | 286 | 268 | 94% | 281 |
| Kutsutud külaline | 112 | 101 | 90% | 128 |
| Total | 1638 | 1519 | 92.7% | 1599 |
Attendance and no-shows
One row per ticket: name, first and last arrival, number of entries and the staff member who scanned.
Attendees and tickets
Every ticket on its own row with the buyer details and the answers to all custom questions.
Orders
Per order: total, discount, number of tickets, time.
Full check-in log
Every entry and undo on its own row with local time, the staff member and the device.
We count visitors ourselves, on the server. No Google Analytics, no Meta pixel, no tracking cookie — the only cookie on the platform appears when an organiser signs in. A unique visitor is a one-day hash whose salt changes every night, and even those go into a counter, not a list. Bots and your own visits are not counted.
PrivacyTicket sales forgive mistakes; the door does not. It is 23:00, the queue is outside and the network is gone. That night is what the platform is built for.
The event’s ticket list is loaded onto the device and checks run against that copy. Entries queue up and reach the server when the network returns. With several scanners only the designated backup keeps working offline, so two devices cannot let the same ticket in.
Only the first one gets in. The rest see an “already used” warning, and a repeat entry shows how many times that ticket has been used. An entry can be undone if it was a mistake.
One tap creates the ticket, checks it in and sends it to a Brother label: QR, barcode and an eight-digit number. No name or email is asked — the queue keeps moving.
Staff are added by email address and reach only the scanner for the event they were assigned. Prices, revenue, buyer addresses and other events stay out of reach. Removing access ends their session for that event immediately.
These numbers were measured on the same platform your event would run on: four cores, six gigabytes of memory.
25 orders/s
1000 tickets for 1000 places — not one oversold
500 → 50
500 clients at once: exactly 50 in, 450 unique queue numbers
52 scans/s
1501 tickets on six scanners, p95 200 ms
13 tickets/s
500 quick tickets in a row, zero lost records
6000 rows
import 1.8 s, search 13 ms; ceiling 50,000 addresses
98–100/100
Lighthouse on mobile: performance, accessibility, best practices, SEO
Overselling is held off by a database lock and the waiting-room gate lives inside Redis as a single script — both because the first, simpler version sold 1002 tickets to a 1000-seat event in testing.
Getting a first event on sale usually takes about fifteen minutes.
Register an organiser account with an email address. No card details are asked for and nothing needs to be downloaded.
Title, time, venue and description. Add a cover image — the page colours are derived from it.
Create ticket types, set prices and quantities, and add the questions you need to ask attendees.
Check the page in preview, send yourself a test email, then publish. The shareable link and QR code are ready immediately.
Open the scanner on a phone, download the list and let people in. Door staff get their own account that shows nothing else.
Online payments are not part of Piletikohver yet. Free and registration tickets work fully: the ticket is issued immediately and reaches the buyer by email. For paid tickets you agree the payment with the buyer yourself — the system keeps prices, totals and reports in order. The payment layer is prepared in the data model and will follow separately. If you need payments now, write to us and let's talk.
info@kakuweb.eeCreating an account, adding events and selling free tickets is free. Terms for paid tickets are agreed separately, because they depend on how the money reaches you. There are no hidden fees and no mandatory plan.
Terms of useWe wrote this platform ourselves, start to finish — there is no third-party software here to shrug at. That means your unusual requirement does not end at “sorry, not possible”; it starts a conversation. Tell us how your event actually runs and we will look at what makes sense to build.
Unusual ticket logic, your own form fields, a different door routine or a link to a system you already use — tell us what you need and we will say honestly whether and when we can build it.
Cover image, accent colour, custom texts and the ticket email are already in your hands. If you need more — your own design, your own domain, the booking form inside your website — we will look at that too.
The person who writes the code answers the email. If your event is close, say so and we will plan the work around it.
Smaller improvements usually reach every organiser on the platform. If the need is very specific, we agree on it separately.
Yes. The attendee list, orders and check-ins can be downloaded as CSV files that open in Excel and Google Sheets.
You do. Piletikohver is the processor, you are the controller. We do not use your buyers' addresses for our own marketing and we do not sell them on.
Yes, at any time. Changes appear on the public page immediately. Tickets already issued stay valid and you can notify their holders.
Yes. A draft has a shareable preview link that works without logging in. The link can be regenerated whenever you want.
As many as you need. Add users in Settings and give each of them a role: owner, manager or door staff.
Mark the event as cancelled. A notice appears on the public page and you can email ticket holders with the reason. Cancelling tickets is a separate action and can be undone.
Creating an account takes a minute and nothing is paid up front. If you get stuck, write to us — we will help you set the event up.