In short
A prepaid event is a booking you create under Settings → Prepaid events. It runs on one of your priced menus, you choose whether guests see the prices, and it has its own access rules and a start and an end.
While it runs, the guests you allowed in order against the allowances you agreed with the client. Anything the allowances do not cover, the guest pays for at checkout as usual.
When you end the event, the consumption report is final - the counts and quantities per item the client covered, plus their value at your own menu prices. How you bill your client from there is up to you.
What a prepaid event is
A prepaid event is a booking a client is paying for: they hire you for a window, and their guests order against what the client has agreed to cover. Every item keeps its price - the event only decides whether guests see prices - and anything outside the allowances is paid by the guest.
You create one booking per event and start it on the day. It is deliberately not a switch you leave on: an event is something you start and end, like a shift.
Create the event
You set a booking up under Settings → Prepaid events. Creating one walks you through:
- 1
Name and client
A name you will recognise on the day, and the client you are invoicing. Both show in the banner while the event runs.
- 2
Start and end time
The window the event runs in. The end time is required, but soft: Slipp never cuts you off at the hour, it just flags the event as overdue until you end it.
- 3
The menu and the prices
Which of your menus the event runs on, and whether guests see its prices while the event is on.
- 4
Who can order
Any email domains that belong to the event (@company.com), plus a guest list for anyone outside them.
- 5
Allowances
Labelled groups saying what each guest gets - "1 burger", "3 drinks". Anything not in a group is paid by the guest.
Pick the menu for the event
The event runs on one of your own menus, and that is what guests can order from. Every item keeps its price: the event only decides whether guests see prices while it runs, and your report and your invoice always have them.
Pick the menu you already sell from, or build a shorter one for the event. Keep it short. A prepaid event is not the moment to offer everything you can make - a tight menu is faster at the counter and simpler to invoice.
Set who can order
A guest is let in if the email they signed in with is on one of the event’s domains, or if their address is on the guest list. The two work together: a @company.com event can still carry a list of consultants, partner-agency staff and plus-ones.
You can import the guest list from a CSV or type addresses in by hand, and you can see who has been added along the way.
- Domains and the guest list are additive - use either, or both.
- New guests can be added straight from the live dashboard, which covers anyone signed in on a personal address.
- Slipp records who admitted a guest at the counter.
Set the allowances
An allowance group is a label, a quantity per guest, and the menu items it covers - "3 drinks per guest" spanning every drink on the menu. Guests see what they have left while they order, and anything a group no longer covers moves to the part of the order the guest pays for.
Items in no group are paid by the guest at checkout, so leaving water or coffee out of a group is a decision, not a leak. A single group covering every item, with no limit, puts the whole menu on the client’s tab.
Start, close and end the event
From 15 minutes before the start time, a banner appears on every screen in the app and carries the event through its whole life:
Start
Starting is always a deliberate tap - there is no auto-start. You confirm a short pre-flight first: how many items are on the menu, the access rules and the limits.
While it runs
The banner shows the event name, the client, the live order count and the end time. Your board and pickup area work exactly as usual - event orders queue, get prepared and get collected like any other order.
Close for new orders
Closing stops new orders while the queue serves out, so you can wind the counter down gracefully. It is reversible: reopen, and guests can order again.
End the event
Ending is like closing a till. You confirm the final counts, and if orders are still open Slipp says so and points you at closing for new orders first.
Pull the report and invoice
The consumption report runs live during the event and is final once you end it: how many distinct guests the client covered, the number of orders, the quantity of each item covered and the covered value at your own menu prices. What a guest paid for themselves is not in it - that is an ordinary paid order. That covered-guest count is what your mobile-ordering line to the client is based on, and what Slipp invoices you on. Export it as CSV to attach to your invoice, or to check your own numbers against.
Once you have invoiced the client, mark the event as invoiced on its detail page. That is private bookkeeping, so "have I billed them yet" does not have to live in a spreadsheet.
Prepaid-event checklist
- 1 Create the booking with the client, the window and the menu it runs on.
- 2 Trim the menu and decide whether guests see prices - short beats complete.
- 3 Add any email domains that should get in (@company.com), and import or type in the guest list.
- 4 Build the allowance groups, and decide what guests pay for themselves.
- 5 Start the event on the day and read the pre-flight summary.
- 6 Close for new orders while you wind down, then end the event.
- 7 Pull the report, invoice the client, and mark it invoiced.