Events

Events let you run workshops, socials, classes, and community gatherings out of your space, with tickets that members and the public can buy or RSVP for. Each event belongs to a location in your workspace and carries its own schedule, pricing, capacity, and visibility settings. This guide covers creating events, configuring tickets and capacity, member-only events, how people buy or register, and how ticket holders are tracked.

Creating an event

To create an event you need the permission to manage events. When you create one, Deskie records the details below and immediately sets the event to a published status and active state, so it can start accepting tickets right away.

Title and an optional description.
Location: every event is anchored to a single location. You must have access to that location to create or edit the event.
Start time and end time.
An optional host name and host description, useful when the event is led by a guest speaker or partner.
An optional event image. Images are uploaded first, then attached to the event.

Once saved, the event appears in your events list and, depending on its visibility settings, in the member portal and on your public website. You can edit any of these fields later, and editing re-saves the full set of details, including pricing, capacity, and visibility.

Sharing an event across locations

An event lives at one primary location, but you can share it with additional locations in the same workspace. When you do, staff scoped to those locations can see and manage the event, and you can optionally set a billing location that determines which location the ticket revenue is attributed to. The billing location is only applied when the event is actually shared with at least one other location; for a single-location event, revenue follows the buyer's primary location as usual.

Tickets and pricing

Deskie supports two distinct ticket prices on every event:

Member price: the per-ticket price charged to signed-in members of your workspace.
Non-member price: the per-ticket price charged to the public and to guests.

Either price can be left blank, which Deskie treats as free (a price of zero). Free events skip payment processing entirely: no card is charged, and a zero-amount invoice is still recorded so the registration shows up in billing history. When a ticket has a real price, the buyer is charged and a paid invoice is generated.

The price a given person pays is decided on the server, never trusted from the browser. A signed-in member who is allowed to buy at the member rate pays the member price; everyone else pays the non-member price. This keeps the price shown in the purchase screen and the amount actually charged in lock-step.

Tax and card fees

For paid public ticket purchases, Deskie applies your workspace tax and card-fee surcharges on top of the ticket subtotal at checkout. The invoice records the ticket subtotal, and the tax and card-fee amounts are snapshotted alongside it so the receipt reflects exactly what was charged. See Tax and card fees for how those surcharges are configured.

Coupons

A coupon code can be applied at the time of purchase. Deskie validates the code against the event and the order amount, applies the discount, and redeems the coupon once the ticket is created (or once payment succeeds for paid events). See Coupons for setting up codes.

Capacity

You can cap how many tickets an event sells. Deskie tracks three independent limits, and any of them can be left blank to mean unlimited:

Total capacity: the overall ceiling across all tickets, member and non-member combined.
Member tickets: how many tickets the member bucket can sell.
Non-member tickets: how many tickets the non-member (public and guest) bucket can sell.

Availability is counted against confirmed tickets only. When someone tries to buy or register, Deskie checks the relevant limits before allowing the ticket through. A purchase is rejected if the event has already ended, if it has been cancelled, if it would exceed the total capacity, or if it would exceed the bucket that applies to that buyer. Buckets are tracked by role: a real member draws from the member allotment and a guest draws from the non-member allotment, regardless of which price they happened to pay.

On the public site, the number of tickets shown as remaining is bounded by both the buyer's own bucket and the overall total, so it reflects whichever of those two limits is tighter. If a buyer asks for more tickets than are left, Deskie returns the exact number still available rather than overbooking.

Visibility and member-only events

Two pairs of switches control who sees and can buy each event:

Allow member purchase: when on, signed-in members can see and buy the event in the member portal. When off, the event is not offered to members.
Hide from member listing: keeps an otherwise member-purchasable event out of the member portal listing while still allowing it to be reached and bought directly.
Allow non-member purchase: when on, the public and guests can buy the event on your public website. When off, the event is not public.
Hide from public listing: keeps an otherwise public event off the public listing while still allowing it to be reached directly.

A member-only event is simply one where member purchase is allowed but non-member purchase is turned off. Members can see and buy it; the general public cannot. On the public site, a signed-in member also sees member-only events and is offered the member price, while a non-member sees only events that allow non-member purchase. The public listing filters out events that are hidden from the public listing, are inactive, are not published, or have already ended.

Door access for ticket holders

An event can be flagged to grant door access to ticket holders, optionally tied to specific Kisi groups or locks. When door access is enabled, ticket confirmation emails indicate that access is included, and a confirmed ticket holder is granted access to the event's configured door locks during the event's start-to-end window through your door access integration. For how door access is configured more broadly, see Door access.

How people get tickets

There are a few distinct paths to a ticket, depending on who is buying and how.

Members buying through the portal

A signed-in member can either pay immediately or add the ticket to their next invoice:

Pay now: the ticket is created as paid and confirmed.
Add to invoice: the ticket is confirmed now and billed on the member's invoice later. This option is member-only. Guests have no billing relationship and must pay at the time of purchase, so the system rejects an attempt to invoice a guest. If the event is free, the ticket is confirmed and a zero-amount invoice is recorded.

A member who is paused is blocked from the pay-now path. Where team billing applies, a member's ticket can be routed to their team's billing rather than their personal card; see Teams.

Public and guest checkout

On your public website, anyone can buy a ticket to an event that allows non-member purchase, and a signed-in member can additionally buy member-only events at the member rate. The checkout collects the purchaser's details plus details for any additional attendees, and a payment method and billing address for paid events. A member whose account is paused cannot complete a public checkout.

When a non-member checks out, Deskie provisions a guest member account for them anchored to the event's location, so they land in that location's roster and can be billed and emailed. If the buyer's email already belongs to an existing account, that account is reused. New guests are also captured as a lead in the CRM. After a successful purchase, each attendee receives a confirmation email, and brand-new guest accounts receive login details so they can sign in later. See Public sign-up and checkout for the broader public flow.

Multiple attendees on one purchase

A public ticket purchase can cover more than one person. The purchaser is recorded as the buyer, and each additional attendee gets their own attendee record and a guest account anchored to the event's location. The purchaser receives the full confirmation with payment details; additional attendees receive a simpler confirmation that names the purchaser.

Bulk RSVP import

For a free event, an admin can bulk-register a list of guests at once, treating each row exactly as if the guest had RSVP'd themselves. This is useful for importing a list collected outside Deskie, such as a sign-up sheet or a partner's attendee list. The import requires the manage-events permission and accepts up to 500 guests per run.

The import enforces the same rules as self-service RSVP, so it cannot be used as a back door:

Only free events are eligible. A paid event is rejected outright, because a ticket cannot be issued without payment.
The event must be active, not cancelled, not yet ended, and open to non-member guests.
Each row needs a first name, last name, and a valid email. Rows missing those, or with an invalid email, are marked failed.
Guests who already hold a confirmed ticket for the event are skipped, so the same person is never double-registered.
Capacity is respected. Once the event's remaining allotment is exhausted, further rows fail rather than overbooking.

For each successful row, Deskie provisions a guest account anchored to the event's location, creates a confirmed ticket and attendee record together, records a zero-amount invoice, and emails the guest the standard RSVP confirmation (including login details when the account is newly created). The import returns a per-row result of registered, skipped, or failed, so you can see exactly what happened to each entry. Per-row signup notifications to admins are suppressed during a bulk import, since you initiated it.

Ticket status

Each ticket carries a status that staff can read at a glance. On the event's ticket-holder list and on a ticket's detail view, a confirmed ticket shows as Confirmed, a ticket awaiting payment shows as Pending Payment, and a cancelled ticket shows as Cancelled. If a ticket carries a check-in timestamp, it shows a Checked In badge along with the recorded time. For events with door access enabled, ticket holders' entry is handled through your door access integration during the event window.

Managing tickets and events after they go live

View ticket holders: each event shows its tickets with the holder's name, contact details, role, quantity, price, payment status, and check-in time. The event detail view also summarizes how many tickets have sold overall and how many came from members versus non-members.
Cancel a ticket: an admin can cancel an individual ticket with an optional reason. The holder is emailed a cancellation notice. Refunds are handled separately by the administrator.
Cancel an event: cancelling sets the event to cancelled and emails every confirmed ticket holder. A cancelled event can later be reactivated, which restores it to published.
Disable or enable an event: toggling an event inactive removes it from sale and from public and member listings without cancelling existing tickets; re-enabling makes it available again.

When a member buys a ticket through the portal, or when someone pays for a ticket on your public website, your admins are notified by email, SMS, and push, so the front desk knows when someone has signed up. Tickets and their revenue flow into the rest of Deskie's billing, so you can review them alongside other charges in Invoices and Payments.