# Quick Event — Knowledge Base for the Support Agent This file is the corpus the in-app studio support agent reads. It is also discoverable by external LLM crawlers at /llms-full.txt. Keep it concise, factual, and current. Do not invent features or behaviour beyond what is documented here. ## Pricing (current) Quick Event is priced per MODULE and per EVENT. There are no plan tiers, no per-guest charge and no paid add-ons inside a module. Building and testing an event is free — there is no trial, no time limit and no card. You pay once, for the modules you need, when you publish the event. The old pay-as-you-go model (€0.99 per participant + 2.75 %) was switched off in September 2026. If someone quotes it back at you, it is out of date. ### Modules (prices are NET, per event) - **Registration** — €590. Includes invitations. - Registration form builder and event page. - Ticket categories (called "contingents" inside the studio — same thing), capacity limits, group bookings. - Confirmation and follow-up emails, invitation sending, contact lists. - PDF tickets and Apple Wallet passes. - **Check-in** — €390. Includes badge printing. - QR-code check-in app, several entrances per event, check-out. - Badge designer and the desktop print station. - **Event app** — €1,390. - Agenda, speakers, networking, feed, polls, floor plan, push messages. - Installed from the browser; no App Store, no download. - **All three modules** — €1,990 instead of €2,370. - **Agency licence** — €14,900 a year. Ten events per module, i.e. €1,490 per event, all modules included. The studio calls it the **Pro licence** (Settings → Billing → Licence, button "Request Pro"). It also unlocks a domain of your own for events and for sending emails — see Event URLs and domains. ### Paid tickets Selling paid tickets adds a payment fee of **3.25 % + €0.25 per booking**, plus VAT on the fee. Card processing is included in that number — there is no separate Stripe charge. Quick Event keeps the fee automatically: it is taken from each payment before the rest is paid out, so there is nothing to transfer by hand. Payouts go directly to the organiser's own Stripe account. The organiser can get an invoice for the fee (see "Invoice for the payment fee" under Stripe Connect). Who bears the fee is the organiser's choice. On Registration → Tickets (Ticket types tab) the switch **Guest pays the payment fees** (it appears once a ticket has a price) is off by default: the fee is included in the ticket price and the organiser receives the price minus the fee. Switched on, the fee is added at checkout: the guest pays price plus fee and the organiser receives the full price. An example line under the switch shows the amounts for the first priced ticket. ### What never costs extra - The number of guests. A module costs the same for 80 people as for 8,000. - Follow-up emails to confirmed participants. - Any feature inside a module you have bought. ### Follow-up emails (free for everyone) Follow-up emails to confirmed participants are free on every plan — there is no add-on to buy. Send updates, reminders, and post-event messages to people who registered, at no extra cost. ### Your own domain Event addresses on a `.quick-event.com` subdomain are free for every account. Running events on a domain of your own is not part of the per-module prices; it comes with the agency licence (the "Pro licence" in the studio) — see Event URLs and domains. ## Event URLs and domains By default, every published event lives at: https://quick-event.com/ The address card above the page list on Registration → Event pages (`/studio//registration/page`) shows the address; its **Edit** button opens the sheet that changes it. The **Address type** is one of: - **Subdomain** — `.quick-event.com`. Included with every account; no DNS setup, it works at once. - **Your own domain** — such as `tickets.acme.com`. This is part of the Pro licence (the agency licence, see Pricing); without it the studio shows a notice instead of the domain list. The domain is added once for the whole account under Settings → Domains → **Event domain**: one CNAME record at the DNS provider, and the SSL certificate is issued automatically. Once verified it can be picked in that address sheet for any event of that owner; unverified domains are listed but greyed out. The switch **Use this address only for this event** decides what sits at the root: on, guests land directly on the root of the address and only this one event can use it that way; off, the event sits at `/` and the address can serve several events. The `` part is the **Event address** in the same sheet; old links keep working and forward to the new one. Additional languages live under a language prefix in front of the event, e.g. `quick-event.com/en/` (see Multilingual events). ## Event pages Each event has its own event pages, built under Registration → Event pages from sections (hero, tickets, content, FAQ, etc.) using the section preset library. The first page is the landing page attendees see at the event address; further pages get their own address (`//`). ## How to publish an event Going live happens PER MODULE — that is also when a module is paid for. Each module's **Overview** page (click the module name in the sidebar) carries its setup list and the **Go live** sheet. Opening an event lands on the Overview of its first live module (Registration if nothing is live yet); the sidebar header shows how many days are left until the event. Once the module is unlocked, the sheet lists what is still missing under "Missing before you can publish", each with an **Open** link, and **Publish now** stays disabled until the list is empty. These blockers apply to the Registration module; Check-in and Event app have none. The possible blockers are: - **Event name** - **Start and end date** (and their times) - **Organiser details** — company and contact e-mail - **Event logo** - **Favicon** - **Payouts** — only when the event sells paid tickets - **Translations** — only when a language visible to guests still has open texts All of them live under Event settings → Key details, Event settings → Branding, Registration → Languages, or Registration → Payment. Fix the item, reopen the sheet, publish. After publishing, the event is live at `quick-event.com/` (or the organiser's own domain, see the address card on Registration → Event pages). ## Stripe Connect (paid events) Paid events use Stripe Connect to route money directly to the organiser's bank account. Quick Event never holds the funds. ### Onboarding When you enable paid tickets for the first time, the studio walks you through Stripe Connect onboarding. Required minimum information depends on country and business type. You'll typically be asked for: - Business type (individual or company). - Tax ID (if applicable). - Bank account / IBAN. ### Identity verification — only when triggered Stripe Connect uses **risk-based KYC**. ID verification is **not** required up-front for most organisers — you can usually start accepting payments immediately. Stripe asks for ID documents (passport or national ID, sometimes a selfie or proof of address) only when one of these fires: - A volume threshold is reached for the country (e.g. for Germany, Stripe typically requests verification once an account approaches a few thousand euros of processed volume — the exact threshold changes and is country-specific). - Risk signals trigger an early review. - The country / business type requires it up-front (some company structures do). When triggered, Stripe surfaces the verification request inside its hosted flow; the studio shows a banner with a deep-link to complete it. Until verification is satisfied, payouts can be paused but charges usually continue. For authoritative thresholds and the current list of required documents, point users to https://stripe.com/docs/connect/identity-verification. Don't quote a specific number from memory — thresholds change. ### Status flags shown in the studio Stripe reports two independent capabilities, both surfaced under Registration → Payment (`/studio//registration/payment`): - **chargesEnabled** — you can accept card payments. Required to publish a paid event. - **payoutsEnabled** — Stripe can send money to your bank. Required to receive your funds. If you skipped IBAN during onboarding this stays off and the studio shows a soft-prompt banner. Charges still work in this state, but money sits on your Stripe balance until you add the IBAN. ### Payout schedule Default Stripe schedule applies (typically T+7 or rolling daily after the first payout). Change it in your Stripe Dashboard. ### Invoice for the payment fee The payment fee is already taken from the payments, but the organiser can get an invoice for it — for bookkeeping and VAT deduction. It is the card **Invoice for our payment fee** at the bottom of Registration → Payment (`/studio//registration/payment`). It appears once payouts are active and only for people who may manage payouts: the owner of the event or anyone with the "Publishing & billing" right. - One invoice per event, created with the **Create invoice** button. It is deliberately not automatic: create it once ticket sales are over. - The card shows what the invoice covers: "N paid bookings · amount net". Fees that were returned through refunds are left out. - The invoice is issued by Quick Event to the owner of the event, with VAT added, and is already marked as paid because the fee was taken from the payments. Afterwards the card shows **Open invoice** with the invoice number instead of the button. - If creating it fails, the message says the billing address of the event owner may be incomplete. ### Refunds Refunds are issued from the studio: Registration → Registrations → Bookings tab → open the booking → **Refund** (bottom left of the "Booking details" sheet; it is shown for paid bookings that were paid through Stripe). The button refunds the whole booking; it asks for confirmation first and a refund cannot be undone. Someone who needs a partial refund should use "Email a human". The buyer gets the money back through Stripe, and the Quick Event payment fee (3.25 % + €0.25 per booking) on that booking is returned too: in full on a full refund, and in proportion if a refund covers only part of the payment. A fully refunded booking is cancelled, its places are released and its participants are removed from the participant list. Refunding needs Edit on **Publishing & billing** for the event (the owner always has it). ### Disputes Disputes are handled via Stripe directly. The studio surfaces an alert, but evidence is submitted through the Stripe Dashboard. ## PDF tickets and Apple Wallet passes For ticketed events (free or paid), every successful registration produces: - A **PDF ticket** with the attendee's QR code, branded with the event's colours, fonts, and design. - An **Apple Wallet pass** (`.pkpass`) for iPhone Wallet — Android users get the PDF. Both are delivered in two ways simultaneously: 1. **On the success page**, immediately after the registration is complete. The attendee can download the PDF and add the Wallet pass in one click without leaving the browser. 2. **Attached to the confirmation email** that fires automatically after registration. The same PDF and Wallet pass are attached, so the attendee can add them to Wallet later or print them. The ticket's look follows the event: logo, colours and fonts come from Event settings → Branding, and the Wallet pass follows the event's light or dark theme. Registration → **Tickets** (`/studio//registration/tickets`) shows a live preview of the Wallet card and the PDF ticket next to the list of ticket types. ## Email campaigns Three email kinds: - **Confirmation email** — automatic, fires after a successful registration. PDF ticket + Apple Wallet pass are attached. One template per event, created automatically, fully editable. - **Follow-up email** — free for everyone. Updates, reminders, and post-event messages sent in bulk to confirmed participants. - **Test send** — preview any template by sending it to yourself from the email editor. ### How to actually send a follow-up (exact steps) There is **no "Follow-up" tab and no "Campaigns" page.** Do not send anyone looking for one. `/studio//registration/emails` redirects straight into the email editor, and the tabs across the top of that editor list the templates that *currently exist* for the event — nothing else. A new event has exactly one: **Confirmation**. A follow-up is a template the organiser creates themselves: 1. Registration → **Emails** (this opens the email editor on the Confirmation template). 2. Click the **"+"** at the end of the row of template tabs and give the new template a name (e.g. "Reminder"). It then appears as its own tab, under the name they chose. 3. Write the email, then **Save**. 4. Click **Send** (German: "Senden") in the top-right toolbar. This opens the send sheet, where they choose which confirmed participants receive it — all of them, a saved filter, or a hand-picked selection. The Send button is greyed out while there are unsaved changes, so save first. The Send button is deliberately absent on the Confirmation template — that one is automatic and fires per registration, not in bulk. If someone reports "follow-up is not showing" or cannot find a follow-up tab, they are describing the product correctly. The tab does not exist until they create the template. Walk them through the four steps above. The email editor is theme-aware — colours, border radius, and fonts you set under Event settings → Branding are applied at send time. Update Branding after saving an email and the next send picks up the new theme automatically. ### "My email isn't arriving" Quick triage: 1. Check spam — the most common cause. 2. Confirm the recipient's email is correct (typos in form-collected addresses are common). 3. Registration → **Recipients** shows the per-address status (sent, delivered, bounced, opened). ## Forms The form builder lives at Registration → **Registration form**. Each field has: - Label, type (text / email / select / checkbox / date / phone / etc.). - Required / optional toggle. - Conditional visibility (show field X only if field Y has value Z). Forms are saved as JSON and rendered live on the event page. Recommended minimum: First Name, Last Name, Email. ## Participants and contacts - **Participants** — people who registered for a specific event. Listed under Registration → **Registrations**, Participants tab. Filterable, exportable. - **Contacts** — the recipient list at Registration → **Recipients** (`/studio//registration/contacts`). Imported from CSV or added one-by-one. - **Bookings** — a booking is a single registration submission. It can contain multiple participants (someone registering themselves and a +1) and multiple booking items (one per ticket selected). Data model: booking → bookingItem → participantBookingItem → participant. ## Registering several people at once (+1, partner, group) **This feature exists and ships today.** One person can register several distinct people — each with their own name, email, and answers to the form — in a single submission. It is off by default and controlled by one setting: > Registration → **Settings**, section "Participants": > **"Maximum per registration"** (German: "Maximal pro Anmeldung"). > The hint under the field reads "How many people one person can > register in a single booking." - Default is **1**. At 1 the visitor is taken straight to a single participant form and never sees a people-count step. This is the usual reason an organiser thinks the feature is missing. - Set it to 2 or higher and the registration wizard first asks the visitor how many people they are registering (1 up to the number you set), then walks through one full form per person, labelled "Person 1 of 2", "Person 2 of 2", and so on. - Every person gets their own participant record, their own ticket, and their own confirmation email / PDF / Wallet pass. So when an organiser asks for "+1", "bring a partner", "register my colleagues", "group booking", or "several people in one form": the answer is to raise this number. Never tell them the product cannot do it — it can. ## Check-in Mobile-friendly check-in app, paired from Check-in → **Check-in app** (`/studio//check-in/app`). Two modes: - **QR scan** — point camera at the participant's PDF or Wallet QR code. - **Search** — type a name or email. Each check-in is timestamped. You can also un-check in. ## AI features - **Event creation from a prompt** — describe your event in one sentence on the public homepage, or choose **AI setup** in the studio's "New event" dialog, and Quick Event generates a starter event (settings, page, form, emails) using Gemini 3.1 Flash Lite. Refine afterwards. - **Page section generation** — pick a section preset, click Generate, the AI fills it with content from your event description. - **Brand extraction** — paste a website URL and the AI extracts colours, fonts, and logo from a screenshot of that site. - **Studio Copilot** (the in-editor chat that manipulated the page, form, and emails directly) — currently disabled. The active conversational helper is the support agent (this assistant). ## Section presets 107 presets across 14 categories: hero, text, image and text, CTA, gallery, timeline, countdown, map, logos, people, FAQ, tickets, video and stats. Inside the studio, the "+" between sections on Registration → Event pages opens the preset picker. Each preset is configurable: text, images, columns, theme overrides. ## GDPR and data residency - All data stored in the EU. - Hosted by Hetzner Online in German data centres (Nuremberg for the live system, Falkenstein for backups). - Database: PostgreSQL, in the same German data centre. - Uploaded files (logos, images, PDFs) in German object storage. - Participant data is exportable as CSV from Registration → Registrations. - Right-to-erasure: delete a participant from the studio; the row and its booking-item links are hard-deleted. - Support-conversation logs are retained for product improvement and not shared with third parties. **"Do event pages need a cookie banner?"** — Not by default. Event pages, the registration and the guest app store nothing that needs consent — only what is technically necessary, such as the language, the sign-in to the event app and the choice to load embedded content — and Quick Event runs no advertising or analytics tags of its own there; visits are counted without cookies. Videos from YouTube or Vimeo load only after the visitor clicks them, and the map is served from our own servers. A cookie banner appears only when the organiser connects their own tracking (Registration → Integrations, Tracking tab), and none of it loads before the visitor agrees. The privacy notice for participants is at /privacy. **"Can an event run without service providers that have a US parent company?"** — Yes, per event and on request. We switch it on for you; it is not a setting in the studio, which only shows a bar saying that the event runs this way. It is offered in section 6.5 of the data processing agreement: for that event only Hetzner Online in Germany acts as sub-processor. On such an event: - Online payment is off, so it works for free events only (we do not switch it on while a ticket type has a price). - Quick Event sends no emails for the event: no confirmations, invitations, follow-ups or sign-in codes, and the external email address check is off. Participants save their ticket (PDF, Apple Wallet, QR code) on the confirmation page and open the event app through a personal link on that page (also a QR code on the ticket) instead of an email code. The organiser sends invitations through their own email route. - Error monitoring, analytics, the organiser's own tracking and the CRM push are off. - The guests' AI assistant (the AI concierge in the event app) and the AI question-and-answer chat of the event are off. - YouTube and Vimeo videos appear only as a link. Web push notifications keep working: their content is end-to-end encrypted and the participant's browser chooses the push service. ## Multilingual events An event can be offered in several languages: event pages, registration form, tickets, checkout and emails. It is included in every event — no extra module, no extra fee. **How it is set up** - The event language (Event settings → Key details → Language) is the ORIGINAL. Everything is written in it; it is also the fallback. - Additional languages are added with the "+" next to the language tabs on Registration → Languages (`/studio//registration/languages`), not in Key details. Up to eight additional languages (all nine interface languages minus the event language). - **Languages** is a regular page of the Registration module (group "Set up"), there even before the first additional language exists. - While additional languages exist, the event language itself is locked — remove the additional languages first if it really has to change. - Only TEXT is translated. Sections, images, prices, dates, form fields and ticket types are the same in every language. **Translating (Registration → Languages)** - One tab per language; inside it, tabs per area (Event page, Registration form, Tickets, Emails, Event) and per page or email template. Original on the left, translation on the right, saved when leaving the field. Formatting (bold, links, coloured words) is edited like in the editors — no HTML. - "Fill missing and outdated translations with AI" fills every text that is missing, outdated or formatted differently. Hand-written texts are never overwritten. - Texts filled by the AI carry an **AI** tag until someone edits them or clicks **Looks right**. "Mark all as reviewed (N)" does that for all AI texts of the current tab. The tag blocks nothing. - **Outdated**: the original changed after translating. **Formatting differs**: bold, links or coloured words differ from the original. Fix the text, or click **Looks right** if it still fits — it then counts as done until the original changes again. - "Open in editor" jumps to the page or email where the original lives. In the editors, the language buttons in the page header show the state of THAT page: green = complete, red = open texts in a visible language, grey = open texts in a hidden language. Clicking one opens exactly those texts. **Going live with a language** - New languages start **hidden**: only studio users see them, through the Preview button. Switch "Visible to visitors" on when the language is complete — the switch stays locked while any text is missing or outdated. - A visible language with open texts gets a red dot (Languages menu item, language tab). Registration cannot go live while a visible language has open texts. All visible languages complete = green dot. - Visitors never see an empty field: anything untranslated shows in the event language. **What visitors get** - Every language has its own address: `quick-event.com/en/`, `quick-event.com/es/` (on a custom domain: `/en/…`). The event language has no prefix. These links can be shared. - Opening the plain event address picks the visitor's browser language if that language is visible (otherwise the event language). A language the visitor chose in the switcher wins over the browser. - A language switcher appears in the event page header as soon as an additional language is visible. - Search engines get every visible language (hreflang, sitemap). **Emails, tickets, contacts** - Emails and PDF tickets go out in the RECIPIENT's language: the language they registered in, else the contact's language, else the event language — only visible languages count. - Contacts have a Language field (contact sheet, column in the recipient list, CSV import column "Language"; values like "English", "EN" or "en-US" are recognised). - When sending invitations, "Language of the email" limits the recipients to one language — useful to send a separately worded invitation per language. **Common questions** - "Why can't I switch the language to visible?" — Texts are still missing or outdated. The number is shown next to the switch; "Fill missing and outdated translations with AI" or the list below fixes them. - "Why is a word red in the translation?" — It is probably not an error: coloured words use the event's primary colour, the same as in the original. - "Can I translate in the page editor?" — No, translating happens on Registration → Languages; the editors keep the original. The language buttons in the editor header jump there. ## Common questions **"Why can't I publish?"** — Open the module's Overview and its **Go live** sheet. Once the module is unlocked, the sheet lists what is still missing under "Missing before you can publish", each with an **Open** link, and **Publish now** stays disabled until the list is empty (see How to publish an event). **"What's my event URL?"** — `https://quick-event.com/`, or the subdomain or own domain set in the address card on Registration → Event pages. Additional languages: `//`, e.g. `/en/`. **"Where do I see my payouts?"** — Registration → Payment, once payouts are active: the Stripe balance (Available, Pending, Next payout), the list of **Payouts** and, below it, the **Payments** list — one row per paid booking (refunded ones are marked), searchable, with CSV export. These sections are shown to the owner of the event and to people with the "Publishing & billing" right. Detailed transactions are also in your Stripe Dashboard (**Open Stripe dashboard**). **"How do I refund a ticket?"** — Registration → Registrations → Bookings tab → click the booking → Refund. It refunds the whole booking (see Refunds under Stripe Connect). **"Where is the attendee's ticket?"** — On the registration success page (downloadable PDF and Apple Wallet pass) **and** attached to the confirmation email. **"Do I have to verify my ID with Stripe before going live?"** — Usually no. Stripe asks for ID only when triggered by volume, risk signals, or country-specific rules. See Stripe's docs for the current threshold for your country. **"Can I send an invoice?"** — Paid bookings get one automatically; free bookings (including 100 % vouchers) do not. The buyer's confirmation email carries a PDF invoice issued in the organiser's name, with the event's logo (from Event settings → Branding), and — when Stripe provides it — a payment receipt. The invoice says "Already paid at booking" and shows the VAT rate and the organiser's VAT ID or tax number, if they are set under Registration → Payment, card "Value added tax": **VAT rate on tickets (%)** (included in the ticket prices) and **VAT ID or tax number** (required for invoices over €250). Above €250 the checkout also asks for the buyer's billing address, and buyers can add their own VAT ID there. For the organiser's bookkeeping: - Registration → Registrations → **Bookings** tab: the column **Invoice no.** (it is in the export too), and **Open invoice** in the booking sheet. - Registration → **Payment**: the **Payments** list (its columns "Invoice no." and "Refunded" can be switched on) and the invoice for Quick Event's own payment fee (see "Invoice for the payment fee"). **"Do you have an API?"** — Limited at the moment. /features/platform/integrations lists what is public today (event creation, MCP server, webhooks). For deeper integrations, contact support. **"Can I clone an event?"** — Yes. On the events overview (`/studio`, tab "My events") use the copy button in the event's row (tooltip "Copy event"). It makes an exact copy and opens it. It is offered for your own events, not for events shared with you. **"Can my team edit the event?"** — Yes, per event: Event settings → Team (`/studio//event/team`). Enter a colleague's email under **Add someone**: with a Quick Event account they get access at once; without one the page offers **Send invitation**, and after signing up the person lands in this event. Rights are set per person, per module and page — **No access**, **View** or **Edit** — with the "Edit rights" button (presets: Edit everything, View everything, Hotel). New people start with Edit on everything except **Publishing & billing**; that right covers going live, payouts and refunds, and only someone who has it can pass it on. The owner always has everything. **Limit to certain registrations** lets a person see only certain ticket types or form answers. People with Edit on the Team page can add people and change rights. **"How do I cancel an event?"** — In steps. Tell the participants by email (Registration → Emails: create a template with the "+", write it, then **Send** — see the follow-up steps above). Refund paid bookings one by one (Registration → Registrations → Bookings tab → open the booking → Refund). Close registration with the deadline under Registration → Settings. To take the event offline, use "Email a human". **"Can I put the registration on my own website?"** — Yes. Registration → Settings (`/studio//registration/settings`) has the card **Embed on your website** with a code to copy (**Copy**): an iframe plus a small script that resizes it. Paste it where the registration should appear; it works on any domain. - Only the registration is embedded — form, checkout and confirmation page — not the event page. - Paid tickets work inside the frame: guests pay by card, Apple Pay, Google Pay or Link. For other payment methods a link opens the full checkout in the whole window. - A password-protected event cannot be embedded; the frame shows a notice instead. - If Google Tag Manager or Matomo is installed on that page, the code passes the registration steps and purchases to it. Six events are sent, from view_event to registration_completed; **Which tracking events are sent?** under the code lists when each fires and which fields it carries. No personal data is sent. **"How do vouchers (discount codes) work?"** — Registration → Tickets → tab **Vouchers** (`/studio//registration/tickets`). A voucher takes a percentage or a fixed amount off paid tickets; a 100 % voucher makes the booking free — no payment step, no payment fee. - A code counts **per person**: a booking for three people uses three redemptions, several tickets of the same person count once. If fewer redemptions are left than there are people, the first people get the discount and the rest pay in full; the guest sees how many people the code covers. A fixed amount applies per person. - Each person in a booking can enter their **own** code, or the same one as the other. The code field is already on the ticket selection once the event has paid tickets and an active code; ticket cards show the list price struck through next to the price after the code. - Refunding a paid booking does not give the redemption back. - Registration → Registrations shows the code in the **Voucher** column: per person on the Participants tab, per booking on the Bookings tab. Confirmation emails show the real discount per person and only the recipient's own code. **"How do I create many voucher codes, or personal ones?"** — On the Vouchers tab, **New voucher** makes one code: an internal name (optional), the code or **Generate**, the discount in percent or as an amount, **Maximum redemptions**, a valid period and active or not. **Create several** makes many at once: **With prefix** (the prefix plus six random characters, for example FREEDOM7K2QXM, in the number you choose) or **One per contact** (every contact of a contact group gets a code of their own; contacts that already have one are skipped). Put the "Discount code" placeholder into an invitation email and each contact receives their own code. A code is not tied to its contact: whoever has it can use it. The list has search, filters and CSV export; tick rows to change status, discount, maximum redemptions or valid dates for all of them at once, or to delete them. A redeemed voucher cannot be deleted — switch it off instead. ## Real public routes — only link to these When you cite a page, use only one of these. Do not invent routes. Top-level marketing & legal: - `/pricing` — pricing page (per-module prices per event: registration €590, check-in €390, event app €1,390, all three €1,990; payment fee 3.25 % + €0.25 per booking on paid tickets; module calculator). **There is no `/docs/pricing` — the canonical pricing page is `/pricing`.** - `/contact` — public contact form (also reachable via the "Email a human" button in this chat). - `/wedding-website`, `/features` — marketing landing pages. - `/imprint`, `/privacy`, `/privacy-for-organizers`, `/terms` — legal. `/privacy` is the privacy notice for event participants (event pages, registration, emails, event app); `/privacy-for-organizers` is the one for organisers and website visitors. - `/login`, `/register` — auth. - `/me/` — a participant's personal accreditation page, the address behind the QR code on their ticket. It is private and not indexed — never link to it. - `/` and, for each visible additional language, `//` (e.g. `/en/`) — event pages. - `/llms.txt`, `/llms-full.txt` — LLM-discoverable site index and full knowledge base. Feature routes — every feature page is `/features//`, with `` one of `platform`, `registration`, `check-in` or `event-app`. These exist (English slugs on every level, in every language): - `/features` — the overview: four areas, 24 feature pages, live search over 194 use cases - `/features/platform` — Platform area page; its feature pages: `/features/platform/ai-creation`, `/features/platform/studio`, `/features/platform/multilingual-events`, `/features/platform/custom-domains`, `/features/platform/tracking`, `/features/platform/integrations` - `/features/registration` — Registration area page; its feature pages: `/features/registration/event-pages`, `/features/registration/forms`, `/features/registration/tickets`, `/features/registration/participants`, `/features/registration/crm`, `/features/registration/invitations`, `/features/registration/guest-lists`, `/features/registration/email-sender` - `/features/check-in` — Check-in area page; its feature pages: `/features/check-in/qr-check-in`, `/features/check-in/badge-printing`, `/features/check-in/check-in-points`, `/features/check-in/live-attendance` - `/features/event-app` — Event app area page; its feature pages: `/features/event-app/web-app`, `/features/event-app/agenda`, `/features/event-app/networking`, `/features/event-app/ai-concierge`, `/features/event-app/polls`, `/features/event-app/sponsors` - `/solutions/agencies`, `/solutions/companies`, `/solutions/trade-fairs` — solution pages per audience **There is no `/docs` section any more, and no flat `/features/` pages either.** Old `/docs/...`, flat `/features/tickets`-style and German `/funktionen/...` addresses still redirect, but never link to one — link to the `/features//` page above. If a topic doesn't have a dedicated feature page, point at the most relevant one above (or `/pricing` for billing) and answer from this knowledge base — never link to a route that isn't in the list. ## Studio pages — what each one does The sidebar starts with the event's **Overview** at the top, then three modules — Registration, Check-in and Event app — and ends with **Event settings** (Key details, Branding, Team) at the bottom. Clicking a module name opens its own **Overview** landing page and shows its pages. Every page lives at `/studio///`; the Overview and the Event settings pages sit under `/studio//event/`. `/studio/` on its own redirects to the first page the user may see, normally the Overview. What it costs (see Pricing above): the Overview and Event settings are always free, **Registration** €590 (emails, invitations and the recipient list included), **Check-in** €390, **Event app** €1,390. Every page is reachable and editable before payment — you pay when you publish, not to look around. Each page has its own walkthrough: invite the user to click the "Start tutorial: …" chip that appears when they open the support panel on that page. There is no separate "Design" page or slide-in panel any more — branding lives under Event settings → Branding. ### Registration — take registrations (€590, emails included) Below the module name come **Registrations**, then two groups: **Set up** (Settings, Event pages, Registration form, Tickets, Payment, Integrations, Languages) and **Communication** (Emails, Recipients). - **Overview** (`/studio//registration/overview`) — registrations, bookings and revenue at a glance, plus the setup (including the Event settings checks) and the way to go live. This is where Studio usually opens. Contacts, invitations and emails are a section of the same page, with the path from invitation to registration. - **Registrations** (`/studio//registration/registrations`) — two views of the same data, one tab for participants and one for the bookings they arrived through. The columns follow the registration form. Abandoned bookings are hidden. Confirmations can be resent from here. - **Settings** (`/studio//registration/settings`) — affects only the registration: when it closes (**Registration deadline**), how many people may come (**Total number of participants**, **Maximum per registration**), and who gets in (**Password protection**, **Invitation only**, **Findable on Google**), plus the contact window, the note on the confirmation page and the code for embedding the registration on your own website. Shared details stay under Event settings → Key details. - **Event pages** (`/studio//registration/page`) — the website guests see. Above the list sits the address card with the event's web address; its **Edit** button opens the sheet for the address: a subdomain (free) or the customer's own domain (part of the Pro licence), and what sits at its root. An event can have several pages; the list shows all of them and a click opens one in the editor. Inside: sections, the "+" between them adds one from the preset library, a settings popover per section, and a Preview button. - **Registration form** (`/studio//registration/form`) — what people fill in. Drag to reorder, click a field for its settings, conditional fields react live. Changes are a draft until Save. - **Tickets** (`/studio//registration/tickets`) — two tabs: **Ticket types** (prices, with a live preview of the ticket beside the list) and **Vouchers**. Paid tickets can be set up before Payment is, but the registration cannot go live with them until payouts are set up. A 100% voucher is not a payment. - **Payment** (`/studio//registration/payment`) — Stripe Connect onboarding, the payout account and the status flags. Set up once and reusable across events, then revenue flows from the buyer to the organiser's bank account; Quick Event never holds the money. Once payouts are active, people who may manage payouts (the owner, or anyone with the "Publishing & billing" right) also see the balance, the payouts, a Payments list and the invoice for the payment fee; the VAT rate and VAT ID for ticket invoices sit on the same page. - **Integrations** (`/studio//registration/integrations`) — two tabs. **Tracking**: the organiser's own tracking IDs for this event; events are sent server-side and only after the guest has consented. **CRM connection**: sends data OUT of Quick Event to the organiser's own endpoint. One-way: nothing can be written into the event from outside. The same record may arrive twice. - **Languages** (`/studio//registration/languages`) — additional languages are added here (the "+" next to the language tabs). Translations, AI fill, review and "Visible to visitors" per language — see Multilingual events above. - **Emails** (`/studio//registration/emails`) — three tabs, three recipient rules: *Automatic* (runs on its own, e.g. confirmations), *Invitation* (may go to the uploaded recipient list) and *More emails* (to registered guests). Drafts wait for the button — nothing sends on a schedule. Placeholders are documented on the page. The sender address sits in the page header; clicking it opens the **Sender** sheet — which address emails leave from. The invitation path has stricter rules than the transactional one; the sheet's top box shows the result, not a wish. The sending domain itself is set up under Settings → Domains. - **Recipients** (`/studio//registration/contacts`) — the uploaded recipient list, the only audience an invitation may go to. Sending happens right next to the list; the statuses show what happened to each address. ### Check-in — the event day itself (€390) - **Overview** (`/studio//check-in/overview`) — check-ins, devices and print stations at a glance, plus the setup for event day. - **Check-in points** (`/studio//check-in/settings`) — a check-in point is one place where guests get scanned: main entrance, workshop room, evening party. Every event starts with a main entrance. Per point: who may pass and where badges are printed. - **Badge design** (`/studio//check-in/badge-design`) — how the badge looks, and only that. Bound fields come from the registration form. Everything that depends on the device on site (printer, duplex, calibration) lives on the print station, so the same template works everywhere. - **Print station** (`/studio//check-in/print-station`) — a laptop plus badge printer at the entrance: check someone in and the badge comes out. Needs setting up once, and calibration is not optional. - **Check-in app** (`/studio//check-in/app`) — getting the scanner onto phones. There is no app to install: pairing codes for entrance and lead devices, the devices paired right now, and a demo guest to test with. ### Event app — the app for your guests (€1,390) - **Overview** (`/studio//app/overview`) — guests in the app, reach and interactions at a glance, plus the setup of the event app. - **App identity** (`/studio//app/identity`) — icon, name, cover image and colours, i.e. everything guests see when they install the app. The app colours are not the brand colours; long names get cut off on the home screen. - **Content** (`/studio//app/content`) — sections are the menu of the guest app. Each one becomes an entry: the first three sit in the bottom bar, the rest in the menu grid. Order matters, some features need another one to be switched on. - **Home screen** (`/studio//app/home`) — the screen attendees land on, arranged from blocks, with a live phone preview. There is no save button. Blocks without content do not appear. - **AI concierge** (`/studio//app/ai`) — who the assistant is and what it knows. The knowledge decides whether it can help; shortcuts are the same entries the guests see; placeholders work in the welcome message. On an event without US providers (see GDPR and data residency) the concierge is switched off: its tile is removed from the guest app, its AI page sends guests back to the app's start page, and the assistant does not answer. - **Guests & access** (`/studio//app/access`) — who gets into the app and what they may do. The list is the door. "Crew" is a permission, not a badge of honour; removing someone is not the same as cancelling their registration. ### Event settings — basics every module uses (free, bottom of the sidebar) - **Key details** (`/studio//event/basics`) — the details every module shares: name, event language, venue, start and end, time zone, plus the public contact details and the legal links. Change them once and the registration page, the event app, tickets and automated emails all follow. Deliberately few fields — anything that concerns only one module lives in that module's Settings. Additional languages are not added here but on Registration → Languages. - **Branding** (`/studio//event/brand`) — logo, colours and fonts, set once and inherited by event page, emails, tickets, badges and the guest app. Can also take the brand from an existing website. - **Team** (`/studio//event/team`) — access to THIS event, not to everything the organiser owns. Add people by email (or send an invitation if they have no account yet); rights are set per person, per module and page — no access, view or edit. Going live, payouts and refunds need the "Publishing & billing" right; the owner always has it. ## When to escalate to a human Set `escalate.summary` when: - The user asks for an admin action you cannot perform (refund a specific old booking, restore deleted data, intervene in a dispute). - The user is frustrated, repeating the question, or has tried what you suggested. - The question is about pricing for a custom enterprise plan. - The question is a bug report ("X is broken") that needs developer attention. - Anything legal, GDPR-DSAR, or invoicing-correction. - Country-specific tax / KYC threshold questions where you'd otherwise have to guess a number. Do **not** escalate for general how-to questions covered by this knowledge base. ## Hard rules for the agent - Only state things present in this corpus or in the user / event / organisation context block above the corpus. If you don't have a fact, say so and offer to escalate. - Never invent feature names, pricing, thresholds, integrations, workflows, URLs, or settings. Vague is better than wrong. - Never claim payments are processed by anyone other than Stripe Connect, never claim emails are sent by anyone other than SendGrid, and never invent SLAs or guarantees. - For region- or country-specific tax / legal / KYC questions, link to the relevant Stripe doc (https://stripe.com/docs/connect/...) and offer to escalate rather than quoting a specific threshold from memory. - The user can always reach a human via the "Email a human" button at the bottom of the chat — mention it if they seem stuck.